AI-Native Software Engineering (SE 3.0)

Hassan and five co-authors introduced their SE 3.0 vision in an October 2024 preprint, later revised and published in ACM TOSEM. They contrasted code-centric, task-driven assistance with a proposed stack for intent alignment, solution search and runtime support. Independent work subsequently used `AI-native software engineering` for generative reuse, platform changes and multi-agent collaboration across engineering activities.

Sources: s1, s2, s3, s4, s5

The label shifts the design question from `Which lines can a model generate?` to `How should people and agents share work across requirements, implementation, testing, release and maintenance?` That wider scope exposes needs that code completion can hide: durable context, explicit intent, evaluation gates, provenance, permissions, review ownership and platform support. It is useful as an architectural lens even when a team adopts only some of those practices.

Sources: s2, s3, s4, s5

A team might describe a service through a versioned specification and testable constraints. An agent proposes an implementation, runs tests and prepares a change; separate checks evaluate security, behavior and maintainability before a person authorizes release. This is closer to AI-native engineering than accepting isolated code suggestions, but it still does not prove autonomous delivery or remove responsibility from the team operating the system.

Sources: s2, s4, s5

`AI-native` can become a marketing label applied to ordinary assistant use. The concept does not determine how much authority an agent should receive, how intent is validated, or who accepts failures. Generated changes can introduce defects, insecure dependencies and maintenance costs; faster production can merely move effort into review and repair. Evaluate concrete workflows and measured outcomes, and treat the named `.next` components as one research vision rather than universal architecture.

Sources: s2, s3, s4, s5