Which Development Method Survives AI

Every method you have run — Scrum, test-first, domain-driven design — was built for a world where producing a first version was expensive. It is not expensive any more. The common response is “Scrum, but faster”, which leaves a team performing a ceremony whose reason has left.

This is what we run instead, and the price behind each step. It assumes the roles set out earlier in this series: we are the engineering office, our software engineers supervise on site, and AI is the contractor. That argument is made here.

The price moved

Those methods were cost-management schemes for one scarce resource: producing a first version. They argued about plenty — who decides, how the work is cut up, which meetings are held. Four of those arguments were set by that price, and all four have an answer now.

Length — how much work goes into a single pass of define, design, build, verify, before anyone finds out the definition was wrong. Waterfall ran one pass at the scale of a project, over months. Agile ran the same pass inside a sprint. Test-first ran it inside a unit.

Order — which stage owns which activity. Test-first made that argument, and a test settles it: a test is the specification written in a form a machine can check, not a verification step that happens early. The test belongs to the definition. It was filed under verification because it used to be written last.

How much foundation before features — agile’s answer was as little as possible. Defer the decision, let the architecture emerge, refactor when it hurts. That was the right call at the time: a foundation is a bet on demand, and demand was unknowable until you built something and watched people use it. The bill arrives on a schedule every engineering manager recognises — a few sprints of speed, then a foundation that cannot carry the next feature, then the rewrite.

What carries the truth — where a team looks to settle what the system is supposed to do. When producing a running version was slow, the referent had to be a document; there was nothing else to point at. Every method since has moved the referent closer to something executable: working software over comprehensive documentation, then the test as the thing that says what correct means.

Methods encode the cost of their era. It is the same mechanism we traced in innovation itself: scarcity is the filter that forces the good answer. Change the price and the method has to move, or it survives as ritual.

The price collapsed. A full pass — definition, architecture, code, verification — now closes in hours, at the scale of one feature.

Three things those methods were protecting survive that: the gate, where work stops and someone looks at the whole rather than the piece; the test as the executable half of the specification; and one shared language for the domain. What dies is the packaging they arrived in — the calendar, the ceremony, the months of workshops.

Speed was the first change. Two more came with it.

Speed on its own makes the existing method run faster. The two changes underneath it are the ones that move the method.

The second change is capacity at the definition stage. Defining a product is a skill, and it converges by iteration. A specialist does not author the specification in one pass — they put up a candidate, watch where it fails against what the business actually does, and run the next one. It takes many passes before the shape is stable enough to build on. What capped that work was the cost of a candidate, not the specialist’s ability: at a week per version you get three or four inside the budget, and you build on whichever one was standing when the money ran out.

AI raises the frequency of that loop. More candidates get tried per week, and the ideation a team can run stops being a function of its headcount. This has almost nothing to do with writing code faster. It also changes what the client is asked for: a requirements document asks them to author a specification, in a language they do not speak, about a system that does not exist, while a candidate asks them to look at a concrete thing and say where it is wrong. The second is a channel a domain expert can use immediately and without training. Their knowledge was never the bottleneck. The channel was, and the channel is now cheap enough to run twenty times.

The third change follows from the second. In the old sequence every stage was internally a single pass, because the only instrument that could tell you a stage was wrong was the finished product — a definition could not be tested except by building it. Now every stage produces its own candidate cheaply, so every stage iterates internally. The loop is no longer around the sequence. It is inside every box in it.

One thing does not follow: cheap passes buy short ones, not big up-front plans. A definition nobody has seen running is still a guess, however fast it was produced.

The method: three stages, and each one runs its own loop

The stages are the ones every method has. What changed is that the pass closes in hours and the specs never freeze.

Definition: draw it wrong on purpose

Most of the time the vision is partly clear. The client knows their business thoroughly, can describe eighty percent of the product without hesitating, then goes vague on the settings page, or the admin surface, or the approval flow. That does not call for a different process. It calls for a screen for that one part: a single static page, navigational, unpolished, deliberately unfinished. They open it and within a minute they are telling you what is wrong with it.

