A change lands in the repository on a Thursday afternoon. Nobody typed it. Two people skim it, the tests are green, and it is approved inside eleven minutes because nine more are queued behind it. Three years ago almost every step in that sequence was expensive, and the expense was doing quiet work nobody had to name.
Making is now the cheap part of building, and these articles have circled one consequence of that: an organisation can produce far more than it can understand, and it pays for what it cannot understand every day the system stays alive. The hypothesis running through this group is that building is what remains when making becomes free. Take out the typing and what is left is judgement, verification, coordination and restraint, which is to say everything that was ever essential about the job. This piece consolidates the group into nine methods. Each one is a diagnostic you can observe this week and a method you can act on.
They fall into three families of question that run through every phase of the series and change only which thinker holds them: Identity, Information and Interaction, which ask who the organisation takes itself to be, what it can see, and how its parts talk to each other. In building, Identity asks who or what is doing the making and what it can be held to. Information asks how precisely the thing being made is described and what the organisation will have to carry once it exists. Interaction asks how teams, components and agents relate while the work is happening. Burgess is the foundational thinker for the first, Ousterhout for the second, Collins for the third. Brooks sits underneath all three, and his distinction between essential and accidental complexity is the instrument that sorts what has changed from what has not.
Two questions sit under all nine. Can anyone still hold this, meaning understand it well enough to answer for it? And can anyone still change it? A system nobody holds is a liability with good test coverage. A system nobody can change is finished, whatever the roadmap says. Most organisations I talk to are losing both at once and measuring neither.
Identity: Who, or What, Builds
The Identity questions are about the builder before anything is built: what it can promise, who answers when the promise fails, and whether the capacity to do this work at all is being renewed or quietly spent. Burgess supplies the frame. An agent, human or otherwise, can only make promises about its own behaviour; an obligation imposed from outside is a statement about the wishes of the imposer, not a fact about what will happen. Autonomy is not something an organisation grants. It is a description of where control already sits, and the only useful question is what each part can promise from where it stands.
1. Ask what the builder can promise. An agent can promise to produce code that compiles, satisfies the tests it was given and matches the interface it was shown. It cannot promise that those were the right tests, that the interface was the right interface, or that the feature was worth having. Those promises were never available to it, because the information they depend on sits outside its locus of control. Most of the trouble organisations are having with agents comes from writing instructions as though they were obligations. Reality then declines to comply. The method: for each class of work you hand to an agent, write two lists, what it can promise and what it cannot, and make sure every item on the second list is held by a named person. The unheld items are your exposure. They are usually the interesting half of the work.
2. Ask who can answer for code nobody wrote. Authorship used to carry accountability without anyone arranging it; the person who wrote the thing understood it, and understanding is what answering for something requires. Generated code cuts that link cleanly, and the review queue is where the consequence shows up. Beck and Fowler made the small single-purpose change the cheapest discipline in software, because a reviewer can hold one. Given a nine-hundred-line diff with four purposes in it, the same reviewer approves the parts that look familiar. A signature on a change you could not explain is not a review. It is an admission. Willison calls the disciplined version of working this way vibe engineering, and what separates it from vibe coding is not the tooling; it is whether a named human is answerable for what shipped. The method: take the last ten merges and ask, for each, whether a named person could describe what it does and what it would break without reopening it. Count the ones where the answer is no. That count is the size of the unowned surface you are now running in production.
3. Ask where the next senior engineer comes from. Sennett spent a career on a single unfashionable claim: skill is made in the doing, and the hand teaches the head. Majors and Osmani describe where the doing now goes. An agent takes a feature from nothing to nearly finished, and nearly is the whole problem, because the last stretch is where the edge cases, the integration and the judgement live. You used to reach that last stretch by walking through the first seventy per cent by hand, badly, several times. We are automating the exact work our seniors were made of. The bill arrives in about five years, which is why nobody is looking at it. The method: name three tasks your juniors learned on three years ago, find out who or what does them now, and put a person deliberately back on at least one of them.
Information: What the Build Can See, and What It Will Carry
The Information questions are about description and cost. Ousterhout is the foundational thinker, and his definition is the one to hold: complexity is whatever makes a system hard to understand or modify. It is not a property of size and it does not arrive in a single bad decision. It accumulates in increments, each of which looked reasonable at the time. Nobody decided to make it this complicated. Free generation multiplies the increments and changes nothing else.
4. Count what you must know to change one thing. Take a small change made in the last fortnight, one that touched a few lines, and ask the engineer what they had to hold in their head to make it safely: which callers depended on the ordering, which flag was still read somewhere, which of the three similar-looking modules was the live one. The number of things that had to be known is the real cost of the change, and no dashboard reports it. Parnas gave the constructive form in 1972. A module earns its boundary by hiding a decision likely to change, so the change stops at the boundary instead of travelling through everything that touched it. The method: run the count on three recent small changes. Where one line required a dozen things to be known, you have found an interface that is not doing its job. Better now than next quarter.
5. Find the intent somewhere other than the code. When generation was expensive, the code was the artefact worth keeping and the specification was a promissory note that went to a wiki to die. That economics has inverted. The code is now the cheap, regenerable part, and the statement of what was wanted, and why, and what must never happen, is the thing that survives and the thing an agent can be held against. The method: pick a module written mostly by a model in the last three months and ask what it was for. If the only answer available is the code itself, you have a system that can be regenerated and not one that can be checked. There is nothing left to check it against.
6. Count what you removed. Ohno put overproduction first among the seven wastes, because it hides the other six and feels like productivity while it happens. Free making removes the only friction that ever restrained it. Generated abundance is not free to discard either; once a thing exists it must be understood, maintained, secured and supervised for the life of the system, so the invoice arrives late and then keeps arriving. Ask a team to add something and you get an estimate. Ask them to remove something and you get a silence. The method: count deletions and retired interfaces alongside the additions, quarter by quarter. A quarter with no removals is a quarter in which the carrying capacity of the team fell, whatever else the numbers said.
Interaction: How the Parts Relate While the Work Happens
The Interaction questions are about relations: between teams, between teams and the software they own, and between people and the things now generating on their behalf. Collins is the foundational thinker, and his account of ritual is the least tool-like idea in this whole group. An interaction ritual, in the account he set out in Interaction Ritual Chains in 2004, needs people assembled, attention on the same thing, a boundary saying who is in it, and something at stake. What comes out is emotional energy, solidarity, and standards the group defends when nobody is watching. A model can supply output all day. It cannot supply one unit of that.
7. Ask what your topology is able to produce. Conway observed that an organisation ships its communication structure, and Skelton and Pais turned the observation into a sizing rule: size the software to the team, one complicated domain per team, and when the software outgrows what the team can hold, split the software. Free generation broke that rule quietly. Software now outgrows its team in weeks, and the team finds out from the length of the review queue. The method: for each team, ask whether it could still explain everything it owns. Where the answer is no, split the software rather than adding another reviewer to the queue; adding reviewers treats the symptom and confirms the disease.
8. Ask what is at stake when the team is together. A stand-up where people report status has nothing at stake and generates nothing; the outcome was fixed before anyone spoke. A design session where two credible options are live, or a review where the change can genuinely be sent back, has stakes, and the group leaves it with more energy than it brought. Collins would say the second is a ritual and the first is an assembly, and only one of them makes standards that hold. The method: find the moment in your week where the team is in the same place, on the same thing, and the outcome is uncertain. Protect it in the calendar. If you cannot find one, that is your finding, and it explains more about your delivery than your tooling does.
9. Ask what your build system actually produces. Beer offered the most unforgiving instrument in the series: the purpose of a system is what it does. Point it at the pipeline. A pipeline that reliably produces green tests over code nobody has read has that as its purpose, whatever the policy says. A review process that approves any diff under a thousand lines the same day has throughput as its purpose. It calls that quality. The same instrument was aimed at the decision process earlier in this series; aimed at the build, it is sharper, because the build leaves evidence. The method: take the last ten changes, write down what the process claims about them (reviewed, verified, wanted) and what it demonstrably did, and treat the gap as the specification of your real build system.
Permanent Principles, Transformed Practice
The nine do two jobs, and separating them is worth a paragraph. Methods one, two, three and five test whether anyone still holds the thing: whether the promises are placed where they can be kept, whether a person can answer for what shipped, whether the skill to answer is still being made, and whether intent survives anywhere outside the generated artefact. Methods four, six and seven test whether anyone can still change it: what a change costs to understand, whether the system can be reduced as well as extended, and whether the shape of the organisation can produce the shape of the software. Methods eight and nine test both, over time, by looking at what the group’s habits and the pipeline actually produce rather than what they were designed to produce.
None of this is new engineering wisdom. That is the point, and it is Brooks’s point. Strip out the accidental complexity, the boilerplate and the glue and the first draft of the test scaffolding, and what remains exposed is the essential kind: what to build, where the boundaries fall, whether the result is any good. Modular decomposition, small reviewable changes, standard work, restraint under abundance, apprenticeship: none of these survived by luck. They are what the job turns out to have been all along, now that the part we mistook for the job has become cheap. The principles are permanent and their practice is transformed, and an organisation that reads the first half without the second will simply do 1998 faster.
Build comes from the Old English byldan, to construct a dwelling, from bold, a house. You build what you then have to live in. Every method here is a way of asking whether the thing being made this quarter is somewhere the organisation can still live in three years, and the reason the question has become urgent is that we have never before been able to build this much this fast without noticing what we were committing to. Carrying capacity, not generation rate, is in my view the binding constraint on every engineering organisation now. You cannot buy more of it with tools. You get it by keeping systems small enough to hold, intent explicit enough to check, and teams whose hands are still on the work.
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.