Before the First Line of Code:
Forces 01–02

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.

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.

Requirement errors are the costly ones. A misunderstanding gets written into the spec, survives the entire development cycle, and reaches production – all because the specification was written for one reader and interpreted by another. This problem existed long before AI. AI just makes it far 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.

In Chapter 5, 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.

Writing the Design Down: The Standards an Agent Can Read

EventStorming gives you the model. The next question is where the model lives. A design that exists in stickies and heads scopes nobody, human or machine, and this is where the classic documentation standards earn a second career. A documented standard does for the design phase what the user story template does for analysis: it defines the deliverable, in a form the model has already read many thousands of times in training.

None of these standards solves the design problem for you. They define what a finished design looks like, which is the one thing an agent cannot infer from intent alone. That is the pattern Chapter 6 closes on: scoped, not constrained. The bounded context tells the agent where it may work; arc42, C4, and UML tell it what the work is supposed to leave behind.

Red Flags: When a Domain Is Not Ready for Agents

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.