In Part 1, the architect updated the plan, and the house was built from revision C of the drawing. Now give the same house a proper backlog. Every wish written down as a story. A versioned brief. Everything captured, nothing lost. And still nobody reopens it. When you want to know what the house looks like, you don't read the backlog. You look at the drawing.
Software is that house, without the drawing.
A few years ago I joined a team and asked the product owner what the application did. His answer: read the tickets we finished. That was five thousand tickets. So I started reading. Then I found a feature that worked completely differently in production than it did in Jira, because a later ticket, far down the list, had changed it. Where do you start, then? "Let me just give you a demo."
At best, a backlog is a wish list of what we wanted. It is not documentation of what we have. And the pressure on that gap is about to rise. At the end of 2025 I started putting stakes in the ground about where this is going:
I'm not sure all four will come true. But if they do, the backlog and the code are all we have left. And neither one tells you what the system is.
It isn't for lack of trying. Every few years the architect in the room spotted something new and ran a proof of concept to see if it moved the needle. First came discipline at the keyboard: extreme programming, pair and mob programming, clean code, CI/CD. All of it lives in habits and people. Discipline leaves no artefact; it walks out of the building at five o'clock.
Then came process around the work. Waterfall wrote everything down once, and nobody opened it again. Teams running Scrum stopped writing things down and called that a virtue. We swung from everything to nothing, and never settled in the middle.
Then came the methods that at least left something behind. Tests. Behaviour-driven development, readable by the business. Domain-driven design and event storming, which gave you an idea of how things should flow. Model-driven architecture and UML. System Design and Project Design. Each one produced an artefact. Not one kept it current. The closer it got to a model, the faster we abandoned it.
Testing tells the same story. End-to-end and integration tests are hard to write and harder to maintain. Unit-test coverage gets reported, not trusted. In Part 1, the factory stopped inspecting every bolt because the line itself became the guarantee. We still inspect every bolt, by hand: unit tests and code review, one function at a time. Once AI assembles code at machine speed, those checks become the bottleneck we can't get past.
The machine shop went from handwheels to readout to program to CAD. Software is walking the same ladder.
We wrote the code ourselves. Then AI assistance arrived: autocomplete, inline suggestions, and you still drive. Then we started writing specs and letting the LLM write the code. Then bigger specs: whole features, several agents across the lifecycle. And now the swarm: you state the intent, a lead agent splits it up, and specialist agents work out the rest. Each step is real progress, and it deserves to be said plainly.
Spec-driven development is a genuine improvement on chatting with a model. The spec is written down, reviewed and committed next to the code. It is the source of truth instead of a throwaway prompt. But after twenty features you have twenty specs and a codebase, and nothing that says how the twenty relate, which boundaries they share, or what breaks when one changes. The specs accumulate. A model doesn't.
The swarm removes real work too: the ticket, the hand-off, the translation from intent into tasks. This is where the industry says software is going, and it isn't a fringe bet.
But look at what's missing from every rung. In the machine shop, once the machine took over the cutting, the drawing became its input. In software, there is still no drawing. Just more text, handed to faster machines.
We hand the LLM a spec and it emits code. It looks like a compiler. It isn't one: a compiler gives you the same output from the same source, every time. Same input, different output. A newer model version, a different temperature, a different context window, and something else comes out. Run it again tomorrow and you may get a third version.
Imagine an assembly line where the car depends on the day: the weather, who's on the floor. Blue on Monday, black on Tuesday. The spec said green. A build you cannot repeat is not a build. We put a non-deterministic step in the middle of the toolchain and called it engineering.
The industry's answer is more agents. A lead agent decomposes the intent, specialists run in parallel, and something comes out. It does come out, and that's true. But two things don't go away.
The first is arithmetic. A chain of steps, each right with probability p, is right with probability p to the power n. Ten steps at 95% each succeed 60% of the time. At 90%, 35%. Better models raise p; they don't change the exponent.
And when researchers at UC Berkeley went through more than 1,600 runs of seven popular multi-agent frameworks (Why Do Multi-Agent LLM Systems Fail?, NeurIPS 2025), one of the three main ways those systems failed was not bad reasoning but misalignment between the agents: agents doing their own part against different assumptions about the same system.
The second is Project Design: planning the build from the dependencies in the design. Nobody knows how to estimate anymore, but there is still a critical path, and there is still a dependency graph. Take five tasks that together are 13 units of work, 11 of them on the critical path. Five agents running flat out save you two units. And the graph is written down nowhere: the swarm infers it again, from the code and the prompts, every run, and maybe differently each time.
You can see it when you trace a real run. In our own agent factory, every stage passes work forward, and a large share of the work goes back to an earlier stage to be redone.
Five agents, five private models of the same system, and one empty sheet where the shared model should be. The swarm does not close the gap. It multiplies it.
So go back to the machine shop. Nobody there hands the CNC machine a paragraph of prose and hopes for the best.
Requirements don't go into code. They change the model. The model goes into a machine that builds the software, deterministically: same model in, same system out, every time. The product comes out the other end. When something is wrong in production, nobody hand-fixes the output. You fix what was wrong in the first place, the model, and run the machine again.
That machine is a compiler, not an LLM, on purpose. The LLM is brilliant at the part before: understanding the requirement, helping to express the change, keeping the model up to date. Once the model is settled, the non-deterministic step comes out.
Intelligence before the model, determinism after it.
Agents still have a place. With a shared model underneath, each agent gets the slice of the model it needs for its activity, and the swarm follows the build plan instead of inventing one.
And the code? Whether the model is kept by hand or with AI, the code is what comes out of it. It is a side effect.
Model-driven architecture is not an idea that failed. It works today, wherever the domain is narrow enough to compile: Simulink in automotive, SCADE in avionics. SysML is standardised and in use. What never happened is model-driven development of general-purpose business software. One notation for every domain fitted none of them, and writing a model precise enough to generate from cost more than writing the code. That second cost is exactly what AI lowers. It's reassuring that some industries kept going. It's not a reason to stop.
There's one leading artefact, and that's not the code.
We've said the model leads. Next time: what it's made of, and where the architect works on it.
