The most expensive mistakes in software are not made during development. They are made before development starts — in how requirements are written, and in how the domain is modelled. In 2026, two structural forces are reshaping both of these phases. Neither is optional when AI agents are in the build chain.
- Requirements now have three readers — the user, the AI agent, and the reviewer — and each needs a different artifact from the same analysis.
- DDD is the language of agent delegation: bounded context = agent scope, ubiquitous language = prompt vocabulary, domain events = integration contracts.
- A pre-sprint checklist and a five-step EventStorming shortcut for making a domain agent-ready.
This article covers Forces 01 and 02 from the eight structural forces reshaping software development. These are the forces that operate upstream of everything: they determine the quality ceiling for everything AI builds downstream. Get them right, and AI amplifies precision. Get them wrong, and AI amplifies the wrong thing faster.
Three-Stakeholder Analysis: Users, Agents & Reviewers
Every requirement now serves three distinct audiences — the humans who will use the feature, the AI agents who will build it, and the reviewers who will validate quality and compliance. Writing for one is no longer enough.
The most expensive bugs are not logic errors. They are requirement errors — misunderstandings that survive the entire development cycle and reach production because the specification was written for one reader and interpreted by another. This problem existed before AI. AI makes it significantly more expensive.
When a human developer misreads a spec, they usually notice. They ask a clarifying question, they run it by a colleague, they realise during implementation that something is off. When an AI agent misreads a spec, it implements the misreading with complete confidence, generates tests that validate the misreading, and produces clean code that does the wrong thing coherently. The error is harder to detect because it looks right.
Writing for Three Readers
A requirement that serves three audiences is not three times the work. It is one discovery conversation that produces three artifacts. The discipline is in knowing what each reader actually needs:
The three-audience approach surfaces something valuable beyond the artifacts themselves: it exposes conflicting assumptions before design starts. When you try to write the agent spec, you discover that the user story was ambiguous. When you write the reviewer checklist, you discover that a compliance requirement contradicts the user story. These conflicts exist regardless — the three-audience process just finds them in a planning session rather than in a post-production incident.
What AI Can Do at This Phase — and What It Cannot
In 2026, AI can generate all three artifacts from a single discovery session. Given a recording or transcript of a stakeholder meeting, a well-prompted model (Claude Sonnet, Gemini 2.5) will produce a draft user story, a structured agent spec, and a reviewer checklist in minutes. It will also surface gaps — places where the discovery conversation did not produce enough information for a complete spec.
What AI cannot do is attend the meeting. It cannot ask the follow-up question when a stakeholder's answer is contradicted by their body language. It cannot notice that the product owner and the engineer have a different mental model of the same feature. The discovery conversation itself is the part that requires human judgment — and it is the part that determines the quality of everything that follows.
DDD as the Language of AI Delegation
Domain-Driven Design has quietly become the most critical AI engineering skill — not philosophically, but practically. Bounded contexts are the natural unit of AI agent assignment, and ambiguous domains produce ambiguous AI output at architectural speed.
In Article 02, we established that an agent's bounded context is its scope boundary — the definition of what it is allowed to touch, what it must not touch, and what constitutes success within that scope. The question that article did not fully answer is: how do you define those bounded contexts for a real production system?
The answer is Domain-Driven Design. Not as a philosophy — as a practical method for producing the input that makes agent-based development reliable.
The DDD Concepts That Now Do Double Duty
Each core DDD concept maps directly to an agent requirement. This is not a metaphor — these are the exact properties an agent needs to operate reliably within a production system:
EventStorming: The Fastest Path to Agent-Ready Contexts
You do not need a perfect DDD model to get started. You need enough structure to give agents unambiguous scope. EventStorming is the fastest method for a team that has not done DDD before — and for teams that have, it is a useful reset when AI is being introduced to an existing codebase.
A two-hour EventStorming session with the right people — domain experts, not just engineers — will produce enough structure for an agent to operate reliably within one context. That is all you need to start. You do not need the full map before you begin. You need the map for the context you are working in next sprint.
Red Flags: When a Domain Is Not Ready for Agents
- The team uses different names for the same concept across different files or conversations — the ubiquitous language does not exist.
- Changing one service requires changes in three other services as a matter of routine — bounded contexts are not bounded.
- Nobody can draw the context map in 10 minutes — the domain model exists only in individual engineers' heads.
- The word "everything" appears in feature descriptions — "update everything for the new pricing rule" is not an agent-ready task.
- There are no domain events — services communicate via direct database reads or synchronous REST calls with no published contracts.
None of these red flags are unfixable. They are signals that the DDD work needs to happen before agent deployment — not alongside it. Agents introduced into an ambiguous domain do not clarify it. They encode the ambiguity into generated code that is harder to refactor than hand-written code, because it is more consistent-looking and more of it exists.
Why These Two Forces Are Inseparable
Forces 01 and 02 look like separate concerns — one is about writing requirements, the other is about modelling the domain. In practice, they are the same conversation at different levels of zoom.
A good domain model is the context that makes requirements precise. When you know the bounded context, the ubiquitous language, and the aggregates, you can write the agent spec unambiguously — because you know exactly which aggregate you are operating on, which events you are emitting, and which boundaries you must not cross.
And the reverse is equally true: writing requirements for three audiences reveals domain model gaps. When you try to write the agent spec and discover you cannot define the bounded context clearly, that is the domain model telling you something. The requirement work and the domain design are a feedback loop, not a waterfall.