Current chapter · Six-part field guide
Part 6 of 6 Building an AI-first development system
The real measure of AI-first engineering is the second change
The first implementation can demonstrate speed. The next changed requirement reveals whether the system can adapt without losing its existing guarantees.
The first implementation demonstrates speed. The second change reveals the system.
The first version can lie
A first implementation is unusually cooperative. The design is current, the requirement is close to the conversation that created it, and the code has not accumulated competing responsibilities. An agent can move quickly because the world around the task is temporarily small.
That makes first-version speed a weak measure of an AI-first system. The more revealing moment comes when the product changes its mind. A new role appears. An API separates one status into three. A mobile workflow needs a different interaction. A shared component gains a second consumer with a legitimate exception.
The question is no longer whether the system can generate code. It is whether it can identify what changed, preserve what did not, update the affected implementation and evidence, and leave the repository more understandable than it found it.
A sanitized workflow that outgrew its booleans
Consider a sanitized review workflow that began with pending, approved, and rejected states. The first implementation reduced the behavior to a few booleans because the initial screen only needed two buttons and a status label. It worked for that release.
The second requirement introduced partial approval, a needs-information state, expiry, and role-specific actions. The generated change added more flags in the component and more conditions in the template. Several combinations could now render an approved label beside an action asking the user to submit more information. The first implementation had encoded the screenshot instead of the workflow.
The artifact I use for this kind of change is an invariant and change map. It records the old and new requirement versions, the states and transitions being added, the guarantees that must remain true, the affected consumers, and the evidence that needs to be refreshed. In this case, the map would make the state model — not the existing booleans — the unit of change.
What I automate
I automate comparison between requirement versions and the discovery of likely impact. The system can identify changed behaviors, search for consumers, locate tests and documentation, and propose which context packets, implementation areas, and verification paths need to move.
An agent can then update the explicit state model, migrate consumers, generate or revise transition tests, and exercise the browser paths for old and new behavior. The evidence from the earlier release remains useful because it describes guarantees the second change must either preserve or intentionally replace.
After verification, automation can refresh durable context with the accepted decision. Temporary debugging evidence stays temporary. New product truth goes to the source that owns it. This keeps the next task from rebuilding its understanding from a pile of contradictory history.
What remains a human decision
Humans decide which old behaviors are invariants and which are implementation accidents. They decide whether backward compatibility is required, whether a migration can be immediate, and whether temporary dual behavior is worth the complexity.
A person also decides when the existing boundary has stopped absorbing change. An agent can show that conditions are spreading across several consumers. Architecture judgment is required to decide whether to introduce a state machine, split a responsibility, change an API contract, or accept a smaller local compromise.
The difficult choice is often not how to implement the new requirement. It is what kind of future the system should make easier. That decision depends on product direction, team capacity, and the cost of being wrong.
Design for legible change, not imagined futures
There is a trade-off here. Designing for every possible second change produces abstraction without evidence. A generic workflow engine built for a three-state feature may be more expensive and less understandable than the original booleans. I do not want speculative flexibility disguised as architecture.
I want the first version to make its assumptions visible. States should have names. Ownership should be clear. Requirements and evidence should be traceable. When the second change arrives, the system should reveal the pressure instead of scattering it through unrelated files.
That is how I measure scale and adaptation. Not by the amount of code an agent can produce in one sitting, but by how calmly the complete system absorbs the next legitimate change without forgetting what the product already promised.