Ask an engineering organisation how much faster it has become and you will be handed two numbers that cannot both be right. Developers report they are somewhere between thirty and sixty per cent faster, and they are not lying; the experience is real, and they can show you the diff. The delivery numbers, measured where work becomes something a customer can use, have barely shifted. The 2024 DORA research found that as AI adoption rose across teams, throughput dipped slightly and stability dipped further.
Both numbers are accurate, which is what makes the gap worth staring at. Something between the keystroke and the delivery numbers is eating the gain, and these articles have spent fifteen articles naming it. The answer has stayed consistent enough to state in one sentence: making went free, the constraint moved somewhere else, and the organisation did not follow it. Money went to the part of the work that had just become cheap. Nothing went to the parts that were always expensive and had merely been hidden behind the labour of typing.
There are five failures underneath the gap. Not one of them is a technology failure, which is why no tool has fixed any of them. They are failures of building: of who builds, of what the building has to carry, and of how the builders relate to each other and to the machines now working alongside them. Building is the subject, and building is what the organisation has quietly stopped being able to do.
1. Brooks sorted this in 1986 and nobody re-read him
Fred Brooks published No Silver Bullet in 1986, and the distinction it draws still sorts every claim anyone makes about an engineering tool. Difficulty in software comes in two kinds. Accidental complexity is the labour surrounding the work: typing, boilerplate, wiring, ceremony, the tax you pay to express an idea in a machine. Essential complexity is the irreducible part: deciding what to build, working out where the seams belong, judging whether the result is any good. Brooks’s claim was that no tool ever touches the second kind. Forty years have not dented it.
AI is the most complete accidental-complexity machine the field has produced. Its effect on that layer is not reduction; it is collapse. The cost of incidental work has fallen far enough to change what the job feels like from the inside, which is why the thirty to sixty per cent is honest. What survives is everything Brooks called essential, and it is now exposed, unsupported, and carrying the whole weight of the outcome.
So the classics did not survive the wave by luck. Modular decomposition, information hiding, small batches, refactoring, review: these are the essential core, left standing once the scaffolding around them came away. The discontinuity and the endurance of the old disciplines are one claim seen from two sides.
Which produces the diagnosis this article is going to argue. Your organisation cannot build because the capabilities that now determine whether a build succeeds were thinly staffed for twenty years and nobody noticed, because typing concealed them. Verification was a background cost. Design was something a few people did on Fridays. Answerability was assumed and never assigned. Remove the concealment and all three are suddenly the job, performed by an organisation that never resourced any of them.
2. Nobody is answerable for the change that just merged
Mark Burgess holds the question of who, or what, builds, and Promise Theory gives the discipline in one line: an agent can promise only what lies inside its own locus of control. Promises are voluntary and best-effort. Impose an obligation from outside and you create what Burgess calls a fictitious coupling, a dependency the system believes in but cannot honour. Fictitious couplings are what make systems brittle, and they are what most AI governance consists of.
Look at what your organisation issued in the past year. An acceptable-use policy, a set of coding standards, prompt guidance, a slide in the all-hands about human oversight. Every one of those is advice offered to somebody who may choose to follow it on a Thursday afternoon when the release is late. Birgitta Boeckeler’s distinction is the operational form of Burgess: guides tell an agent what to do and can be ignored; sensors observe what it actually did and can stop the work. Static analysis is a sensor. A blocked merge is a sensor. A markdown file of standards is a guide, and so is a governance framework, however many pages it runs to. Most organisations, sorting their own controls honestly, find that everything they have is a guide.
Underneath that sits a slower failure. Addy Osmani named the seventy per cent problem: the model gets you most of the way and leaves the last portion, the edge cases, the integration, the production behaviour, exactly as hard as it ever was. Charity Majors has been blunt about what that does to a career ladder, because the first seventy per cent is the work that used to make juniors into seniors. Richard Sennett explains why the loss is not recoverable by training. Craft knowledge is built through resistance: the hand meets a material that pushes back, and the head learns something it could not have been told. Remove the resistance and you remove the mechanism.
Put the three together and the shape is unpleasant. Verification is becoming the whole job at the exact moment the pipeline that produced people capable of verifying is being closed. This is not a prediction. It is arithmetic on a hiring plan.
3. The organisation cannot stop
Taiichi Ohno held that overproduction is the worst of the seven wastes, and his reason was not sentimental. Overproduction manufactures the appearance of progress and hides the other six behind it. A team producing four times the output feels four times as productive and is accruing four times the liability.
Cost was only ever half a tax on production. The other half was the friction restraining overproduction, and that half is gone. Every line you once had to write by hand was a line you thought twice about. Nobody thinks twice now, and the danger has moved from the price of generating to the price of keeping. Generated code cannot be thrown away once it exists; it must be read, maintained, secured and supervised for the life of the system. The bill arrives late and it arrives forever.
Generated code is code. Somebody reads it like code, reviews it like code, patches it like code and audits it like code, and none of those costs fell when the cost of writing the code fell. What changed is how much code there is.
Ohno’s two counter-disciplines are pull and jidoka. Pull means real demand triggers the build, and almost nothing in a modern backlog process can tell real demand from available capacity. Jidoka means stopping the line the instant a defect appears rather than producing confident defective output at volume. Pull and jidoka are both refusals, and refusal is the capacity most organisations have bred out of themselves.
I have sat in a great many steering meetings and I have never once watched an executive receive good news for stopping something. Stopping reads as a throughput failure, so it is renamed a pause, a rebaseline, a phase two. The andon cord exists on every Toyota line because pulling it is safe. In most enterprises it is not safe, and the cord is therefore decorative, which is a fact about the reward system rather than about anyone’s courage.
Lorin Hochstein found the sharpest version of this in the incident world. Using a model to assemble the ingredients of an incident report saves genuine toil. Using one to write the report removes the act in which the organisation learns anything, because the understanding was never in the document; it was in the writing. Any artefact whose value lies in the thinking it forces loses that value the moment it can be produced without the thinking. The document survives. The learning does not.
4. Somebody has to hold the graph
John Ousterhout holds the question of what the build must carry, and his definition of the enemy is precise. Complexity is anything that makes a system hard to understand and change. It shows up as change amplification, where a small modification touches many places; as cognitive load, where somebody must hold too much in their head to proceed; and as unknown unknowns, where it is not even obvious what you would need to know to change something safely. Those three name precisely what generated abundance costs.
His prescription is deep modules behind simple interfaces. The interface is what a person must understand; the depth is what they are spared. Get this right and machine leverage is enormous, because the agent can churn inside the module while a human reasons about the surface. Get it wrong, expose the complexity through a wide shallow interface, and every generated line becomes a line somebody has to comprehend.
Ousterhout is building directly on David Parnas, and Parnas supplies the half the industry dropped. His 1979 paper was called Designing Software for Ease of Extension and Contraction; the field took the extension half and built fifty years of practice on it. Contraction is the property you only discover you lack at the moment you need it. Every system has a uses relation, the graph of which component may invoke which. Where that graph is a hierarchy, every level downward is a shippable subset: you can cut anywhere and what remains still runs. Where it contains loops, the system has exactly one deliverable configuration, which is all of it.
No agent has ever seen your uses relation. Asked to add a capability, it attaches the capability wherever attachment is easiest, which is correct behaviour for the task it was given and corrosive behaviour for the graph. Each edge is defensible. The graph degrades anyway, one reasonable decision at a time, and the loss surfaces two years later when a regulator kills a product line or an acquisition needs one service carved out and the answer comes back that it cannot be separated.
5. The batch got bigger while everyone was talking about speed
Kent Beck and Martin Fowler built a practice on one insight: the way to survive change is to shrink the interval between decision and feedback. Small batches, continuous integration, refactoring as a daily habit. The economics were never in dispute. A small change that breaks tells you what broke it; a large change that breaks tells you almost nothing.
Generation quietly reverses this. A model produces a large, plausible, internally consistent change in one pass, and large plausible changes are precisely what the practice was designed to prevent. Review capacity did not scale with generation capacity, because review is a human act performed at human speed. The measurable signature is already in the data: refactoring is falling as a share of changed lines while short-interval churn climbs, which is what code being generated faster than it is understood looks like from the outside.
Fowler’s design stamina argument is the one to put in front of a board. Neglecting internal quality buys you speed for a few weeks and costs you speed for years, and the crossover arrives sooner than anyone estimates. That argument was made against schedule pressure. It now has to be made against a tool that removes the only remaining reason to keep changes small, which is that they were tiring to write.
The practical correction is deterministic enforcement rather than probabilistic instruction. You cannot prompt your way to a small batch. You can configure a pipeline that refuses one.
6. The topology did not change, and the ritual quietly stopped
Melvin Conway observed in 1968 that a system’s structure copies the communication structure of the organisation that produced it. That has not stopped being true; it has gained a new term. Your organisation chart now holds agents that nobody drew, reporting to nobody, communicating through whichever developer happens to be supervising them. If the architecture you are getting is not the architecture you asked for, the chart is the first place to look, and this year the chart is incomplete.
Matthew Skelton and Manuel Pais gave the operational version in 2019 with cognitive load as the sizing constraint on a team. A stream-aligned team should own no more domain than it can hold in its collective head. The load has just risen sharply, because supervising output you did not write is more expensive than writing it, and almost nobody has reduced a team’s domain to pay for it. Instead the same team owns the same surface and now spends its day reviewing machine drafts of it.
Randall Collins explains what that does to the team itself, and his argument is the least comfortable here. Interaction ritual chains generate emotional energy through bodily co-presence, mutual focus of attention, and shared mood. Energy is a product of particular interactions, and it decays without them. Collins rejects the managerial reading of cadence as a schedule. A stand-up is not a ritual because it recurs; it is a ritual when people are jointly attending to the same thing and leave with more energy than they arrived with.
Four people each running four agents have fewer of those moments than the same four people had in 2019, and the agents supply none of the deficit. An agent can make a promise; it has nothing at stake in keeping it, no relatedness, and no capacity to care whether it holds. That is the structural line between a human and a machine builder, and it falls exactly where the energy is generated.
Stafford Beer closes the section with the shortest test in the series. The purpose of a system is what it does. Whatever your build system claims about quality, its purpose is what it produces in production under load. Judged by that standard, a great many delivery organisations are running a machine for converting review capacity into unreviewed change, and doing it well.
7. Your metrics are working perfectly
Measurement is where the four failures above go invisible, and the dashboard is usually the last instrument anybody thinks to check.
DORA gave the field four measures that earned their authority honestly. Deployment frequency, lead time, change failure rate, time to restore. DX Core 4 extended the frame to speed, effectiveness, quality and impact, and made developer experience something you could measure. They are good instruments, and both are being read badly, because organisations under pressure to show an AI return reach for the two numbers that move fastest and mean least: acceptance rate and lines generated.
Apply Beer’s test to your own dashboard. If the reported measure is volume of generated code, the purpose of that dashboard is to increase volume of generated code, whatever the accompanying narrative says about quality. The metric is not broken. It is working perfectly, and it is producing exactly what it was designed to produce.
The measures worth watching now sit on the other side of the constraint: the ratio of building new to maintaining old, the share of changed lines that are refactoring, the interval between a change being generated and a human accepting it, and the time it takes to answer the question of what would break if you removed something. Nothing on that list flatters anybody in a quarterly review. All four tell you whether you can still build.
8. The five failures are one failure
Taken separately, each of these looks like a discipline problem with a discipline answer. Taken together they compound, and the order of compounding is the same order this series has used since Learning.
Identity fails first. No one is clearly answerable for a merged change, and the people who would have grown into answerability are no longer doing the work that grows it. Information fails next, because an organisation without answerable builders has nobody holding the design, nobody willing to stop the line, and nobody drawing the graph. Interaction fails last and hardest, because the topology and the cadence were the only remaining mechanisms for catching what the first two missed, and both have been degraded without a decision being taken about either.
Say it plainly. Nobody is answerable, nothing gets stopped, nobody holds the graph, the batches keep growing, and the topology stays where it was. Five failures, and each one feeds the next.
They also fail in the same way, which is why listing them separately is slightly misleading. Each one is a failure to stop. A change merges because nobody could stop it without a name against it. A line producing waste keeps running. A dependency joins a graph nobody holds. A batch grows. A topology absorbs agents nobody drew. Stopping is the single capacity underneath all five, and stopping is what free making removed the last natural restraint on. Cost used to stop things. Nothing stops them now except a decision, and a decision of that kind has to be taken by somebody answerable for it.
The failure stays invisible for a long time, and the invisibility is structural. Every individual step is defensible. Every agent addition is reasonable. Every deferred refactor has a good reason on the day. Every unpulled cord protects a date somebody committed to in good faith. The system degrades through a sequence of locally correct choices, which is precisely the mechanism Parnas described for software aging and Ohno described for waste, and it is roughly why exhorting people to be more careful tends not to work.
There is one further reason this wave punishes harder than the last three. When an organisation failed to adopt agile properly, it delivered slower than it might have; the cost was opportunity. When an organisation fails to build properly under free making, it accumulates a system it cannot understand, cannot subtract from, and cannot staff, at a rate limited only by its licence count. The cost is carried, it compounds, and it arrives on a balance sheet rather than in a retrospective.
9. Simplicity is a capacity, not an aesthetic
Each part of this series leaves an organisation with a capacity, and Building leaves simplicity. Not tidiness. The capacity to subtract. Subtract, and you can build. Fail to subtract and you can only add, and you will keep adding until the system you are adding to is a system nobody can hold.
An organisation that can build has three properties a visitor could verify in a morning. Somebody read every merged change and accepted it by name. Controls sit in the pipeline as sensors rather than in a deck as advice. And it can stop: it can kill a feature, halt a release, and remove a component without a fortnight of archaeology.
Everything else here is instrumentation for those three. Deep modules and clean interfaces exist so a person can be answerable for something they can actually understand. Small batches exist so stopping is cheap enough to do. Team topology and cadence exist so the people doing the verifying have the energy and the context to do it. Promise Theory explains why an imposed obligation will not substitute for any of it, and Brooks explains why no tool will.
The uncomfortable part is that none of this is new. I have not described a novel discipline; I have described the practice of good engineering organisations in 2015, now made compulsory. Free making did not invent a new set of virtues. It removed the slack that let organisations get away without them.
The next article closes Building and hands to Transforming, where the question stops being what you can build and becomes what kind of leader you can be while the building changes underneath you.
Where this sits: this is the synthesis that closes Building, the third of the series' four phases; Learning, Deciding, Building, Transforming. The articles on building start at Structure and ask whether an organisation can build an effective response. What an organisation gets out of that work is a system, of software, process, organisation and so on, and a descriptive operational vocabulary nobody could have written in advance. The Build Is the Test opened it, and Why Your Organisation Can't Decide is the matching synthesis one step back.
Further Reading
Fred Brooks: No Silver Bullet: Essence and Accidents of Software Engineering (1986), freely available as Brooks’s own University of North Carolina technical report at https://www.cs.unc.edu/techreports/86-020.pdf. The essay this whole argument rests on, and the fastest way to sort any vendor claim you will hear this year.
John Ousterhout: A Philosophy of Software Design (2nd edition, 2021). Short, opinionated, and more useful the more code your organisation is generating that somebody will later have to understand.
David Parnas with Paul Clements: A Rational Design Process: How and Why to Fake It (1986). Free and brief. The gap between how the work actually happened and what should be written down is probably wider now than at any point since they wrote it.
Mark Burgess: Thinking in Promises: Designing Systems for Cooperation (O’Reilly, 2015). Read it for why coordination by voluntary promise outlasts coordination by command, whether the agents are people or machines.
Taiichi Ohno: Toyota Production System: Beyond Large-Scale Production (Productivity Press, 1988; first published in Japanese, 1978). The origin of overproduction as the worst waste, and the conscience of this whole argument on restraint under abundance.
I write about the industry and its approach in general. None of the opinions or examples in my articles necessarily relate to present or past employers. I draw on conversations with many practitioners and all views are my own.