Chapter 3: Core Differences Between Old and New Paradigms
AOSE inherits and elevates Agile principles. The core shift is from “hand-coding” to “defining requirements and reviewing AI solutions.” Value creation moves from implementation to definition and verification, requiring technical personnel to develop new core capabilities in specification design and AI review.
1 From Agile to Intent-Driven: A Paradigm Leap
Looking back at the evolution of software engineering, Agile Development has undoubtedly been the most influential paradigm shift over the past two decades. Through practices such as short-cycle iterations, continuous delivery, and rapid response to change, it effectively addressed the core problem of “how to maintain responsiveness in an environment of constantly changing requirements.” However, with the maturation of large language models and AI Agent technologies, software engineering is now facing a new proposition: “how to redefine the division of labor and collaboration between humans and machines in the AI era.”
Agent-Oriented Software Engineering (AOSE) was born to respond to this proposition. It is particularly important to emphasize that AOSE is by no means a negation or subversion of Agile principles; on the contrary, it is another paradigm leap built upon Agile methodology—Agile solved the problem of “how people collaborate efficiently,” while AOSE will further solve the problem of “how humans and AI collaborate efficiently.” The two are in a continuous, evolutionary relationship.
2 Core Dimension Comparison
To more clearly understand the differences between the two paradigms, let us conduct a systematic comparative analysis across four dimensions: core units, development processes, team roles, and deliverables.
Evolution of User Stories: From Interpersonal Communication to Human-Machine Collaboration
User Stories in Agile development, as the core unit of requirement expression, still retain their value in the AOSE era, but their form of expression and target audience have undergone significant changes.
In traditional Agile practice, user stories primarily serve communication among team members. The classic format of “As a
In the AOSE paradigm, user stories need to carry more responsibility: they must not only be understood by human team members but also be accurately executed by coding Agents. This requires us to adopt more structured, unambiguous forms of expression. Behavior-Driven Development (BDD) using Gherkin syntax is an effective choice—it describes scenarios through the “Given-When-Then” format, maintaining the readability of natural language while possessing the rigorous structure required for machine parsing.
The key to this evolution lies in: Product Requirements define “what to do,” serving as a human-machine readable requirement expression; technical personnel then define Implementation Specifications to guide the Agent in completing “how to decompose and execute.” Product Requirements are oriented toward business value, while Implementation Specifications are oriented toward technical execution; the two collaborate to complete the transformation from requirements to code.
It should be emphasized that this is only a conceptual introduction. How to write user stories and acceptance criteria suitable for Agent execution in practice will be elaborated in detail in subsequent implementation chapters.
Changes in Development Process
| Development Phase | Agile Development Practice | Intent-Oriented Development Practice |
|---|---|---|
| Requirements Input | Product Manager writes PRD documents, discussed and confirmed through requirement review meetings | Product Manager defines Business Requirements and Product Requirements, technical personnel guide Agent execution accordingly |
| Task Breakdown | Tech Lead manually breaks down tasks, estimates effort, and schedules | Task breakdown in Technical Intent directly guides Agent execution |
| Coding Implementation | Developers manually write every line of code | Agent generates code based on Technical Intent Implementation Specifications, humans review |
| Testing & Verification | QA engineers write test cases, executed through manual and automated combination | Agent automatically generates and executes tests based on acceptance specifications |
| Code Review | Manual review of code style and logical correctness | Human review of intent alignment and Implementation Specification rationality |
The essence of process change is the shift in value creation: humans move from “hands-on implementation” to “definition and verification,” while AI takes over the “specific execution” phase.
Changes in Team Roles
| Role | Core Competency Requirements in Agile Era | Core Competency Requirements in AOSE Era |
|---|---|---|
| Product Manager | Writing PRDs, drawing prototypes, requirement communication and coordination | Defining Product Requirements, designing business rules, validating value realization |
| Architect/Tech Lead | Drawing architecture diagrams, technical selection decisions | Defining Technical Intent (Implementation Specifications + constraints), designing system decomposition |
| Developer | Coding implementation, debugging, performance optimization | Defining Implementation Specifications, reviewing AI solutions, handling edge cases |
| Test Engineer | Writing test cases, executing tests, reporting defects | Designing acceptance specifications, defining quality gates, reviewing test coverage |
| Operations Engineer | System deployment, monitoring and alerting, incident handling | SRE strategy design, configuring self-healing rules, observability architecture |
The change in roles is not simply a replacement of skills but a shift in the focus of capabilities. Everyone moves from “executor” toward “definer” and “reviewer.”
Changes in Deliverables
| Deliverable Type | Agile Era | AOSE Era |
|---|---|---|
| Requirements Documents | PRD documents, user story lists | Business Requirements + Product Requirements |
| Design Documents | Architecture diagrams, sequence diagrams, flowcharts | Agent Execution Output |
| Code | Primarily written and maintained by humans | AI-generated based on Implementation Specifications, human-reviewed and key modules written by humans |
| Testing Assets | Manually written test scripts and cases | Acceptance specification-driven, AI-generated test code |
Particularly noteworthy is the upgrade in delivery logic: from “humans reading documents and then manually coding” to “coding Agents directly understanding requirements and generating code.” This is not merely a change in document format but a reconstruction of the value delivery chain around coding intelligence—Business Requirements point the direction, Product Requirements define functionality, and Technical Intent guides Agents to complete specific development. Business Requirements and Product Requirements constitute the core deliverables at the requirements level, while Technical Intent serves as the implementation blueprint for technical personnel to guide Agent execution, enabling business value to be transformed into runnable software at a faster pace from concept.
3 Three Key Mindset Shifts
The deep foundation of paradigm transformation is the shift in thinking patterns. From Agile to AOSE, we need to complete cognitive upgrades across three dimensions.
From “Controlling Implementation Details” to “Defining Implementation Specifications”
In the Agile era, the work of architects was often “control-oriented”: drawing detailed class diagrams, sequence diagrams, and state diagrams, specifying the interfaces and data structures of every module. The developer’s task was to follow the map and strictly adhere to design documents without deviating from the predetermined path.
In the AOSE era, the role of technical leads transforms into “Implementation Specification definers”:
- No longer hand-writing every line of code, but defining Implementation Specifications in Technical Intent—including how modules are decomposed, how data models are designed, how interface contracts are defined, and how development tasks are broken down;
- No longer specifying “how each class should be implemented,” but defining architectural constraints such as “the domain layer must not depend on the infrastructure layer,” and performance constraints such as “all external interfaces must satisfy P99 response time < 100ms”;
- AI autonomously completes coding based on Implementation Specifications, with humans responsible for reviewing whether the implementation conforms to specifications and whether the solution is reasonable.
The essence of this shift is moving from coding executor to specification definer. The core value of technical personnel is reflected in “whether they can define sufficiently clear and complete Implementation Specifications that enable AI to autonomously complete development tasks based on them.”
From “Hand-Writing Code” to “Reviewing AI Solutions”
Let us use flowcharts to intuitively demonstrate this change:
Value Creation Chain in Agile Era:
Requirements → Design → Coding → Testing → Production
↑Humans create core value here
Value Creation Chain in AOSE Era:
Product Requirements + Technical Intent → Agent generates based on Implementation Specifications → Human review → Agent implements → Automated testing → Human acceptance and production
↑Humans define functional direction and Implementation Specifications ↑Humans judge whether implementation conforms to specifications
The point of value creation shifts from “coding implementation” to “Product Requirements definition,” “Technical Intent (Implementation Specifications) definition,” and “implementation review.” This requires technical personnel to cultivate new capabilities: how to decompose product functionality into executable modules, how to design clear data models and interface contracts, how to define verifiable acceptance specifications, and how to quickly judge whether AI-generated implementations conform to specifications.
From “Collaboration Between People” to “Collaboration Between Humans and Agent, and Between Agent and Agent”
Agile development highly emphasizes “interactions between individuals”; daily stand-ups, pair programming, and code reviews are all practices designed to promote efficient collaboration among team members.
The AOSE era introduces new dimensions of collaboration:
- Human-Agent Collaboration: Humans define intent, Agent executes implementation, humans review results;
- Agent-Agent Collaboration: Multiple specialized Agents work in parallel—requirement analysis Agents, architecture design Agents, code generation Agents, testing Agents, etc.—collaborating through structured intent descriptions.
This shift does not mean that collaboration between people is no longer important; rather, collaboration complexity and efficiency are enhanced by AI—humans can focus on higher-level strategic discussions and Value Judgment and Intent Coordination, leaving execution-level coordination to AI.
4 Retention and Sublimation of Agile Core
Agent-Oriented Software Engineering is by no means an abandonment of Agile; on the contrary, it sublimates the core values of the Agile Manifesto, giving them new vitality in the AI era:
| Original Agile Manifesto | Specific Manifestation in AOSE |
|---|---|
| Individuals and interactions over processes and tools | Humans focus on high-value intent definition and verification, AI handles repetitive execution work, unleashing human creativity |
| Working software over comprehensive documentation | Lightweight intent descriptions can drive Agents to complete requirement analysis, design, and generate runnable software, with documentation greatly simplified |
| Customer collaboration over contract negotiation | Customer intent can be quickly transformed into verifiable prototypes through Agents, shortening feedback cycles and achieving real-time requirement alignment |
| Responding to change over following a plan | After intent changes, AI can regenerate implementations at the minute level, with response speed achieving exponential improvement |
Based on this relationship of inheritance and sublimation, we can attempt to propose an “Agile Manifesto 2.0” for the Intent-Oriented era:
- Clear and explicit intent over intricate and complex code
- Complete and rigorous constraints over cumbersome and tedious processes
- Overall efficiency of human-machine collaboration over coordination costs between people
- Rapid delivery of value over rapid accumulation of features
5 Resistance to Change and Coping Strategies
Any profound change encounters resistance. Understanding the sources of this resistance and adopting effective coping strategies is key to successful transformation.
Cognitive Inertia: “If I’m Not Writing Code, What Am I Doing?”
Typical manifestation: Senior developers might ask: “I’ve been writing code for ten years, and now you’re telling me not to write code? What am I doing? Where is my value?”
Coping strategies:
- Redefine value measurement: Help the team establish new value cognition—from “how many lines of code I wrote” to “how many high-value Product Requirements I defined,” “how many clear Implementation Specifications I designed,” “how many problems I found in AI solutions”;
- Systematic skill upgrade training: Provide pathways for cultivating new capabilities from coding skills to intent expression, constraint design, and systems thinking;
- Establish benchmark demonstrations: Let those who have successfully completed the transformation share their experiences and sources of achievement, letting facts speak for themselves.
Process Dependency: “Our Current Process is Running Smoothly”
Typical manifestation: The team might say: “Our Scrum process is already running smoothly, and our Sprint rhythm is stable; why bother?”
Coping strategies:
- Small-step pilots, leading by example: Start pilots from non-core businesses or newly launched projects, without touching core processes that are already running stably;
- Data-driven decision making: Establish clear comparative metrics, letting before-and-after efficiency and quality data from pilots speak for themselves;
- Respect existing rituals, change substantive content: Retain familiar Agile rituals (such as daily stand-ups, Sprint retrospectives), but change what is discussed—from “what code was written yesterday” to “what Product Requirements were defined yesterday, what Implementation Specifications were refined.”
Trust Deficit: “I Don’t Believe AI Can Write Good Code”
Typical manifestation: Skepticism about the quality of AI-generated code, worrying about introducing uncontrollable risks.
Coping strategies:
- Establish transparent mechanisms: Have AI explain “why this implementation solution was chosen” while generating code, enhancing understandability and auditability;
- Improve constraint guarantee systems: Ensure AI does not overstep boundaries through rule engines and static checking tools, gradually expanding AI’s authority within a controllable risk range;
- Progressive authorization strategy: Start from AI-assisted coding (such as code completion), gradually transition to AI generating module code, and then to AI implementing complete features, allowing the team to gradually build trust through the process.
6 Chapter Summary
Through systematic comparison of old and new paradigms, we can summarize the core differences in one sentence:
The core problem Agile Development solves is “how people collaborate efficiently amid changing requirements,” while the core problem Agent-Oriented Software Engineering solves is “how humans and AI divide labor and collaborate, each contributing their strengths.”
| Key Dimension | Characteristics of Agile Era | Characteristics of AOSE Era |
|---|---|---|
| Core Work Unit | User Story | Business Requirements, Product Requirements, Implementation Specifications |
| Human-Machine Division of Labor | Humans write code, machines handle compilation and execution | Humans define Product Requirements and Technical Intent, Agents generate code based on Implementation Specifications |
| Team Role Positioning | Professional division by skill | Product personnel define Business Requirements and Product Requirements, technical personnel define Implementation Specifications |
| Core Deliverables | Code and documentation | Business Requirements, Product Requirements, AI-generated code |
| Focus of Thinking | How (how to implement) | What (Product Requirements) + How to implement (Implementation Specifications) |
This transformation is not a negation of software engineering history but a natural evolution and upgrade of software engineering against the backdrop of AI capability leaps. Deeply understanding these differences is the prerequisite and foundation for our successful completion of the paradigm transition.
Discussion Questions
Review the Agile practices currently adopted by your team (such as Scrum, Kanban, or XP). Which practices may become unnecessary under the AOSE paradigm, and which need to be retained but changed in form? For example, are daily stand-ups still valuable? How should Sprint review meetings be adjusted?
Suppose your team decides to pilot the AOSE paradigm next quarter. Which role do you think will present the greatest resistance—senior developers worried about diluted value, architects worried about losing control, or management worried about process chaos? How would you design a communication strategy for this role?
Comparing the four values of the Agile Manifesto with the sublimated expressions of AOSE, which transformation has the greatest impact on your personal work style? Is it the change in expression habits brought about by “documentation being greatly simplified,” or the change in collaboration patterns brought about by “rapid validation of customer intent”?