The Build Is the Test
How building software changes when the cost of making approaches zero...
The Learning phase of this series asked whether an organisation could perceive at all. The Deciding phase asked whether it could design under constraint. Both were preparations. Neither touched the ground. Building is where the ground answers back, and for most of the history of software the ground answered slowly, because making the thing was the expensive part. You specified, you argued, you committed budget, and then you waited months to discover whether any of it was true. The cost of making bought you time you did not want: the lag between deciding and finding out was so long that organisations learned to treat building as a delivery problem, a throughput question, the downstream phase where plans became artefacts. That entire mental model was a side effect of making being hard. It is now obsolete.
Making has become cheap, fast, and close to free. This is the largest discontinuity in building since the move from assembler to high-level languages, and it does not leave the nature of the work untouched; it inverts it. When generation costs almost nothing, the activity whose dominant cost has collapsed is not the same activity wearing new tools. The centre of gravity moves, permanently, from producing the artefact to specifying it, verifying it, integrating it, and governing it for the life of the system. Building is what remains when making becomes free. And what remains has a precise shape, which this phase will spend its length describing: building is a testable hypothesis. Every build is an experiment with a result that can disconfirm. You build to release, and you release to learn. A build that cannot fail is not a test. It is a ritual, and an organisation that runs rituals instead of tests will ship its assumptions intact, all the way to the customer, who will run the test it declined to run.
1. Brooks Is the Engine, Not a Lever
One instrument sorts every thinker in this phase, so pick it up first. In 1986 Fred Brooks drew the distinction the whole phase rests on: accidental versus essential complexity. Accidental complexity is everything incidental to the problem, the syntax, the boilerplate, the glue, the scaffolding, the manual mechanics of getting a well-understood idea to compile and run. Essential complexity is the irreducible difficulty: deciding what to build, working out where the boundaries fall, and judging whether the result is any good. Brooks’s claim, which forty years have not dented, is that no tool touches the essential. Tools only ever absorb the accidental.
This is why Brooks is the engine of the phase rather than one of its levers. He does not occupy a position in the architecture; he runs underneath every position, sorting what AI changes from what it leaves exactly where it was. Hold any practice up to him and it falls into one of two piles. AI is an accidental-complexity machine, and its effect on that layer is not reduction but collapse: it drives the cost of incidental work towards zero, and the collapse is total enough to change the felt nature of the job. But AI cannot touch essential complexity. It cannot tell you what to build, it cannot decide where the seams between your components belong, and it cannot judge whether what came out is good. Those were always the hard parts. They were merely hidden, for decades, behind the labour of typing.
The consequence reframes every classic principle this phase will carry. The old disciplines, modular decomposition, information hiding, small batches, refactoring, are not survivors grudgingly still standing after the AI wave. They are the essential core, left exposed and load-bearing once the incidental scaffolding around them was stripped away. The discontinuity and the endurance of the classics are the same claim seen from two sides. Making went free; what making used to conceal is now the whole job.
2. The Waste Corollary: Free to Make, Expensive to Keep
Free making has a corollary organisations consistently fail to price, and it costs more than anything else in the phase. Cost was never only a tax on production. It was also the only friction that ever restrained overproduction. Every line you had to write by hand was a line you thought twice about. Remove the cost of generation and you remove the restraint, and the danger is not the cost of making the abundance; it is the cost of carrying it. Generated code cannot simply be discarded once it exists. It must be read, understood, maintained, secured, and supervised for the entire life of the system. The bill for free making arrives later, and it arrives forever.
This is where Taiichi Ohno re-enters the series, carried forward from Deciding, because he named this failure mode before software existed. Overproduction is the worst of the seven wastes, Ohno held, precisely because it manufactures the appearance of progress and hides the other six wastes behind it. A team generating four times the code feels four times as productive and is quietly accumulating four times the liability. The evidence is already visible: as AI adoption rises, refactoring falls as a share of changed lines while two-week churn climbs, which is the signature of code being generated faster than it is being understood. David Parnas, also carried here, supplies the long-run name for the result: software aging, the slow degradation of a system whose every line must be maintained whether or not anyone still understands why it exists.
So the phase inverts a comfortable assumption. Lean and agile do not retire under free making; they become existential. Reduce Waste stops being prudent advice and becomes the central survival discipline, because deliberate restraint is the only remaining defence once cost has stopped defending you for free. Pull, not push: you build in response to genuine demand, not because generation happens to be available. This is the first place the testable-hypothesis frame bites. Overproduction is what you get when building stops being a test and becomes mere generation; output with no hypothesis attached, no result anyone intends to read, no way for it to fail. Volume that cannot fail is not progress. It is waste wearing the costume of progress.
3. The Three Levers, and the Warning That Governs Them
This phase, like the two before it, interrogates building through three levers: Identity, Information, and Interaction. The levers are not stages, and forgetting that is the single most common way these diagnostics get broken. They are families of questions you hold up at any moment of building, not a sequence you move through and tick off. Identity asks who, or what, is building, and what it can actually promise. Information asks how the build sees and describes itself, and what it must carry. Interaction asks how teams, components, and agents relate. All three questions are live at every moment; none of them belongs to a phase of the work.
The relationship between the levers and the ELSA transitions is orthogonal, not linear. ELSA tells you where in the movement you are; the levers tell you what to interrogate once you are there. The warning is blunt and it matters: do not map one lever to one ELSA move. That linear reading is wrong, and it breaks the diagnostics, because it tricks you into thinking Identity is something you settle early and Interaction is something you arrange late, when in truth a single build is testing all three at once. When a build runs, it tests whether the team that made it had the capability to make it (Identity and Interaction together), whether the design decisions held up under real load (Information), and whether the parts could coordinate without seizing (Interaction again). The build does not consult the levers in turn. It puts pressure on all of them simultaneously and reports back where the structure gave way.
Each lever has a foundation thinker, and these are the governors the rest of the phase hands off to. Identity is governed by Mark Burgess and Promise Theory. Information is governed by John Ousterhout and the discipline of complexity. Interaction is governed by Randall Collins and the ritual chains that generate the energy a building team runs on. The remainder of this article introduces what each governs and why, so that the phase that follows has somewhere to stand.
4. Identity: Burgess, and What a Builder Can Promise
The Identity lever used to have a settled subject. The builder was a person or a team, and you asked human questions about them: are they capable, do they have judgement, is the apprenticeship pipeline intact. Those questions remain, and they sharpen rather than soften, because AI gets a builder most of the way and leaves the last and hardest portion, the edge cases, the integration, the security, the production behaviour, exactly as hard as it ever was, and harder for the senior who must now supervise work they did not write. Software is an apprenticeship industry; competence is forged over years doing precisely the work AI now absorbs, which puts the pipeline of senior judgement under a threat the phase takes seriously rather than waving away.
But the subject of the Identity lever is now mixed, because some of what builds is not human. This is why Mark Burgess governs the lever rather than a thinker about human craft alone. Promise Theory supplies the formal model for a world of human and agent builders, and its central discipline is severe in the best way: an agent can only promise what lies within its own locus of control, and promises are voluntary and best-effort, never obligations imposed from outside. The moment you impose an obligation from outside, you create what Burgess calls a fictitious coupling, a dependency the system believes in but cannot honour, and fictitious couplings are what make systems brittle. Coordination by voluntary promise is more resilient than coordination by command, and this holds identically for a team of people and a fleet of autonomous agents.
Here the testable-hypothesis frame meets the Identity lever directly. A promise is a testable claim. A component that promises an interface and fails to keep it has not committed a policy violation; it has run a test and returned a result. The build is where promises meet reality and the kept ones are sorted from the broken. Promise Theory then lets us draw one line with unusual precision: an agent can promise, but it has nothing at stake. It has no relatedness, it generates no emotional energy, and it cannot care whether its promise holds. That is not a sentimental observation. It is the structural fact that the Interaction lever is built on, and it is where the discontinuity between human and agent builders is sharpest.
5. Information: Ousterhout, and Complexity as the Enemy
If making is free and the danger is what you must carry, then the discipline that decides how much you carry is design, and design is what the Information lever interrogates. John Ousterhout governs it because he names the enemy precisely: complexity, defined not as difficulty but as anything that makes a system hard to understand and change. Complexity shows up as change amplification, where a simple modification touches many places; as cognitive load, where a developer must hold too much in their head to make progress; and as unknown unknowns, where it is not even clear what you would need to know to change something safely. This is the exact vocabulary for what AI-generated abundance degrades, and for what generated code costs to carry.
Ousterhout’s prescription is the structural answer to free making: deep modules with simple interfaces. A deep module hides a great deal of complexity behind a small, clean surface, which is the only configuration that lets a human supervise machine-generated volume without drowning in it. The interface is what a person must understand; the depth is what they are spared. Get this right and AI leverage is enormous, because the agent can churn inside the module while the human reasons about the interface. Get it wrong, expose the complexity through a wide shallow surface, and every line the machine generates becomes a line a human must now comprehend. Brooks’s engine sorts this immediately: interface design is essential complexity, the part AI cannot do, and it becomes more important as the machine grows more capable, not less. Great design was always the work. Now it is visibly the work.
6. Interaction: Collins, and the Energy a Build Runs On
The Interaction lever asks how the builders relate, and its foundation thinker is the least obvious and the most important for what is coming. Randall Collins, a sociologist, argued that human interaction runs on chains of rituals, and that successful rituals, occasions of bodily co-presence with shared attention and a common mood, generate emotional energy and renew the shared symbols a group organises itself around. Read into a building team, this reframes the entire cadence of the work. The standup, the demo, the retrospective, the incident review are not administrative overhead to be optimised away. They are the interaction rituals where a team’s emotional energy is generated and its sacred symbols, the things it will not ship, the bar it holds itself to, are renewed.
This is where the phase makes its sharpest and least nostalgic claim, and it follows directly from Burgess. An agent can promise, but it cannot generate emotional energy, because it has no body to be co-present with, no mood to share, and nothing at stake in the shared attention. Collins gives the precise mechanism for something many organisations are feeling and failing to name: why an agent-heavy or remote-only configuration can post excellent output and still feel lifeless. The output metrics are met and the ritual chain is starved. This is not an argument against agents or against remote work; it is a structural account of what those configurations cannot supply on their own, so that you can supply it deliberately rather than discover its absence as a slow loss of energy no dashboard explains. Cadence, in this phase, evolves from a team’s rhythm into the irreplaceable generator of the one thing a fleet of agents categorically cannot produce.
7. Where the Build Meets Reality
The phase enters the ELSA cycle at Structure, because a specification must be constructed before it can do anything, and it is inherently iterative: the operational knowledge a build produces feeds back into the next pass. This is not a metaphor for CI/CD. CI/CD is literally this cycle running fast. Every commit is a hypothesis. The pipeline is the test. A red build is disconfirmation, the most useful result of the day, because it changed your mind before the customer did. The speed is the point: the loop closing fast enough that learning compounds rather than arriving too late to act on. The discipline of building well is, in large part, the discipline of running this loop honestly and quickly, and refusing to suppress the red.
When the built thing meets reality, two disciplines carried from earlier phases do the evaluation, and the phase places them here deliberately rather than giving them lever seats of their own. Ohno’s jidoka is the andon cord wired into the build: stop the line the instant a defect appears rather than generate confident, defective output at volume. Stopping is not failure of throughput; it is the refusal to manufacture waste, and under free making, where confident defective output can be generated faster than ever, the andon cord matters more than it ever did on a physical line. And Beer’s POSIWID, the purpose of a system is what it does, is the unforgiving test of the built thing in operation, whatever the specification claimed for it. A build judged by its specification is a build that has not yet been tested. A build judged by what it actually does, in production, under load, is a build that has met reality and reported back. That report, fed to language and carried into the next pass, is the learning that release exists to produce.
One discipline in this phase has no classic analogue. When generation is cheap and trust in the generated output is low, verification becomes the principal engineering discipline rather than a background cost. Verification-at-scale is the binding constraint of building under free making: the work that does not shrink when making shrinks, the place the bottleneck moves to the moment the old bottleneck disappears. The teams that will build well in this phase are not the ones that generate the most. They are the ones that can verify, at scale and at speed, whether what they generated was worth keeping. That is the testable hypothesis made operational. You build to release, you release to learn, and the learning only happens if you are willing and able to read the result.
(An Organisational Prompt is something you can do now....)
Organisational Prompt
This prompt is not a diagnosis of a transformation problem. It is a test of whether your builds are tests.
Pick one build your organisation completed in the last quarter. Not a programme, a single shippable thing: a service, a feature, an automation, an agent. Now ask the question the phase turns on: could it have failed, and would you have known?
Work through it in four passes, and resist the urge to map them to stages; you are interrogating one build from four angles, not walking it through a process.
First, capability. Did the team that built it have what was needed to build it, or did the build quietly reveal a gap, a skill, a piece of context, a missing pair of hands, that you papered over rather than named? The build tests the builder before it tests anything else.
Second, design. When the thing met real load, did your design decisions hold, or did the boundaries you drew turn out to be in the wrong place? A promise a component could not keep is not a failure to discipline. It is a result to read.
Third, learning. What did the build teach you that the design did not already assume? If the honest answer is nothing, you did not run a test; you ran a ritual, and you should be suspicious of how comfortable that felt.
Fourth, waste. How much of what you generated is now something you must carry, understand, and maintain, whether or not it earned its place? The build-new versus maintain ratio is the only number that catches overproduction before it ages into liability.
If you cannot answer the first question, “could it have failed, and would you have known,” then the build was not a test, and you are shipping your assumptions to the only examiner who never declines to mark them: the customer. Wire the andon cord in before you generate the next thing at volume. The whole discipline of building, once making is free, is the discipline of building things that can fail in front of you rather than in front of them.
Further Reading
Fred Brooks: No Silver Bullet: Essence and Accidents of Software Engineering (1986). The essay the whole phase rests on, freely available as Brooks’s own University of North Carolina technical report at https://www.cs.unc.edu/techreports/86-020.pdf. Read it for the distinction between essential and accidental complexity, then keep it beside you, because it sorts every claim anyone will ever make about an engineering tool, this phase included.
John Ousterhout: A Philosophy of Software Design (2nd edition, 2021). The clearest modern statement of complexity as the enemy and deep modules with simple interfaces as the answer. Short, opinionated, and more useful the more code your organisation is generating that someone will later have to understand.
Mark Burgess: Thinking in Promises: Designing Systems for Cooperation (O’Reilly, 2015). Read it for the discipline that an agent can only promise what lies within its own locus of control, and for why coordination by voluntary promise outlasts coordination by command, whether the agents are people or machines.
Randall Collins: Interaction Ritual Chains (Princeton University Press, 2004). Dense sociology, but the source of the phase’s most load-bearing claim about why cadence cannot be automated. Read it for emotional energy, shared symbols, and the structural reason an agent cannot supply either.
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, of jidoka, and of pull over push. Read it as the phase’s conscience on restraint under abundance.
Disclaimer
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.