This is iteration at the definition stage, and the screen is the instrument that stage never had. The sequence holds whatever the starting point: the requirements document first, then the features list, then the screens. What changes is how much of the writing survives contact with them — a clear vision gets confirmed and sharpened, a vague one gets rebuilt. The corrections land back in those two either way.

The definition produces two specs, kept apart because they have independent lifecycles.

Business spec — the requirements document and the features list. What the product does, for whom, in what order: version one and later, including what was deliberately deferred and why.

Tech spec — the architecture. Boundaries, definitions, components, and how they communicate.

Features churn continuously; the foundation does not. Fuse the two and every feature change becomes an architecture change, which is how a system acquires the property where nothing can be added without touching everything. Kept apart, the foundation grows regardless of features: a new feature does not modify the architecture, it plugs into it.

Architecture: the contract that lets the next feature exist

Screens sit before architecture because a screen is a demand generator. Each one names the entities it displays, the states those entities can occupy, the transitions a user may trigger, the roles permitted to trigger them, and the data that must exist for the page to render at all. A settings page listing thirty toggles has told you there is a configuration domain with scoping, defaults and precedence rules. An approval flow drawn as three static pages has told you there is a state machine, who owns each transition, and what has to be auditable. Architect first and you are designing supply against unknown demand.

Agile was right about this. Deferring the foundation was the correct response to demand nobody could see yet, and the rewrite a few sprints later was the price of the deferral rather than a failure of discipline. Put the demand in front of the architect before the first commit and that reason is gone: the foundation can be built to carry what it will actually be asked to carry, and it is worth building properly, because it is no longer a guess.

The architecture’s product is the specification of how a new thing joins, not an inventory of parts. Get that contract right and features arrive as plugs into sockets that were already calculated. At twenty iterations a day this is what makes the speed survivable: if every feature has to be reasoned into place individually, integration cost consumes the entire gain and then keeps consuming. With the contract in place the contractor can pour all day, because the sockets were designed before the pour.

Architecture is also where the internal loop stops being free. Producing one got as cheap as everything else; discovering it was wrong did not. A wrong screen is corrected in a minute by someone who needs no training; a wrong boundary surfaces at the third feature, under change, weeks later. Cheap to generate and expensive to falsify is the definition of a stage that still takes judgment — which is the one the office stamps.

Iteration, and then the screens die

Iterations run against testable units, and the unit is chosen because it can be tested. The test written back at the definition is what each iteration runs against, and what pins the contractor to the drawing. A prose requirement can be satisfied in ways nobody intended; a test fixes the cases it names, and only those.

Both specs move as the product moves. A frozen spec is a cache, and caches lie.

The last step: once the product exists, the screens are deleted. A screen was a stored representation of intent, useful exactly as long as no better representation existed. The moment the product is real, the product is the intent, and a kept screen becomes a second source of truth guaranteed to drift. Every question answered by consulting a screen instead of the running product is an answer with an unknown expiry date.

Reality is the source of truth. Never store what can be read directly.

The specs are the deliberate asymmetry: they do not die, because they carry what the product cannot show — intent, rationale, and the version-one cut, including everything consciously not built. A running system cannot tell you what was deferred or why. The screens, once the product exists, cannot tell you anything the system does not say better.

What it costs to get this wrong

The common failure is keeping the ceremony and losing the gate. Two-week sprints whose work finished on day two. Standups reporting on iterations that closed before the meeting started. Retrospectives on a cadence nothing in the actual work shares any more. The ritual outlives its function, and because the ritual is the visible part, nobody notices what left.

Two substrates so far, and they sit about as far apart as the work gets: suctl, a command-line operator tool, and acp-patchbay, an editor extension. Same pipeline through both. acp-patchbay was released in five days. A method that works on one product may have met an easy domain; two that share almost nothing is what starts to suggest the method is doing the work.

The command-line tool is the harder case, because it has no screens. We drew them anyway — HTML pages standing in for terminal sessions — and they behaved as they do for a graphical product: the corrections came back within the hour, and they were about the command surface rather than the screen itself. The definition stage does not need a user interface. It needs something concrete enough to be wrong.

Both are open source.

Every method answered what does a first version cost?, which is the same question as how long does a wrong decision survive? — and that number moved by orders of magnitude while the debate was still in progress.

Which parts of your process are still paying a price that no longer exists?