An icosahedron has twelve vertices, thirty edges and twenty faces. In 1994, in his late sixties and at the end of a career spent telling large organisations that their information architecture was killing them, Stafford Beer published a book proposing that you should organise a meeting in that shape.

Put a topic at each vertex. Put a person on each edge. Because every edge touches exactly two vertices, each of the thirty people is now a member of two topic teams, and each team has five people. Give everybody a critic’s role on two further topics. There is no chair, no top and no bottom, and no agenda handed down, because the twelve topics are generated by the thirty people in the first session. Beer called the group an infoset, called the method Team Syntegrity, and thought it was the most important thing he ever built.

Deciding used Beer for the Viable System Model and for the observation that the purpose of a system is what it does. This article takes the part that got left out. Building’s Interaction lever asks how the parts of a system relate, and syntegrity is the only serious attempt anyone has made to design that relating from first principles.

1. The problem it solves

Beer’s whole career rests on one law, borrowed from Ross Ashby and published in 1956. Only variety can absorb variety. A regulator has to be able to produce at least as many distinct responses as the situation can produce distinct states, and where it cannot, the difference does not vanish. It shows up as the situation doing something you had no way of handling.

Hierarchies deal with this by attenuating. Information is summarised at every level on its way up, because the layer above cannot hold what the layer below knows. Attenuation is not an abuse of the structure; it is the structure. And each summary is a decision about what to leave out, made by somebody with an interest in how the result reads.

The Viable System Model answers this with channels and with the audit path, which lets the centre look directly at operations rather than through the reporting line. Syntegrity answers a different question. Suppose you have thirty people who between them know what needs to be known, and no time to pass it through a hierarchy. What shape should the conversation be?

2. The shape, and why it is that shape

The word fuses synergy with Buckminster Fuller’s tensegrity, a structure that holds itself together through distributed tension rather than through a strong centre. That is the design intent stated in the name.

Two properties of the icosahedron are doing the work. The first is that every person sits at most two nodes from every other, so anything said anywhere can reach anybody in two hops without climbing anything. The second is that no position is distinguishable from any other. Rotate the solid and it looks the same, which means the protocol cannot be gamed by seniority, because seniority has nowhere to sit.

The meeting runs three iterations over about three days. In each, a person is a member of one team, a critic of another, and an observer somewhere else, and the roles rotate. Beer’s term for what happens next is reverberation: an idea raised in the green team on the first morning comes back to you on the second afternoon, altered by two teams you were not in. He analysed the propagation mathematically, with eigenvalues, which tells you something about how seriously he meant it. Practitioners who run these report something in the region of ninety per cent of the information ending up genuinely shared across all thirty.

Since 1994 it has been used on the future of the City of London, at Union Bank of Switzerland, by the Colombian Ministry of the Environment, and by an Israeli and Palestinian group discussing West Bank settlements. This is not a thought experiment.

3. What the last two articles would say about it

Collins would notice immediately that syntegrity satisfies all four of his ritual ingredients by construction. Bodily co-presence over three days. A hard boundary, since the infoset is exactly thirty named people. A mutual focus, because each session addresses one statement. And a shared mood, which three days of that intensity guarantees whether or not anyone intended it.

That is probably the honest explanation of why participants describe syntegrations the way they do. Beer built a machine for manufacturing emotional energy and described it in the language of cybernetics, which is the language he had.

Skelton and Pais would notice something else. Syntegrity is the interaction mode chosen deliberately rather than left to drift, at the largest scale anyone has attempted. Their three modes are a vocabulary for pairs of teams. Syntegrity is a protocol for a whole population, making the same argument at a different scale: the shape of the interaction is a design decision rather than a matter of taste.

4. Attenuation just became free

The reason to care about a thirty-year-old protocol is that its central warning just got much cheaper to ignore.

Beer’s warning was always about attenuation. Every point at which information is summarised on its way to a decision is a point at which variety is destroyed, and the destruction is invisible from above, because what arrives looks complete. The report reads well. It reads well because somebody made it read well.

Summarisation is now free, instantaneous and fluent. Every layer of your organisation can attenuate at machine speed, and the output is more polished than the human version was, which makes it harder rather than easier to notice what has gone. An organisation can now attenuate everything and amplify nothing, and the dashboards will look better than they have ever looked.

Lorin Hochstein made the specific version of this argument about incident reports, and his distinction generalises. Using a model to gather the material is fine. Using it to produce the account removes the act in which somebody had to decide what mattered. Beer would put it more bluntly: you have automated the step where variety is lost and left the step where variety is generated to look after itself.

The syntegrity answer is not to ban summarisation, which is impossible and would be stupid. It is to notice what compensates for the losses. A channel with real capacity, in which thirty people hear each other directly, is the only thing that ever has, and such channels are getting rarer while cheap imitations of them get easier to build.

5. Where the argument runs out

Three honest objections, and the third is the serious one.

It is expensive. Thirty people for three days is a real cost, most organisations will do it once, and once is not an operating model. Beer designed an event, not a way of running a company.

It gets strange. The later formalism drifts into chakras, enneagrams and elaborate colour schemes, and this loses him readers who would otherwise take the geometry seriously. Read the structure and skip the mysticism; the structure stands without it.

The evidence is thin, in the way most organisational evidence is thin, and it is worth saying so plainly rather than leaning on the numbers. The ninety per cent figure comes from practitioners rather than from controlled study. And the people reporting how much the experience changed them had just spent three days in a highly charged group, which Collins would tell you affects the reporting.

None of that touches the underlying claim, which is the one to carry away. The shape of your conversations determines what your organisation can know, and almost nobody designs that shape on purpose.

The next article takes this to measurement, and to what the numbers can and cannot see.

Where this falls: Building, the third of four phases; Learning, Deciding, Building, Transforming. Beer is carried forward from Deciding, where he held Interaction, and POSIWID becomes the unforgiving test: a system in production is judged by what it does, not by what its specification claimed for it. The Build Is the Test opens this stretch of the argument.

(An Organisational Prompt is something you can do now....)

Organisational Prompt

Count the attenuations between the work and the decision.

Take one significant decision you made in the last quarter. Trace backwards to where the information came from, and count the number of times it was summarised on the way. Not the number of layers on the org chart. The number of separate acts of summarising.

For each one, write down two things: who did the summarising, and what they had at stake in how it read. Then mark which of them were done by a person and which by a model, and note that the second kind leaves no trace at all.

Most organisations find four to six, and I have seen nine. Beer’s guarantee inside a syntegration is that nobody is more than two hops from anybody, and the gap between two and six is roughly the amount of variety that never reached you.

Then pick the single attenuation you would most like to remove, and remove it. Sit in the room where the work happens, once, for an afternoon, with nobody presenting. What you learn will be uncomfortable and specific, and it is the thing your reporting line was built to prevent you from learning.

Further Reading

Stafford Beer wrote Beyond Dispute: The Invention of Team Syntegrity in 1994, for Wiley, and it is odd, brilliant and uneven in roughly equal parts. Read the protocol chapters and treat the metaphysics as optional.

Joe Truss and Allenna Leonard: The Coherent Architecture of Team Syntegrity. Free, and the clearest technical account of how the thing is actually run, including the smaller variants for groups that cannot field thirty people.

The International Society for the Systems Sciences primer on Beer is a short free summary of the protocol and of where his work sits, which is a reasonable place to start if the book looks daunting.

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.

There is a sentence in Team Topologies that most readers skate past on the way to the diagrams, and it is the one that matters most this year. Size the software to the team, never the reverse. One complicated domain per team. When the software outgrows what the team can hold, split the software.

Read that against what has happened to your codebase since 2024. The software grew. The team did not. Nobody made a decision and nobody proposed a change to the operating model. The rule broke from a direction Matthew Skelton and Manuel Pais had no reason to anticipate when they published the first edition in 2019.

Conway appeared in this series during Deciding, for the claim that an organisation ships its communication structure. This article picks up what two practitioners built on top of that observation, and what happens to their construction when a large share of the code is written by something that has no place on the org chart.

1. From an observation to a manoeuvre

Conway’s 1968 paper made a descriptive claim. A system’s design copies the communication structure of the organisation that built it, because the interfaces people can negotiate are the interfaces they have conversations across.

Skelton and Pais turned the description into an instruction, and the move is the reverse Conway manoeuvre. If your architecture will end up mirroring your team structure whatever you do, then decide the architecture you want and build the team structure that produces it. Stop drawing target architectures and start drawing target org charts, because only one of those two things is under your control.

Their vocabulary is four team types and three interaction modes, and its value is that it is small enough to hold in a meeting. Stream-aligned teams own a flow of change to some part of the business. Platform teams reduce what stream-aligned teams have to know. Enabling teams raise capability and then leave. Complicated-subsystem teams exist where genuine specialism is unavoidable. The modes are collaboration, self-service, and facilitating, and the discipline is that a pair of teams should be in exactly one mode, deliberately chosen, and should change it deliberately rather than by drift.

The second edition arrived in September 2025 with new case studies. The framework has become the default vocabulary for engineering org design in large organisations, which is worth noting mainly because default vocabularies stop being examined.

2. The constraint underneath all of it

The four types are not the theory. Cognitive load is the theory, and everything else is a consequence.

The idea comes from John Sweller, who distinguished the intrinsic difficulty of the material, the extraneous difficulty added by how it is presented, and the germane effort that actually builds understanding. Their application is a constraint on org design: a team can own only as much domain as it can hold in its collective head. Draw the boundary past that line and you have not created ownership. You have created a name on a wiki page.

This is where the sizing rule comes from, and it is worth stating in the direction they state it. The team is the fixed thing. The software is the variable. When a domain grows past what a team can carry, the answer is to split the software, not to add people to the team, because adding people raises the coordination cost faster than it raises capacity.

Notice that Ousterhout named the same quantity two articles ago from inside the code. For him it is what a developer must hold to make a change safely. Skelton and Pais measure the same quantity at the scale of a team, and use it to decide where boundaries go. Two disciplines, one constraint, arrived at independently.

3. Which direction the rule broke

Now put generation into the model, and notice that it attacks the sizing rule from the side nobody defends.

The intended failure mode is a domain that grows because the business asked for more. That is visible, budgeted and argued about in a room. What is happening instead is that the volume of code inside an unchanged domain boundary has risen sharply while the team roster has not moved. The domain looks the same on the diagram. The amount that must be held to change it safely has gone up, and quite a lot of it was written by an agent, at speed, by somebody who read the diff quickly.

Three responses are available, and only three. Split the software, which is the answer the book gives. Narrow the domain, which means giving something away and is therefore politically expensive. Or accept shallow ownership, in which the team’s name stays on the service and its actual grip on the service quietly weakens.

Almost every organisation is taking the third option, and almost none has decided to.

There is also an uncomfortable dependency between this remedy and the last article but one. Splitting the software is only available if there is something to split along, which means the uses relation has to be a hierarchy rather than a tangle. Parnas’s loops and Skelton’s sizing rule meet here in an unpleasant way. Where generated code has accumulated dependencies nobody drew, the Team Topologies remedy is unavailable in exactly the situations that call for it.

4. The org chart has non-human nodes on it now

Conway’s law does not care whether the communicating parties are people.

Suppose a stream-aligned team’s real interface to a domain runs through an agent, and the agent’s context is a directory of markdown files somebody wrote in March. That arrangement is now part of the communication structure, and the architecture will come to reflect it. Whatever the agent finds easy to attach to is where things will attach. Whatever the agent has no visibility of will drift.

Skelton has been direct about this in his 2026 talks, and his framing is bounded agency. Organisations that had already learned to give humans clear, limited, well-supported autonomy turn out to be well placed to give agents the same thing. The problem has the same shape either way: what may this party do, what may it reach, and through which interface. He is explicit that agents should not have unbounded access to data and resources, which is the platform argument restated for a new kind of consumer.

Which makes the platform question sharper than the framework originally posed it. A platform justifies itself by the cognitive load it removes from stream-aligned teams and by nothing else. If your agents reach around the platform and touch whatever they like, you do not have a platform. You have a set of conventions and a strong hope, and Skelton’s vending-machine test applies unchanged: capabilities should be available through a clear self-service interface, not through a ticket and a favour.

5. What is being claimed, and by whom

A good deal is currently being asserted about how the four types change under AI, and it is worth separating the sources.

The community claims run roughly like this. Stream-aligned teams shrink towards three to five people. Complicated-subsystem teams dissolve because agents absorb specialist implementation. Enabling teams pivot towards context engineering and tool evaluation, and platform becomes the highest-return investment in the organisation. Every one of these is plausible. None of them is yet supported by evidence I would put in front of a board, and they come from commentators rather than from Skelton and Pais, who have been noticeably more careful.

The authors’ own claim is narrower and stronger. The principles were never about humans in particular. They were about any system trying to build and maintain software under a limit on what can be held at once, and that limit does not disappear because some of the holding is being done by a model. Cognitive load is indifferent to what kind of mind is being overwhelmed.

So the useful question for a leader is not which team type is obsolete. It is whether your teams still own what they are named after, and the sizing rule gives you a way to find out that does not depend on anybody’s opinion about the future.

The next articles move to measurement, which is where all of this either shows up in numbers or does not.

Placement: Building, the third of the series' four phases; Learning, Deciding, Building, Transforming. Conway returns here on the Interaction lever, which asks how teams, components and agents relate. In Deciding his law was a warning about what a structure would produce; in Building it is a report on what it did. The Build Is the Test opens this stretch of the argument.

(An Organisational Prompt is something you can do now....)

Organisational Prompt

Ask a team to draw its own domain, and see whether it can.

Take one stream-aligned team. Give them a whiteboard and twenty minutes with no manager present, and ask them to draw everything they own: services, jobs, data stores, integrations, the lot. Then ask each person privately to mark the parts they could change safely on their own next week.

Two numbers come out. The size of the domain, and the fraction of it any individual can actually act on. The gap between them is your cognitive load overrun, and it is the number Team Topologies says should govern your org design.

Then ask when each part was last substantially changed, and by whom. Suppose a meaningful share of the domain was generated in the last year and nobody who works on it marked it as safe to change. That team no longer owns the service in any sense that will hold up at two in the morning. It owns the name.

Three responses exist and you must pick one out loud: split the software, narrow the domain, or say plainly that you are accepting shallow ownership and why. The third is a legitimate choice for a short period. It is not a legitimate accident.

Further Reading

Matthew Skelton and Manuel Pais: Team Topologies (second edition, September 2025). Short, practical, and unusually honest about its own limits, which is rarer in this genre than it should be. The site carries a readiness survey and the new case studies.

Matthew Skelton: Team Topologies as the infrastructure for agency with humans and AI (2026). The authors’ current position on agents, and considerably more restrained than most of what is being written around them. The slides are worth a scroll on their own.

Melvin Conway: How Do Committees Invent? (1968). Free on Conway’s own site, six pages, and it says more than the one line everybody quotes from it.

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.

A team of six ships something difficult on a Thursday afternoon. Somebody says it in the channel, somebody else replies with a picture of a dog in sunglasses, two of them get up and go for coffee still talking about the thing, and by Friday morning the same six people take on a problem they would have flinched at in March. Nothing measurable happened between Thursday and Friday. No process changed, no tool was introduced, no capability was acquired. Something was produced anyway, and every experienced leader has watched it happen and has no vocabulary for it beyond momentum, which explains nothing.

Collins has the vocabulary. His answer is that the thing produced on Thursday afternoon is emotional energy, that it was produced by a ritual, that rituals have four identifiable ingredients and four identifiable outputs, and that the whole business is mechanical enough to design for. This is not a soft claim about culture but a specific account of where a group’s capacity to act comes from, which is why the Interaction lever here belongs to a sociologist rather than an engineer.

Building runs on three lever questions. Identity covers who or what is building and what a builder can honestly promise; Mark Burgess holds that one, and his answer is that an autonomous thing can only promise what lies within its own control. Information covers how the build sees and what it must carry; John Ousterhout holds that one, and his answer is that complexity is the enemy. Interaction covers how teams, components and agents relate, and where the energy comes from to sustain a cadence at all.

Collins holds Interaction. He holds it because the other candidates describe the arrangement of teams while he describes what makes a team a thing rather than a list of names. His account also says most precisely where the human and the agent part company. Agents can produce work. They cannot participate in the ritual, because they have nothing at stake in the outcome, and the ritual is where the energy comes from.

1. What Collins inherited, and from whom

Around 1960, as an undergraduate at Harvard, Collins sat in a lecture where Talcott Parsons explained Durkheim’s account of religion. The claim was not that religion is about belief in the supernatural. Religion began, on Durkheim’s account, as a process by which humans came together in emotional rituals, and those rituals produced symbols standing for membership of the group. Collins describes this as a revelation, and it is worth understanding why. He had grown up attending Protestant churches where nobody seemed especially exercised about theology. What the church actually did was assemble people.

He took a master’s in psychology at Stanford, then went to Berkeley for his doctorate, finishing in 1969 under Herbert Blumer, Reinhard Bendix and Erving Goffman. Both Parsons and Goffman have already appeared in this series, in Learning, which means the Interaction lever in Building runs on a line drawn directly back through it. Goffman gave him the microscope: the study of what actually happens between people in a room, at the scale of seconds. Durkheim gave him the mechanism. Collins spent forty years putting them together.

The result, stated across Conflict Sociology in 1975 and given its full treatment in Interaction Ritual Chains in 2004, is a move most people find counter-intuitive on first contact. The unit of analysis is not the individual but the situation. People are not fixed entities who bring their qualities into encounters; they are the accumulated residue of the encounters they have been through, and they carry different capacities out of different rooms. That inversion is what makes the theory useful to anyone running an organisation, because situations can be designed and personalities cannot.

2. The four ingredients

On what an interaction ritual requires, Collins is precise, and the precision is the value. Four ingredients, and the effect is multiplicative rather than additive.

Bodily co-presence. People in the same physical space, able to affect each other in ways below the level of attention: posture, timing, the small automatic rhythms of turn-taking. Collins is careful that this is not about being able to see faces. He means entrainment, the way people in a room synchronise without deciding to.

A barrier to outsiders. The participants know who is in this and who is not. A ritual with no boundary produces nothing, because there is no group for the solidarity to attach to.

A mutual focus of attention. Everyone attending to the same thing, and, importantly, aware that everyone else is attending to it too. Six people looking at the same screen is not the same as six people each reading the same document alone.

A shared mood. Some common emotional state, which does not have to be a pleasant one. Shared frustration works. Shared fear works, and often works better.

Get all four and they feed back on each other. The shared focus intensifies the shared mood, which sharpens the focus further, and the group enters what Durkheim called collective effervescence and what everyone else calls the meeting where something finally clicked. Get three of the four and you get an event, not a ritual. Attendance is not participation, which every organisation knows and almost none acts on.

3. The four outcomes

When the ingredients combine, four things are produced, and it is worth reading them as outputs of a process rather than as virtues.

Group solidarity. A feeling of membership. Not affection for the individuals, which is a different thing entirely and frequently absent; a sense of belonging to the unit.

Emotional energy in the individual. Collins defines this as a sustained feeling of “confidence, elation, strength, enthusiasm, and initiative in taking action”. Note that last item. Emotional energy is not a mood. Collins is naming a disposition to act, which is why it shows up in behaviour rather than in engagement surveys.

Symbols charged with group significance. The in-joke, the name of the incident, the phrase that means nothing to anyone outside. These are Durkheim’s sacred objects rendered ordinary, and they are how a group carries its solidarity between meetings.

Standards of morality. Violating the symbols starts to feel wrong. This is the part organisations most often try to install directly, through values posters, and it is the one output that cannot be installed directly, because it is a consequence of the other three.

That last observation is worth sitting with if you have ever been handed a culture programme. Values do not produce rituals. Rituals produce values, and in that order only.

4. The energy is in the gathering, not the person

The most useful thing in Collins for a working leader is that emotional energy is produced by situations and carried between them, rather than being a property of a person.

You have seen the evidence yourself. The same engineer is transformed in one team and flat in another. The obvious explanation is fit, or management quality, or a bad manager, and those are sometimes true. Collins’s explanation is more mechanical. The person is running down or charging up depending on the rituals they participate in, and they are drawn, over time, towards interactions that pay out and away from those that drain. People do not choose their meetings on the merits. They choose them on the energy return.

This reframes several persistent puzzles. Your quiet high performer who is unrecognisable in one particular working group is not two people. Your reorganisation that moved the same individuals into different rooms and produced entirely different output was not a coincidence. And the person who has become steadily less initiative-taking over eighteen months has probably not lost their ability; they have been sitting in draining rituals, and emotional energy that is not replenished does not persist.

Collins takes this further than most readers expect. He argues that thinking itself is the internalisation of conversation, so the quality of your internal reasoning is downstream of the encounters you have had. The Sociology of Philosophies, published in 1998, tests this at scale: he traces two and a half thousand years of intellectual creativity and finds it clustered in networks of face-to-face contact between rivals. Great ideas do not come from isolated minds. They come from chains of encounters, and they come disproportionately from people who spent time in rooms with the small number of others working on the same problem.

5. Chains: why a team is a stock, not a state

The word chains does the real work in the title, and it is what makes the theory organisational rather than merely social.

Each ritual is stocked by the ones before it. The symbols charged in June are what allow the group to reach a shared focus quickly in July. The solidarity built during a bad outage in August is what makes an honest and difficult conversation possible in October, when somebody has to say that the approach is not working. A team’s capacity to concentrate together is therefore an accumulated asset rather than a standing property. Like any asset it can be built up, drawn down, or written off in a reorganisation without anyone recording the loss.

This explains the thing that most annoys experienced leaders about org design. You move six people into a new structure that is defensibly better on paper, and productivity falls for two quarters. The usual account is storming and norming, which describes the phenomenon without explaining it, and I have sat through that explanation four times without it ever getting better. Collins explains it: you did not move six people. You destroyed a chain and started a new one at zero, and the new chain has no charged symbols, no established rhythm of attention, and no accumulated solidarity to draw on when something goes wrong.

The corollary is more useful. A team that has been through a real crisis together is worth materially more than the same six people who have not, and nothing in your capability matrix will show it.

6. Your organisation already runs rituals

Every engineering organisation runs interaction rituals continuously. Standups, code review, incident calls, demos, retrospectives, planning, the release. What almost none of them do is ask which of these charge the group and which drain it, though the four ingredients give you a checklist you can apply this week.

Take the standup. A standup where six people give sequential status updates to a manager has one ingredient at best. There is no mutual focus, because everyone is waiting for their turn and thinking about their own item. There is no shared mood, unless mild dread counts. A standup where the team looks together at something that is stuck has all four, and the difference is not the duration or the tooling. What separates them is whether the group is attending to one thing or to six.

Or the incident call. Incidents produce the strongest rituals in most technology organisations, and they do so without anyone designing them. All four ingredients arrive by force: co-presence, an obvious barrier between those on the call and everyone else, a mutual focus nobody has to be reminded of, and a shared mood of considerable intensity. That is why teams that have handled a bad outage together behave differently afterwards, and why the war story becomes a charged symbol within days. And it explains why an organisation that outsources its incident response loses something it did not know it was buying.

The retrospective is the interesting case, because it can go either way. Run well it generates symbols and solidarity. Run as a compliance exercise in which nothing is ever changed, it drains, and worse, it teaches the group that its attention is worthless. A failed ritual is not neutral. Failed rituals cost energy, on Collins’s account, which means the meeting nobody wanted is not zero-impact. That hour is a withdrawal.

In every organisation I have worked in, the reliable signals were behavioural rather than reported. Attendance at optional sessions, whether cameras come on unprompted, whether the conversation continues after the formal end, whether the in-jokes are recent. Those are the observable signals, and they are more reliable than any instrument you can buy.

7. Nothing at stake

Here the argument reaches the discontinuity it has been building towards, and Collins gives it a harder edge than any argument about capability.

An agent can produce work of considerable quality. It can take part in something that looks like a ritual. It appears in the pull request, it responds in the channel, and it can be given a name and a personality if you are that way inclined. What it cannot do is participate in the ritual, and the reason is structural rather than sentimental.

The energy is generated by mutual entrainment among participants who are affected by the outcome. The agent is not affected. It does not carry the residue of Thursday into Friday, does not experience the shared mood, does not find the symbol meaningful, and does not act differently in March because of what happened in November. It has nothing at stake, and having something at stake is the precondition for the energy the group runs on.

Burgess arrives here from the Identity side saying the same thing in a different vocabulary. An agent can promise, because a promise is a statement about behaviour within its own control. What it cannot do is care whether the promise holds. Collins tells you what that costs at the group level. The capacity to sustain a cadence, to hold attention together, and to keep going through a difficult month is produced by people being in it together, and the agent is not.

The practical consequence is uncomfortable for anyone planning a headcount reduction on the strength of a productivity claim. You can replace a large fraction of the typing. You cannot replace a participant in the chain without reducing what the chain generates, and the reduction will not show up in the quarter you make it. It will show up as a team that has become oddly brittle, slower to recover, less willing to take on the difficult thing, with no single decision anyone can point to as the cause.

8. The complications, honestly

Three things make this harder than the argument so far suggests, and the argument is more useful if I name them.

The first is that bodily co-presence, Collins’s first ingredient, was already substantially removed from software work before any agent arrived. Distributed teams have been running weakened rituals for years. Collins addressed this directly in an interview published in Theory and Society in 2024, after a visit to Oslo Metropolitan University, and he is not dismissive of digital interaction. His position is that the mechanism still operates and the intensity is lower, which is roughly what most people report from experience. Video sustains a mutual focus reasonably well and sustains entrainment poorly, because the sub-second rhythms that produce it do not survive the latency.

If you are distributed, the conclusion is not that you are doomed. The conclusion is that your rituals are running at reduced power, and that you need more of them, or occasional high-intensity co-present ones, to charge the same chain. The organisations that fly people in twice a year for something that looks like a jolly are often, without knowing it, doing the only thing that works.

The second complication is that emotional energy resists measurement. Collins has been cited far more than he has been elaborated, and the concept has been criticised for exactly this. Boyns and Luery argued in 2015 that the negative side is underdeveloped: failed and hostile rituals also generate energy of a kind, and a group can be charged by shared contempt as easily as by shared purpose. Anyone who has worked in a high-solidarity team that had turned entirely against the rest of the organisation will recognise the gap.

The third is the one that matters most for how you use this. The theory explains why solidarity forms. It says nothing about whether the group that forms is any good. A tightly bonded team with charged symbols and abundant emotional energy can be building the wrong thing with tremendous conviction, and Collins’s framework will register it as a healthy ritual chain. Solidarity is a capacity, not a virtue, which is why this lever needs the other two to stay honest.

9. What a leader actually does with this

Four things, and none of them is a culture programme.

Treat your meetings as an energy budget rather than a time budget. Every recurring session either charges the group or drains it, and the cost of the draining ones is not the hour but the withdrawal from a chain that took months to build. If a meeting cannot pass the four-ingredient test, either fix it so that it can or stop holding it, and stopping is usually the braver and better option.

Protect the chains when you reorganise. Not the individuals, the chains. The question to ask before moving people is which accumulated groups you are about to write off, and whether the structural improvement is worth more than what those groups can currently do together. Sometimes it is. Most reorganisations never ask.

Design for something at stake. If the outcome does not matter to the people present, no ritual you design will produce anything, and this is the deep problem with a great deal of process theatre. Ownership is not a governance nicety; it is the precondition for the energy that makes ownership work. Consequences shared by the group are what turn a meeting into a ritual.

And be deliberate about where the humans are in the loop, for reasons that have nothing to do with quality control. Collins’s later work with Maren McConnell reads leadership itself as the capacity to generate and direct emotional energy in others, the leader as an amplifier in a chain rather than a source of instructions. If your organisation quietly becomes a set of individuals each supervising their own agents, you will have preserved the output and destroyed the mechanism that produces initiative, and initiative is the thing you actually cannot buy.

The last article in the Interaction group takes this from the individual team to the shape of the whole organisation, which is Conway’s territory and, after him, Team Topologies.

Where this sits: Building, the third of four phases; Learning, Deciding, Building, Transforming. Collins is the foundational thinker on Interaction, the questions about how the builders relate, and his claim is that the energy a team runs on is generated in ritual and cannot be supplied by anything with nothing at stake. The Build Is the Test sets out the argument these articles run on.

(An Organisational Prompt is something you can do now....)

Organisational Prompt

Audit one week of meetings against four ingredients.

Take one team’s calendar for a normal week and list every recurring session. There will be more than you expect, somewhere between eight and twenty for most teams.

Score each one out of four. Co-presence: are people in the same space, physical or as close as you can manage, able to pick up each other’s timing? Barrier: is it clear who is in this group and who is not? Mutual focus: is everyone attending to one thing at once, and do they know the others are? Shared mood: is there any common emotional state, including frustration or urgency?

Anything scoring four is generating energy and should be protected, whatever it costs. Anything scoring one or zero is draining, and the cost is not the hour on the calendar. The cost is a withdrawal from something the team took months to accumulate.

Now do the harder half. For each low-scoring session, ask a single question: does the outcome of this meeting matter to the people in it? If nobody present bears any consequence from what is decided, you cannot fix the ritual by changing its format, because the missing ingredient is not in your gift as a facilitator. The missing piece sits in how you have distributed ownership, which is a structural problem with a calendar invitation attached.

Do this once a quarter. The trend in the scores will tell you more about your organisation’s capacity to do difficult things than any engagement survey you will ever run.

Further Reading

Randall Collins: Interaction Ritual Chains (Princeton University Press, 2004). Dense sociology and worth the effort. Chapters one and two carry the ingredients and outcomes; the rest applies the machinery to smoking, sex and stratification, which tells you how general he thinks the mechanism is.

Randall Collins: The Sociology of Philosophies: A Global Theory of Intellectual Change (Harvard University Press, 1998). Long, and the most persuasive argument I know that ideas are produced by networks of people in rooms rather than by individual brilliance. Read it if you are deciding how much co-location is worth.

Lars Johannessen and Randall Collins: The future of interaction rituals (Theory and Society, 2024). Collins at eighty-three on digital interaction, remote rituals and AI, hedged where the evidence is thin. The most current statement of his own position.

David Boyns and Sarah Luery: Negative Emotional Energy (Social Sciences, 2015). Open access, short, and the sharpest published objection to the optimistic reading of the theory, which makes it the corrective to hand anyone who has started treating solidarity as automatically good.

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.

The last four articles leaned on people who did their thinking between 1972 and 2023. The choice is deliberate, because the classics sort the permanent from the temporary better than anything written last month can. But it leaves an obvious question open, and this article answers it: what are the practitioners closest to the work actually saying right now, and does any of it agree with the theory?

It does, which was not guaranteed. Five people, working from a personal weblog, a consultancy, a newsletter and an incident practice, have converged on the same finding without much coordination. The input mode changed. The discipline did not. And the part that got harder is the part nobody is selling you a tool for.

1. The naming argument is not about naming

In February 2025 Andrej Karpathy coined “vibe coding” for a way of working in which you give in to the vibes, let the model do whatever it does, and accept the result without reading it. The phrase escaped immediately, as good phrases do, and within months it was being used for everything from a weekend hack to a disciplined production workflow.

Simon Willison drew the line on 7 October 2025. Vibe coding, he wrote, is building software through dice rolls without caring what code is produced. What experienced engineers do when they use agents responsibly is a different activity, and he proposed calling it vibe engineering. Karpathy has since suggested “agentic engineering” instead. Addy Osmani backs that on practical grounds: the word “vibe” does not survive contact with an executive. Tell a CTO you are vibe engineering their payment system and watch the face.

The terminology will settle wherever it settles. What the argument is really about is where responsibility sits, and both proposed terms answer it the same way. In one mode nobody is answerable for the code, because nobody read it. In the other somebody is, and that somebody is a person.

2. Willison’s list is a job description, and the job is management

Willison names what vibe engineering requires, and the list is unglamorous: automated testing, planning, documentation, good version control, code review, a deep understanding of what is being built, and what he calls a very weird form of management.

Read that list again with the last three articles in mind. Nothing on it is new. Every item was standard practice in 2015, and most of it was standard in 1995. What has changed is that each item has stopped being a mark of professionalism and started being the mechanism by which work gets verified at all.

The management phrase is the one to sit with. Willison reports running several agents in parallel, finding it surprisingly effective and mentally exhausting, and that combination will be familiar to anyone who has ever run a team of four. You are not typing. You are specifying, delegating, waiting, checking, and deciding what to accept. Holding four contexts you did not personally build is tiring in a specific way. Management has always felt like that, which is why so many strong engineers find their first management job harder than expected.

3. Boeckeler builds the thing Fowler asked for

The last article ended on deterministic enforcement rather than probabilistic prompting. Birgitta Boeckeler has the concrete version, and it is the most useful idea in this article.

She is Thoughtworks’ global lead for AI-assisted software delivery, a role the firm created in July 2023, and she still writes production code, which shows in the specificity of what she says. Her framing is harness engineering. A harness has two halves. Guides tell the agent what to do, and in practice they are markdown files sitting in the repository. Sensors observe what the agent actually did, and in practice they are the tools you already own: static analysis, security scanners, tests, the pipeline. Guides are advice and can be ignored. Sensors are not, and that asymmetry is the whole design.

Her warning is that a harness is not a one-off build. It needs continuous maintenance, because the models underneath it keep changing and a guide tuned to last year’s model can quietly stop steering anything.

Then there is the observation that should worry any executive reading this. Only a small number of organisations, she says, treat AI-assisted delivery as anything more than the introduction of a tool that requires no change management. She is describing a transformation failure rather than an engineering one, which is the diagnosis this whole series has been making from the other direction.

4. Orosz reports the gap

Gergely Orosz is not proposing a theory, and that is his value. He runs the interviews and publishes the numbers, and the numbers keep saying the same uncomfortable thing: individual developers feel considerably faster while organisational delivery moves very little.

I keep returning to what that gap implies. Both halves are true. The engineer is not lying about the experience, and the measurement is not wrong about the outcome. Something between the keystroke and production is absorbing the gain. Everything here has been an attempt to name it: the queue, the coupling, the loops, the unreviewed change nobody can revert in halves.

5. Hochstein knows where it will show up

Lorin Hochstein writes about incidents from inside the resilience engineering tradition, and he has made two observations in the past six months that belong in every board pack on this subject.

The first, in February, is that the industry has produced a great deal of AI tooling for site reliability and almost nothing for incident management. The tools aim at resolving the incident faster. Almost none of them aim at the learning the incident makes available, which is the more valuable of the two and always was.

The second, in June, is sharper. He wrote that he dreads a future of incident reports written by models, and he was careful about why. Using a model to assemble the ingredients of a report saves real toil and he has no objection to it. Using one to write the report removes the act in which the organisation actually learns anything, because the understanding was never in the document. It was in the writing of it.

That is Ohno’s andon cord argument arriving from a different direction, and it generalises well beyond incidents. Any artefact whose value lies in the thinking it forces will lose that value the moment it can be produced without the thinking. The document survives. The learning does not.

6. What the convergence is worth

Five independent observers, no shared employer, no common method, and they agree. The tools changed what a keystroke costs. They did not change what a system costs, who is answerable for it, or what has to be true before you ship. The constraint moved from producing to verifying, and verification still ends with a person deciding to accept the result.

The practical version is short. Somebody must be answerable for every merged change. The guides go in the repository and the sensors go in the pipeline. And the artefacts whose worth is the thinking they force stay written by people, however tempting the alternative becomes.

The next article moves to the Interaction lever, and to why a team’s energy is not a resource an agent can supply.

Where this falls: Building, the third of the series' four phases, after Learning and Deciding and before Transforming. The Identity lever asks who or what is building and what it can actually promise, and directing an agent is that question in its most practical form. What an organisation gets out of that work is a working system and people who can still supervise it. The Build Is the Test opens this stretch of the argument.

(An Organisational Prompt is something you can do now....)

Organisational Prompt

Find out which of your controls are guides and which are sensors.

List every rule your organisation has issued about AI-assisted development in the last year. Coding standards, prompt guidance, the acceptable-use policy, whatever went out in the all-hands deck. You will probably find between five and fifteen.

Now sort each one into two piles. A guide is advice: it tells somebody what to do and depends on them choosing to do it. A sensor observes what actually happened and can stop the work: a failing check, a blocked merge, a scan that refuses. Be strict. If it can be ignored by a busy person on a Thursday, it is a guide.

Most organisations will find every item lands in the first pile. That is not a governance programme; it is a set of hopes, distributed at scale. Pick the two rules you would least like violated and ask what it would take to convert each into something the pipeline enforces.

Then ask who maintains them. A harness tuned to one generation of models stops steering when the models move, and they move faster than your policy review cycle.

Further Reading

Simon Willison: Vibe engineering (October 2025). Short, and the comment thread underneath it is a fair sample of how divided serious engineers still are. His weblog is the single best running record of what is actually working.

Birgitta Boeckeler keeps an index of her own talks and memos, which is the honest way to follow someone whose subject changes every quarter. The Exploring Generative AI memo series on Fowler’s site is where the field observation is written down.

Lorin Hochstein: Surfing Complexity. Start with the piece on LLM-written incident reports and then read backwards. He is the clearest current writer on what automation does to the shape of failure.

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.

Open a pull request from an agent and you will usually find two things tangled together. Somewhere in the diff is a change to what the system does. Everywhere else is a change to how the code is arranged: renamed variables, extracted helpers, a reordered import block, a nested condition flattened because the model preferred it that way. The reviewer now has to work out which lines are which, and there is no reliable way to do it except by reading all of them.

That is a solved problem. It was solved before the agents arrived, by two people who have been arguing for thirty years that the arrangement of code and the behaviour of code are different kinds of thing and should never travel together. Kent Beck states the rule; Martin Fowler wrote the catalogue that makes it operable. The last article left the uses relation degrading one reasonable edge at a time, and asked what keeps a graph clean while cleaning is still cheap. This is the answer, and it is startlingly mundane.

1. The word doing all the work

Fowler’s Refactoring appeared in 1999 and in a second edition in 2018, and its definition contains a phrase that carries the entire discipline: a refactoring is a change to the internal structure of software that does not alter its observable behaviour.

Not “should not”. Does not. If you cannot demonstrate that behaviour was preserved, you did not refactor. You edited, and you now have two uncertainties where you had one: whether the new arrangement is better, and whether the system still does what it did on Friday. The catalogue of named transformations exists because each one is small enough to be verified, and the discipline is the sequence of small verified steps rather than the ambition behind them.

Which makes the guarantee the whole asset. Everything else in the practice is arguably scaffolding around a claim about sameness.

2. Beck’s rule: separate the two, always

Tidy First? runs to under a hundred pages, and its central instruction takes one line: a structural change and a behavioural change never belong in the same commit.

That is a claim about the cost of review rather than about neatness. A structural change can be checked largely by inspection: names moved, shape improved, nothing new asserted. A behavioural change has to be reasoned about, because somebody is claiming the system will now do something it did not do before. Put them in one diff and the reviewer cannot do either job properly, because every structural line has to be examined in case it is smuggling behaviour. Review cost becomes the product of the two rather than the sum.

There is a second reason, and it is usually the one that bites at three in the morning. Mixed commits cannot be reverted in halves. If the behaviour turns out to be wrong you either keep the bad behaviour or throw away good structure, and in practice the team keeps everything and adds a patch on top.

Beck calls the smallest of these structural moves tidyings: extract a variable, delete dead code, add a guard clause, make two things that look different actually look the same. A tidying is a refactoring nobody could reasonably argue about. The question mark in his title is real, and he gives four honest answers to when: first, after, later, never. Tidy first when it makes the next change easier. Tidy after, when finishing taught you something you did not know at the start. Later or never when you are not coming back, and that is a legitimate answer rather than a moral failure.

3. The chain that makes it a business argument

The part of Beck’s book most worth carrying into a leadership meeting is a chain he takes from Larry Constantine, and it is four terms long.

The cost of software is approximately the cost of changing it. Changing it is dominated by the big changes. And the big changes are priced by the coupling. So the cost of your software is your coupling, and almost nothing else you measure touches it.

Nothing in that chain mentions volume, headcount, story points or lines shipped, which is why the numbers on your delivery dashboard have such a weak relationship to what your systems actually cost you. And notice what it implies about generated code. Volume is not the liability. Coupling is the liability, and generation raises coupling by default because each addition attaches wherever attachment was easiest.

Beck is careful not to turn this into a crusade. Decoupling is not free, it has diminishing returns, and reducing coupling in one place tends to make it reappear in another. The aim was never zero.

4. The option went deep in the money, and nobody exercised it

Here is where Beck’s economics become uncomfortable to read.

He treats a tidying as an investment: you pay now, you collect later, and whether it is worth it depends on how soon you will be back and how uncertain the future is. Design creates options, and options are worth more when uncertainty is higher. Structural changes are also far more reversible than behavioural ones, which makes them cheap bets in the technical sense as well as the ordinary one.

Now put free generation into that model. The cost of performing a tidying has collapsed, because an agent will do it in seconds. The value of having tidied has risen, because there is far more code to carry and far more uncertainty about what next quarter’s tooling will make possible. Both sides of the trade moved in the same direction at once, which on Beck’s own reasoning makes structural investment more obviously correct than it has ever been.

And GitClear’s measurements show refactoring falling by around 70 per cent against 2022 levels while duplication rises. The single practice that got cheaper is the practice that stopped. Call that a tooling failure if you like. It looks to me more like an organisation optimising for the thing it can see.

5. What actually broke

The discipline did not lapse through laziness, and the diagnosis matters here, because the wrong one leads to the wrong intervention.

Refactoring requires the behaviour-preservation guarantee, and the guarantee has always come from tests you trust. When the same agent writes the code and the tests, the tests do not check the code; they restate it. Both come from one understanding of what the system should do, so a shared misunderstanding passes green. The suite still runs. It has quietly stopped being evidence.

Fowler’s answer to the analogous problem in security is the one to borrow: move from probabilistic prompting to deterministic enforcement. Do not ask the model nicely to preserve behaviour. Constrain the pipeline so that a commit touching both structure and behaviour cannot merge, and so that the characterisation tests protecting a module were written by somebody who was not generating changes to it. Constraints hold. Instructions in a prompt are mostly a hope with good grammar.

At the Thoughtworks retreat in Utah last February, fifty or so practitioners spent a day and a half on the future of the profession. One of the eight themes they landed on was the question of where the rigour goes now. Good question. This pair give the most concrete available answer to it. It goes into the shape of the commit, and into whatever the pipeline refuses to let through.

The next article goes to the practitioners writing about this in public.

Placement: Building, the third of four phases; Learning, Deciding, Building, Transforming. Small batches belong to the Information lever, which asks what a build must carry and how clearly it can be read. Building enters the cycle at Structure and runs it fast, which is what makes a commit a hypothesis rather than a delivery. The Build Is the Test opens this stretch of the argument.

(An Organisational Prompt is something you can do now....)

Organisational Prompt

Split one pull request in half.

Take the next substantial change your team ships, and require it to arrive as two pull requests: one that changes structure and changes nothing else, and one that changes behaviour and touches structure not at all. Do not announce a policy. Do it once, with one team, and watch what happens.

Three things usually happen. Somebody will discover that the split is harder than expected, which tells you the module is more coupled than anyone believed. The structural half will review in a fraction of the time, and that difference is what mixed diffs have been costing you all year. And somebody will probably ask whether the tests actually prove that behaviour was preserved.

If the answer to the third is that the tests were generated alongside the code, you do not have a behaviour-preservation guarantee. You have a suite that agrees with itself. Fix that before you scale anything.

Further Reading

Kent Beck asks the question in his title, Tidy First? A Personal Exercise in Empirical Software Design (O’Reilly, 2023). It runs to under a hundred pages, and the last third, on coupling, cohesion and optionality, is what to read if you decide where the money goes. He develops the rest of the series in public at tidyfirst.substack.com.

Martin Fowler: the refactoring catalogue is free online and remains the reference. The book around it is worth owning; the catalogue alone is enough to change how a team talks.

Martin Fowler and Unmesh Joshi: LLMs and Building Abstractions (2025), a published email exchange rather than an essay, which is why it is more honest than most of what has been written on the subject. Fowler’s fragments from the February 2026 retreat are the shortest route to what serious practitioners are currently unsure about.

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.

Ask a team to add a feature and you will get an estimate. Ask the same team to remove one and watch what happens. There is a pause, then a set of questions nobody can answer: what else calls it, what would break, whether anyone still uses the reporting job that reads its table. The estimate, when it eventually comes, is larger than the estimate for building it in the first place. Everybody accepts this as the natural order of things, and I have never once heard it questioned in a planning session.

Parnas did not. In March 1979 he published a paper in IEEE Transactions on Software Engineering whose title contains the word almost nobody carried forward: “Designing Software for Ease of Extension and Contraction”. The industry took the extension half, built a fifty-year practice on it, and quietly dropped the other. Deciding used Parnas for information hiding and for where to draw a boundary. Building needs the half nobody read, because a system you cannot subtract from is a system you have stopped being able to change, and free generation is producing those at a rate no organisation has previously managed.

1. You are not building a program

Three years before the contraction paper, Parnas published a shorter one with a claim that still sounds strange: you are never designing a program. You are designing a family of programs, and the one you happen to ship is a member of it.

The reasoning is unsentimental. Any system that survives will exist in variants: an early release with less in it, a customer-specific version, a stripped build for a constrained environment, next year’s edition without the module that regulation killed. Those variants exist whether or not you designed for them. If you did not, each one is produced by mutilation, and the mutilations accumulate.

Designing the family means making the decisions common to all members first and holding them stable, then isolating the decisions that distinguish one member from another so they can be changed without disturbing the rest. That asks for a judgement about which parts of the system are the family and which parts are this particular member. The judgement has to be made early, when it is least comfortable and most valuable.

2. The relation that decides everything

The mechanism Parnas gives for this is the part worth taking away, and it is one line of graph theory.

Every system has a uses relation: which components are permitted to invoke which. Draw it and you have a picture of your real architecture, which is usually not the picture on the wall. Where the relation is a hierarchy, with no loops in it, something useful follows. Every level downward is a working subset. You can cut at any point and what remains still runs, still passes its tests, still does something useful. You can ship it early, test it in pieces, tailor it to a customer, and contract it when a feature dies.

If the relation contains loops, none of that is available. A depends on B which depends back on A, and the two are now one thing regardless of what the directory structure says. The system has exactly one deliverable configuration, which is all of it. Removing anything means unpicking the loop, and unpicking the loop means understanding both halves at once, which is the condition Ousterhout called cognitive load and which is why nobody does it.

Parnas is stricter than most architects about when the relation is allowed to grow. A should use B only if B genuinely simplifies A, only if A is not badly degraded without B, and only if there is some useful subset containing B but not A. Those are three conditions, and a dependency that fails any of them should not exist. I have never seen an organisation apply a test of that severity, which is roughly why almost every large system I have worked in is a tangle.

3. Nobody draws the graph any more

Here is what changes when the code is generated.

An agent asked to add a capability will attach it wherever attachment is easiest. It has the local context and it optimises for the change in front of it, which is exactly the right behaviour for the task it was given and exactly the wrong behaviour for the uses relation. It has no view of the graph, no opinion about whether this dependency creates a loop, and no reason to propose that the surrounding structure should move so the new thing can sit cleanly. Each addition is defensible. The graph degrades anyway, one reasonable edge at a time, which is the same mechanism the last article described for waste and the same one Parnas described for aging.

The four flaws he blamed for uncontractable systems read now like a description of generated code. Components that serve two purposes at once. Components that depend on each other in a loop. Chains in which each link assumes the next one is there. And data structures shared widely enough that removing anything breaks something three services away. Nobody sets out to produce these. They are what you get when volume rises and nobody is holding the graph.

And the loss is invisible for a long time, because contraction is a property you only discover you lack at the moment you need it. Extension keeps working. The system keeps accepting features. Then a regulator kills a product line, or a customer wants the small version, or an acquisition needs one service carved out, and the answer comes back that it cannot be separated. That answer was determined two years earlier by a set of edges nobody looked at.

4. It was actually done

The usual objection is that this is academic, so it is worth knowing that Parnas built it.

From 1977 he led work at the US Naval Research Laboratory to rebuild the flight software of the A-7E, a carrier-based attack aircraft, using his own method under real constraints: real memory limits, real weapons, real pilots. The project produced a module guide, a precise requirements document, and a structure in which the documentation was a product with its own design rather than a residue of coding. As far as I know it is one of very few occasions in the history of the field when a design theory was tested at full scale by the person who proposed it.

Which matters for what happens next. Documentation written after the fact, describing what the code does, is worth very little now, because a model will produce that on demand and produce it faster than you can read it. What a model cannot produce is the graph you intended, the subsets you meant to be able to ship, the dependencies you decided to forbid. Those are constraints rather than descriptions. They have to be stated in advance, and something has to enforce them, or they do not exist.

5. The refusal

There is one more thing in Parnas that belongs in a series about how organisations change, and it has nothing to do with modules.

On 28 June 1985 he resigned from the SDIO Panel on Computing in Support of Battle Management, the group advising the Strategic Defense Initiative on whether its software could be built. With his resignation letter he submitted eight short essays, later published together as “Software Aspects of Strategic Defense Systems”. His ground was narrow and technical. The software could not be made trustworthy, because it could never be tested under the conditions of its only real use, and no amount of funding changes that. He was being paid a great deal to say something else. He said he did not wish to take part in misleading the public, and he left.

MacIntyre’s virtues sit underneath this whole series, and this is the cleanest case of them operating inside a technical practice. Truthfulness about what the discipline can deliver, and courage. Every senior engineer currently being asked whether a generated system is safe to ship is standing in a smaller version of that room, with the money pointing one way and the evidence the other. The question of what you will put your name to is not separate from the engineering. It is the last part of it.

The next article picks up the practice that keeps a graph clean while it is still cheap, which is Beck and Fowler on small batches and refactoring.

Where this sits: Building, the third of the series' four phases; Learning, Deciding, Building, Transforming. Parnas is carried forward from Deciding into the Information lever, the one that asks how a build sees and describes itself, and the ability to delete is the sharpest test of whether it can. What an organisation gets out of that work is a working system and the capacity to take things out of it. The Build Is the Test sets out the argument these articles run on.

(An Organisational Prompt is something you can do now....)

Organisational Prompt

Try to remove something.

Pick a feature your organisation no longer needs. It exists: an old integration, a report two people open, a payment method retired in 2023, something behind a flag that has been off for a year. Choose one that is genuinely dead, so nobody can hide behind the argument that a customer might want it.

Now ask a team to remove it, and time the answer rather than the work. How long before somebody can say with confidence what else would break? If the answer arrives in an afternoon, your uses relation is a hierarchy and you can still change your system. If it takes a fortnight and three meetings, you have loops, and the loops are the reason every estimate you receive is larger than it should be.

Then do the harder version. Ask what the minimal useful subset of your most important system would be: the smallest thing that could be shipped and still do something worth paying for. If nobody can name it, the system has one configuration, which is all of it, and you are carrying every line of it into every future decision you make about the business.

Do this once a quarter with a different system. The trend is the finding.

Further Reading

David Parnas: Designing Software for Ease of Extension and Contraction (IEEE Transactions on Software Engineering, March 1979). The paper is behind a paywall; Adrian Colyer’s summary is the best free account of it, and covers the uses relation and the four flaws.

David Parnas: Software Aspects of Strategic Defense Systems (American Scientist, 1985, and later Communications of the ACM). The eight essays that accompanied the resignation, free in full. Read the first three for the argument about why some systems cannot be trusted, and read all of them for the tone of a professional declining to be useful.

Parnas again, with Paul Clements: A Rational Design Process: How and Why to Fake It (1986). Free, short, and more relevant now than when it was written, because the gap between how the work happened and what should be recorded has never been wider.

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.

Two numbers from CircleCI’s 2026 delivery report, which nobody reads together. Across all projects, average daily workflow runs rose 59 per cent year on year, an enormous increase in activity by any measure you like. For the median team, feature-branch throughput rose 15 per cent while main-branch throughput fell 7 per cent. More work started. Less work finished. The gap between those two figures is where the whole story of AI-assisted building currently lives.

Ohno had a word for that gap, and it is not the word anyone quotes. He is remembered for muda, waste, and for the seven categories that made waste visible to a shop floor that had been swimming in it. But he was explicit that muda is downstream. The root is mura, unevenness, and mura produces both muri, overburden, and muda. Attack the waste without attacking the unevenness and you are treating a symptom, which is probably why waste-elimination programmes have to be run again every three years. Deciding used Ohno for seeing: gemba, standard work, the five whys. Building needs the part of him that is about flow, because free making has installed unevenness at the centre of the way software now gets produced, and almost nobody has named it.

1. You installed unevenness deliberately

Consider what an engineering organisation actually is: a flow with a generation step and a verification step. Somebody produces a change; somebody else, or the same person on a different day, works out whether it is safe, correct and comprehensible enough to keep. Until about three years ago those two steps ran at roughly comparable speeds, because both were performed by humans reading and writing at human pace. The balance was invisible precisely because it was never in question.

Then one side of the flow got a hundred times faster and the other did not.

That is mura in its purest form. Not a mistake, not misuse, not a tooling problem: a structural mismatch between the rate at which one step can produce and the rate at which the next can absorb. Faros AI’s telemetry across more than 10,000 developers found teams with high AI adoption completing 21 per cent more tasks and merging 98 per cent more pull requests. Over the same period review time rose 91 per cent, and average pull request size rose 154 per cent. LinearB’s 2026 benchmarks, drawn from 8.1 million pull requests, found agentic pull requests waiting 5.3 times longer than unassisted ones before a reviewer even picked them up: 1,055 minutes against 201. The generation step improved enormously. The flow did not.

The consequences arrive in Ohno’s order. Muri lands on the reviewers, who are now asked to absorb twice the volume in change sets two and a half times the size, written by someone who was not present for the decisions. Ousterhout gave the last article the name for what that feels like from inside: cognitive load, the amount a person must hold in their head to act safely. Muri is cognitive load measured on a queue rather than on an individual. And then the muda follows, exactly as predicted, in GitClear’s numbers. Refactoring is down around 70 per cent against 2022 levels, duplicated blocks are up 81 per cent, and copy-pasted code climbed from 9.4 per cent of new code in 2022 to 15.7 per cent by early 2026.

2. The queue is inventory

Ohno’s most counter-intuitive teaching was about inventory, and it is the one that translates here without losing anything.

Conventional manufacturing regarded work in progress as an asset. Stock between stations meant no station ever starved; buffers absorbed variation; the line kept moving. Ohno insisted the opposite. Inventory was a waste in its own right, and worse, it was the waste that concealed all the others. A deep buffer means a defect can sit for a week before anyone downstream sees it, by which point the conditions that produced it are gone and so is the person who could explain them. Every problem your buffer absorbs is a problem you have paid for and not learned from.

An unreviewed branch is inventory. So is a merged change nobody has read, a generated module with no owner, a feature behind a flag that has been off for five months. It has all the properties Ohno objected to: it looks like progress, it sits between stations, it hides defects by delaying their discovery, and it costs money to hold in a currency nobody records.

His image for this was a lake. Lower the water and the rocks appear. The rocks were always there; the water was what let you pretend otherwise. The instruction is to lower the level on purpose, hit the rocks, and fix them, and it is the opposite of every instinct a delivery organisation has, because rocks look like incidents and water looks like resilience.

3. Who pulled this?

Which brings the question that survives the translation from a Toyota plant to a codebase with nothing lost at all.

Pull, not push. Push means you produce because you have the capacity to produce, and you send the output downstream because that is where output goes. Under pull, nothing is made until something downstream signals that it is needed. The signal is the authorisation. No signal, no work, however idle the machine.

So: who pulled this? A customer waiting, a defect reproducing in production, a hypothesis that cannot be settled without building the thing, a regulator with a date. Those are pull signals. “We had the tool available”, “it was in the backlog”, “the agent was running anyway” and “it seemed like it would be useful later” are not. Those are push. And push under free generation has no ceiling, because the ceiling used to be the cost of writing the code by hand.

Ask the question of a week’s output in any large engineering organisation right now and the honest proportion with a real pull signal behind it is uncomfortable. I have not seen a leadership team that could answer it from data, which is itself the finding.

4. Levelling, and what it costs you to do it

Ohno’s remedy for mura is heijunka, levelling: match the rate of release to the rate the next step can absorb. On a plant floor that means a mixed, steady sequence rather than long batches of one thing. In software it means a cap on how much change can be open at once, which sounds administrative and is actually the hardest political act available to a technology leader.

The reason it is hard is that levelling looks like deliberately going slower, and every visible metric will confirm that impression for a quarter. Pull request counts fall. Individual engineers, who genuinely feel more productive with an agent, will say so, and they are not wrong about the feeling. LinearB’s data catches the shape of it: developers reported feeling around 20 per cent faster while measuring around 19 per cent slower. That is a 39-point gap between what the work feels like and what it does. A leader who levels chooses the measurement over the feeling, in public, against people whose own experience contradicts them.

But note what levelling actually restrains. It does not cap ambition or ration the tools. It caps the amount of unfinished, unverified, unowned change permitted to exist at one time, which is a cap on inventory rather than on work. And it converts the invisible cost of the queue into a visible cost at the front: somebody has to decide what not to start this week. That decision was always being made. It was simply being made later, by whoever eventually gave up on the branch.

5. The constraint moved and nobody sent a memo

Goldratt’s rule holds here with unusual force. Improving anything other than the constraint improves nothing. For thirty years the constraint in software delivery was authorship, so every tool, method and hiring decision was aimed at producing code faster, and that aim became so deeply assumed that it stopped looking like a choice.

The constraint has moved to verification. Everything downstream of the keystroke, review, integration, environments, comprehension, is now the narrow part, which is why organisation-level DORA metrics have stubbornly refused to improve in the studies while individual-level metrics have soared. Pointing more generation at a verification constraint does not raise throughput. It raises inventory, and inventory is where the bill accumulates.

Ohno built his system for a factory that could out-produce its own ability to absorb what it made, which may be the fairest description currently available of a modern engineering organisation. Hence a man who died in 1990, and never worked on software, being one of the more useful people to read this year. The next article stays with what happens to code that nobody understands well enough to change, which is Parnas’s territory and the long-run price of everything described here.

Where this sits: Building, the third of four phases; Learning, Deciding, Building, Transforming. Ohno arrives here carried forward from Deciding, where he held Information, because overproduction is what free making does to a build. What an organisation gets out of that work is a working system and the discipline to subtract from it. The Build Is the Test opens this stretch of the argument, and From Deciding to Building is the bridge into it.

(An Organisational Prompt is something you can do now....)

Organisational Prompt

Count your inventory, then ask who pulled it.

Take one team and one week. Count four things: pull requests opened, pull requests merged, the age of the oldest open branch, and the number of merged changes nobody outside the author has read. That last one will require asking rather than querying, and the asking is part of the exercise.

Then take a sample of ten merged changes and ask a single question of each: who pulled this? Name the customer, the defect, the hypothesis or the date. Not the ticket, which records that somebody wanted it, but the demand signal underneath the ticket.

Sort the ten into pulled and pushed. Do not argue about the borderline cases; put them in pushed, because a pull signal you have to argue for is not one.

Now show your leadership team two numbers side by side: opened against merged, and pulled against pushed. If opened exceeds merged you are accumulating inventory, and the gap is compounding while you look at it. If pushed exceeds pulled you are running a push system with the cost cap removed, and Ohno would tell you what that produces, because he watched it happen to people who thought full shelves meant a good month.

Further Reading

Taiichi Ohno: Toyota Production System: Beyond Large-Scale Production (Productivity Press, 1988; first published in Japanese, 1978). Short, blunt, and much stranger than its reputation. Read chapters one and two for pull and for why he treats inventory as a moral failing rather than a working capital line.

GitClear’s AI code quality research, now spanning hundreds of millions of changed lines, is the longest continuous measurement of what generated code is doing to maintainability. Read the duplication and churn series rather than the headline.

LinearB’s engineering benchmarks and CircleCI’s state of software delivery are the two datasets large enough to separate activity from throughput. The split between feature-branch and main-branch numbers is the single most useful thing in either.

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.

A senior engineer takes a two-line change and spends three days on it. The change is not hard. Before she can make it she has to work out which of the eleven call sites depend on the ordering, why the retry sits in the caller rather than in the client, and whether the flag she is about to set is still read anywhere after the migration that was meant to delete it in 2023. It ships on Thursday. At the retrospective everybody agrees it was a small change.

That is the tax. It is paid by whoever arrives next, it appears on no plan, and nobody ever decided to levy it.

This phase of the series asks three questions about building: what a builder is and what a builder can promise, what a builder has to know, and what holds a team together while it works. Burgess answered the first. John Ousterhout answers the second, and he answers it in a way that makes the question harder and more useful at the same time.

The information question changed shape when we crossed into building. In the learning phase it was whether the truth could travel: whether the organisation could hear what it did not want to hear. In the deciding phase it was whether you were standing at the real place when you chose, or looking at a model of it from four floors up. Both are diagnostic. Both ask what is the case. Building flips the register. The question is no longer whether you can see, but what you must now make visible to the person who comes after you, and what it costs them when you do not.

Ousterhout has spent forty-five years on both sides of that question. He built Magic and Caesar at Berkeley in the early eighties and won the Grace Murray Hopper Award for them in 1987. He created Tcl in 1988 and Tk shortly after, which took the ACM Software System Award in 1997. With Mendel Rosenblum he produced the first log-structured file system, an idea now sitting underneath most of the flash storage in the world. He left for Sun, founded two companies, came back to Stanford in 2008, supervised the work that produced Raft, and at seventy he was submitting patches to the Linux kernel. In 2018 he published a short book called A Philosophy of Software Design, and it has done more to change how good engineers argue about code than anything else this century.

The book is about one thing. Here is the sentence that carries it.

1. Complexity has a definition, and it has nothing to do with size

Ousterhout defines complexity as anything about the structure of a system that makes it hard to understand or to modify.

Read that again, because the definition is doing more work than it appears to. It says nothing about how large the system is. It says nothing about how clever the algorithm is, how many services there are, or how many lines you have. A four-hundred-thousand-line system can be simple. A four-hundred-line service can be a swamp. Complexity is not a measure of the thing; it is a measure of what the thing does to the person trying to work on it.

That makes complexity an information property, which is why Ousterhout holds this lever rather than one of the others.

He gives three symptoms. Change amplification is when an apparently simple change has to be made in many places. Cognitive load is the amount a developer must hold in their head before they can make a change safely. Unknown unknowns is when it is not even apparent what needs to be changed, so you make your change, it passes review, it passes the tests, and something falls over in a region you have never visited.

He calls the third the worst, and he is right. The first two announce themselves. You feel the tedium of change amplification and you feel the weight of cognitive load. Unknown unknowns feel like nothing at all until the incident.

Underneath the symptoms he puts two causes. Dependencies are where a piece of code cannot be understood or changed in isolation. Obscurity is where important information is not obvious. Every symptom traces back to one of them, and both are about information: how much of it a person has to gather, and how hard it is to find.

So the constructive form of the information question in building is this. What must somebody know before they can safely change this, and who pays to find out?

2. It arrives one reasonable decision at a time

Nobody sets out to make a system complicated, and that is why it is so hard to stop.

Each dependency was justified on the day it was added. Each special case had a real reason behind it. Each shortcut was taken by somebody under a deadline you also thought was reasonable, and each of them made a note to come back. Ousterhout’s word for this is incremental, and it is the most important thing he says about the mechanism. Complexity is not created by bad decisions. It accumulates through a very large number of small ones, none of which looks wrong on the day it is made.

Which is exactly why no review catches it. A code review looks at a change. Complexity does not live in the change. It lives in the sum, and nobody is assigned to read the sum.

I have watched this argument play out in a dozen rooms and it always goes the same way. Somebody says the codebase is a mess. Somebody else asks for an example. The example gets defended successfully, because the example was reasonable, and the meeting concludes that the codebase is fine. Everyone leaves knowing it is not fine and unable to prove it. The evidence is distributed across three hundred small choices, and the argument format only admits one at a time.

Now put agents on it.

If complexity accumulates through the rate of individually reasonable decisions, and you have just multiplied that rate, you have multiplied the accumulation. Not the defect rate; the tests still pass. The accumulation. Ousterhout’s own view, given in an interview in April 2025, is that current AI coding tools behave rather like the fastest and least disciplined engineer you have ever employed: quick output, quick fixes, and a bill that lands on everybody else. He does not think this makes design less important. He thinks design becomes the scarce skill, because the volume of code that somebody eventually has to understand has gone up and the number of people available to understand it has not.

That is the discontinuity these articles are built around, stated as precisely as anyone has stated it.

3. The interface is the price

Here is the idea that reorganises everything else.

A module has two faces. The interface is what a user of the module must know to use it. The implementation is what the module actually does. Ousterhout’s move is to treat the interface as a cost and the implementation as a benefit, and to say that a good module is one where the ratio between them is large. He calls those deep modules: substantial functionality, small surface.

The canonical example is Unix file input and output. Five calls, roughly. Open, read, write, seek, close. Underneath them sit disk scheduling, buffer cache management, block allocation, permission checks, journalling, and forty years of accumulated device handling. That interface fits on a postcard. The implementation is a career. That ratio is why the abstraction survived every hardware generation since 1970 while almost everything built on top of it has been replaced twice.

The opposite is a shallow module: an interface that costs about as much to learn as the implementation saves you. A class that wraps a single field with a getter and a setter is shallow. A method that exists to give a name to two lines used in one place is shallow. Ousterhout has a word for the disease of producing them at scale, which is classitis, and his claim is the one that gets him into trouble. Decomposition is not free. Every boundary you draw has to be learned by somebody, and if you draw enough of them for their own sake you will produce more complexity than you removed.

This is where he and Robert Martin publicly disagree, and the disagreement is worth reading in full because both men wrote it together and neither backed down. Martin’s position in Clean Code is that methods should be small, and then smaller. Ousterhout’s is that a method extracted from tightly coupled logic does not remove the coupling, it just spreads it across a dozen stack frames, and now the reader has to hold all twelve. They agree entirely that boundaries matter. They disagree about where a boundary belongs. That argument does not resolve, and it should not, because the answer is different for every module, which is why it takes judgement rather than a rule.

Note what happened to Parnas here. Parnas said, in 1972, that a module should hide the design decisions most likely to change. Ousterhout keeps that and adds a price. Information hiding tells you what belongs behind the wall; depth tells you whether the wall was worth building.

The second edition of the book, published in 2021, pushed this further. General-purpose modules are deeper. A module built for exactly the case in front of you tends to have an interface shaped like that case, which means the next case needs a second interface, and then a third. The slightly more general design usually has fewer total moving parts across the life of the system.

4. Tactical, strategic, and the tornado you promoted

Ousterhout splits programmers by what they are actually optimising for.

Tactical programming takes working code as the goal. Get the feature out, get the bug closed, and design is whatever happens on the way. Strategic programming takes a good design as the goal, and treats working code as necessary rather than sufficient. He is not describing two skill levels. He is describing two objective functions, and the tactical one is the default in almost every organisation because it is the one that gets measured.

Then he names something everyone recognises. The tactical tornado is the prolific engineer who ships faster than anyone, whose output is spectacular, and who leaves a wake that the rest of the team spends years navigating. Management often loves the tornado. From where management sits, the tornado is the most productive person on the floor. The costs land somewhere else, in a quarter that is not this one, on people who cannot name what happened to them.

His remedy is an investment framing. Spend something like ten to twenty per cent of development time on design and cleanup, permanently, as a rate rather than as a project. Not a refactoring initiative. Not a tech debt sprint that gets cut when the roadmap slips. A standing tax you pay on every piece of work, which returns compound interest because every future change gets cheaper.

For a technology leader this is the section that matters, and it is uncomfortable, because the tornado is a creature of the incentive system rather than a character flaw. If you reward visible output and you cannot see accumulated complexity, you will select for tornadoes and then wonder why your delivery rate falls every year. The organisation gets what it pays for. It always did.

Which brings us back to agents. An AI coding tool is a tornado you can rent by the hour, and it has none of the things that eventually slow a human one down. It does not get bored maintaining what it wrote. It does not feel the shame of the pull request that broke Christmas. It will not, on its own initiative, stop and say the design is wrong. Where the whole of your check on complexity was the tacit reluctance of experienced engineers to make a mess they would have to live in, that check has just left the loop.

5. Design it twice

The most practical thing in the book takes one paragraph to explain and most teams never do it.

Before you commit to a design, produce a second one that is genuinely different. A variation will not do. You want a different decomposition, with the boundaries in different places. Then compare them and pick.

Ousterhout is candid that capable people resist this hardest. When you are good at this, your first design is usually decent, and producing a second feels like wasting an afternoon proving something you already know. He points out that this is precisely backwards. The value is not that the second design turns out better, though sometimes it does. The value is that having two makes the first one visible as a choice rather than as the shape of the problem. You cannot evaluate a design you cannot compare with anything.

He tells the story against himself. When he designed the API for the Tk toolkit, the second design was clearly better than the first, and he had been designing systems for a decade at that point.

Simon explains why this works, and the two ideas are the same idea seen from different ends. Rationality is bounded. You do not survey the space of possible designs and select the optimum, because you cannot; you generate candidates until one is good enough and then you stop. Satisficing is not a failure of discipline, it is how minds under constraint operate. Design it twice is a procedural hack that forces the search to continue for one more round after it wanted to stop, and one more round is usually enough to reveal that the first answer was the first acceptable answer rather than the best available one.

There is a version of this with agents that is almost free. Ask for two decompositions, with the constraint that they differ in where the boundaries fall, and then do the comparing yourself. Generation is the cheap half now. Judgement is not, and judgement is what the exercise was always for.

6. Comments are an instrument, not a residue

Ousterhout thinks you should write the comment first, and he thinks so for a reason that has nothing to do with documentation.

The argument runs like this. When you cannot write a short, clear description of what a module does and how to use it, the module does not have a clean abstraction. The difficulty you are feeling while writing the comment is not a writing problem; it is the design telling you something. A comment that requires four sentences of exceptions and caveats is describing an interface that will require four sentences of exceptions and caveats in the head of every person who ever calls it.

So the comment becomes a design instrument, used before the code exists and revised as the design changes. Write it, find it awkward, change the design, watch the comment get shorter.

This puts him directly against the self-documenting code position, and he takes the fight on. Good names help. Good names cannot express why a variable exists, what the caller is responsible for, what invariant is being maintained, or which of two plausible readings of the parameter is the correct one. Those things are not in the code, because they are decisions somebody made about the code, and a decision that is not written down is a decision that will be re-litigated by whoever inherits it.

Under AI this argument gets sharper rather than weaker, and it connects directly to the specification argument this phase opened with. A model is extremely good at telling you what a piece of code does; it will summarise a function you have never seen faster than you could read it. What it cannot tell you is what the code was supposed to do, because that information was never in the code. If the intent lives only in the head of the person who prompted it, and that person has moved on, the system now has a class of unknown unknowns that no amount of reading will resolve. The comment, the specification and the design record are the same artefact viewed at different zoom levels, and they are the only place intent survives.

7. Define errors out of existence

The last idea is the one I find myself using outside engineering more than any other.

The normal way to handle an exceptional case is to detect it and throw. The problem is that every caller now has to know about it, and the exceptional case has propagated into forty places that were otherwise simple. Exception handling is a major source of complexity precisely because it is contagious.

Ousterhout’s alternative is to change the definition so that the case is no longer exceptional. His example is deletion: on Unix you can delete an open file, because the semantics were defined so that the file goes away when the last reference does, and no caller ever has to handle the case. Windows chose to make it an error, and everyone downstream pays. His other favourite is string slicing. Java’s substring throws if the range is out of bounds, so every caller writes a bounds check. Define the operation to clamp the range instead and the exception disappears, along with the checks, along with the bugs in the checks.

The move is not to ignore the error; it is to ask whether the error had to exist.

The organisational version of this is everywhere once you start looking. Every escalation path is an exception handler. Every approval gate that exists for the case where somebody might do the wrong thing is a caller-side bounds check. Every one of them imposes cognitive load on people who will never hit the case, and the honest question is whether the design could have made the bad state unreachable rather than detectable. Sometimes the answer is no. Often it is no because nobody asked.

8. What this lever asks of you now

Pull the threads together and the constructive information question in building comes out as three obligations, and none of them is a dashboard.

The first is to make the cost of understanding visible, because it is the only cost in software that is entirely invisible in the accounts. You can see headcount, cloud spend, and licence fees. You cannot see the four hours a week that every engineer spends finding out how something works before they can touch it. Ousterhout’s symptoms are the closest thing to a measure, and no tool reads them. Take a competent person who did not write the system, give them a real change, and watch what happens. The time between the ticket being picked up and the first line being written is the number. Call that your interface cost, measured honestly.

The second is to pay the tax deliberately. Ten to twenty per cent, as a rate, protected. You pay in this quarter and collect in a later one, and every incentive you have points the other way, so the rate survives only where a leader defends it. If you will not defend the rate when the roadmap slips, do not announce it, because an investment policy that is suspended under pressure is worse than none: it teaches the team exactly what you actually value, and they will believe the lesson.

The third is to insist that somebody reads the sum. Reviews catch changes. Design reviews catch decompositions. If nobody in your organisation has the job of looking at the whole and saying this has got worse, then the incremental mechanism runs unopposed, and it will run faster now than it ever has.

Ousterhout’s position is that none of this changes because the code is generated. What changes is the ratio. The cost of producing code has collapsed and the cost of understanding it has not moved at all, which means understanding is now nearly the whole of the work. Simplicity was always the thing you had to win rather than the thing you were given. It is just that you used to be able to postpone the fight.

Placement: Building, the third of the series' four phases; Learning, Deciding, Building, Transforming. Ousterhout is the foundational thinker on Information in Building, the questions about how a build sees and describes itself. Complexity is what a build has to carry rather than what it has to produce, which is why deep modules matter more once generation is free. The Build Is the Test opens this stretch of the argument.

(An Organisational Prompt is something you can do now....)

Organisational Prompt

Watch somebody try to change something they did not build.

Pick a service that matters and is not new, then find a competent engineer who has never worked on it. Give them a small, real change, the kind that would normally be sized at half a day. Then sit next to them, say nothing, and write down every question they have to answer before they can write the first line.

Do not help. Do not explain. Your job is to record.

You will have a list of between eight and thirty questions. That list is the real interface of your system: it is what a person must know before they can act, and it is the tax every change has been paying. Read it and mark each item as one of two things. Obscurity, where the information exists but is not findable. Dependency, where the information exists somewhere else and this thing cannot be understood alone.

Then take the single most expensive item and ask the question that closes the loop: did this error have to exist? Not how do we document it better. Whether the design could have made the question unnecessary.

Run it again in three months with a different person and a different service. If the list is longer, your rate of accumulation is beating your rate of investment, and you now have the one piece of evidence that argument has always lacked.

Further Reading

Ousterhout’s book page carries a free extract of the second edition, including the new material and his comparisons with Clean Code: web.stanford.edu/~ouster/cgi-bin/aposd.php.

The full dialogue with Robert Martin on method length, comments and test-driven development, jointly edited by both authors: github.com/johnousterhout/aposd-vs-clean-code.

His fullest recent statement on AI and design, with a transcript: newsletter.pragmaticengineer.com/p/the-philosophy-of-software-design.

Raft, the consensus algorithm Ousterhout and Diego Ongaro published in 2014. Understandability was its stated design goal, which is the clearest evidence that he applies the argument to his own research; paper, lectures and visualisations at raft.github.io.

The log-structured file system paper with Mendel Rosenblum: people.eecs.berkeley.edu/~brewer/cs262/LFS.pdf.

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.

That idea carried his whole career. It now describes the central risk in how software gets made. An agent can write most of the code a team needs, quickly, to a fair standard. The engineers who used to write that code got their judgement in the writing. The resistance of the work taught them what good looked like. Take the writing away and the judgement has nowhere to form. Skill is made in the doing. What you stop doing you stop knowing.

1. Doing the work well, for its own sake

Sennett defines craftsmanship as “the desire to do a job well for its own sake”. Not for the bonus. Not to clear the ticket. For the quality of the thing itself. Craftsmanship is a relationship to the work, not a category of work. He counted the programmers who built Linux among his craftsmen, alongside the glassblower and the surgeon, because a craftsman is made by engagement with a standard and not by the material he works. The surgeon setting a line and the engineer refactoring a module answer the same demand. The work should be good because good is what the work deserves.

The enemy of craft is detachment. Laziness barely enters into it. Tell people exactly what to produce, measure them on volume and speed alone, move them off a task before they master it, and caring makes no sense. Sennett’s craftsman is the opposite of the alienated worker. He is invested, absorbed, slow to call a thing finished. Give people reasons to care about quality and most of them will care. Strip the reasons away and you get compliance. Compliance looks like work and is not work.

2. The hand educates the head

Thinking and making are one act. Skill does not sit in the head as a plan the hand carries out. All skills, Sennett argues, even the most abstract, begin as bodily practices. The hand feeds the head knowledge that reasoning alone cannot reach. A surgeon’s hands know things no textbook states. An engineer who has debugged enough race conditions feels the wrongness of a design before he can say why. The feeling is usually right long before the explanation arrives.

Instruction has a ceiling. You can give someone the rule. You cannot give them the feel. Bourdieu called it habitus: the durable dispositions that repetition lays down until they run beneath conscious thought. Habitus is what the workshop builds into the hand. It is acquired one way. You do the thing badly, many times, until the doing rewires the knowing. A craft explained is not a craft possessed.

3. Resistance is the teacher, and a smooth tool can dismiss it

Craft is built on difficulty. The material pushes back. The joint refuses to close. In fighting the resistance the craftsman learns what the clean picture in his head left out. Sennett’s warning about computer-aided design was not that the tool was bad, and the best architects reach for it. It was that a tool which dissolves the resistance dissolves the learning that lived inside the resistance. He walks through Atlanta’s Peachtree Center, five and a half million square feet of towers and hotels designed on screen. The plan fills the streets with well-drawn pavement cafés that the Georgia sun makes unusable. Nothing could fail on screen. Nobody saw the failure until it was concrete.

Programs that improve from their own data, Sennett wrote, tempt the craftsman to become “a passive witness to and consumer of expanding competence”. He watches a skill grow and does not acquire it. That was published in 2008. It describes an engineer who ships an agent’s code all day and cannot say how any of it works. The most powerful tool engineering has ever held is the most capable of turning the craftsman into a spectator. Which of the two it does is settled by how the work around it is arranged, not by the tool.

4. The workshop was the curriculum

Engineers already have a name for the shape of this. The agent carries seventy per cent of the code and the last part still needs a human. Osmani’s knowledge paradox adds that seniors use the agent to move faster through what they understand, and juniors reach for it to learn what they do not. Sennett supplies what that argument leaves out. He explains how the understanding got into the senior in the first place.

It got there at a shared bench. Before there were courses there were workshops. What passed between master and apprentice could not have been delivered as instruction, because most of what the master knew the master could not put into words. The apprentice worked beside him and was corrected in the moment. Not in a written review three days later. The correction came while the hand was still moving and the material was still in it. It was physical, it was immediate, and it came from someone who saw the error before the apprentice had finished making it. Sennett’s figure, taken from the research on expertise and argued over ever since, is that ten thousand hours of this makes an apprentice a master. The teaching was done by the arrangement: proximity, repetition, and somebody watching who already knew.

That arrangement is what an agent removes. The junior tasks were never cheap code that happened to go to juniors. The junior tasks were the bench. Give every one of them to the agent and you have closed the workshop and left the sign lit.

5. The corrosion began before the agent arrived

Craft was eroding long before the agent, and Sennett watched it go. In The Corrosion of Character he described how short-term, flexible employment dissolves the long horizons craft needs. Teams reform every quarter. Skills are declared obsolete on a roadmap. The patient accumulation of mastery stops paying. Eight years later, in The Culture of the New Capitalism, he named the fear that follows. He called it the spectre of uselessness: the dread of the skilled worker who suspects the system no longer wants what he gave a life to learning.

The agent did not make that condition. The agent makes it efficient. An organisation that already treated its engineers as interchangeable executors of tickets was starving craft before any agent arrived. The agent hangs a productivity number on the starvation. I suspect the teams that keep their judgement through this will turn out to be the teams that refused the corrosion years ago, for reasons that had nothing to do with agents at all.

6. Craft is a decision the organisation makes

The impulse to do good work is basic and nearly universal. It is not a rare temperament you interview for and hope to spot. Whether it grows or dies is set by how the work is arranged. The same person will care in one system and coast in another. The difference sits in the system and not in the soul.

So the question an agent puts to an engineering organisation is not whether to use it. Use it. The question is whether your use of it deepens the engagement that builds judgement or hollows it. Ask whether the people around it are becoming better craftsmen or better spectators. Ask whether the judgement your seniors carry is being passed on or spent down. You are running a workshop or you are emptying one. Nobody else will decide which.

Where this falls: Building, the third of four phases; Learning, Deciding, Building, Transforming. Sennett sits on Identity, the questions about who is building and what they can promise, because craftsmanship is the account of how judgement gets into a person in the first place. What an organisation gets out of that work is a system and the competence to keep it. The Build Is the Test sets out the argument these articles run on.

(An Organisational Prompt is something you can do now....)

Organisational Prompt

Give someone the work the agent could do

Each sprint, take one real task an agent could finish in minutes and give it to someone still building judgement. A senior reviews the result by hand and corrects it in conversation, not in a comment thread. Treat it as production and not as training. The task ships, and the point is that a person learned the craft of it.

Then look at what sits in your juniors’ queues. If it is only the work the agent could not do, you are spending senior judgement and making none. The bill arrives when the seniors leave and nobody behind them ever ran the bench. Reserve the apprenticeship on purpose, or lose it by default.

Further Reading

Richard Sennett, The Craftsman (Yale University Press, 2008). The first chapter, which contains the Peachtree Center material and the argument about computer-aided design, is freely available.

On the argument in section five, two more: The Corrosion of Character: The Personal Consequences of Work in the New Capitalism (W. W. Norton, 1998) for flexible employment and long horizons, and The Culture of the New Capitalism (Yale University Press, 2006), where the spectre of uselessness is named.

Addy Osmani, “The 70% problem: Hard truths about AI-assisted coding”, for the knowledge paradox in full.

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.

Addy Osmani named this the seventy-per-cent problem, and Charity Majors named the thing it threatens. Osmani’s observation is about a single build: AI carries you most of the way and leaves the last portion as hard as ever. Majors’s is about a career: the last portion is exactly the work that used to turn juniors into seniors, and if you let the machine swallow it, you stop forging the judgement you now need more of than ever. The question is no longer only who is doing the work today. It is where the next generation of judgement is going to come from.

1. The seventy per cent is a gift; the thirty is the job

When you watch a senior engineer work with an AI coding tool, it looks like magic; they scaffold an entire feature in minutes, tests and documentation included. Watch more closely and you see they are not accepting what the model hands them. They are refactoring the generated sprawl into smaller modules, tightening the interfaces, throwing away the clever bits that will not survive contact with the rest of the system. The model is accelerating the part they already know how to do, and their judgement is what keeps the result alive. The acceleration is real. The judgement is what makes the acceleration safe.

Osmani’s term for what happens when the judgement is missing is house of cards code: software that looks complete and collapses under real-world pressure. It is the precise failure of a junior, or anyone, who accepts the model’s output because they cannot yet see what is wrong with it. The thing stands up in the demo. It stands up in the second demo. It comes down the first time the world leans on it, and it comes down in a way the person who shipped it cannot diagnose, because they did not build the parts that broke. The seventy per cent the machine wrote was never the dangerous part. The thirty per cent it could not write is where the building actually happens, and it is the part you now have to be good enough to finish.

2. AI helps the people who least need the help

The most counterintuitive thing in Osmani’s account is the one most adoption strategies get backwards. AI tools help experienced developers more than beginners. He calls it the knowledge paradox: seniors use AI to accelerate what they already know how to do, while juniors try to use it to learn what to do, and only the first of those works. The senior already holds the model of the system in their head, so they can see in a glance whether the generated code belongs in it. The junior has no such model, so they have no way to tell good output from plausible output, and plausible output is exactly what the machine is best at producing.

This inverts the democratisation story the tools were sold on. The promise was that AI would flatten the field, letting the inexperienced perform like experts. What it actually does is widen the gap, because it is a force multiplier and a multiplier rewards whatever you already bring. Bring deep judgement and it makes you formidable. Bring little and it makes you fast at producing things you cannot evaluate, which is worse than slow. An organisation that hands powerful generation to its most junior people and expects it to substitute for experience has misread the tool at a basic level. It does not close the experience gap. It pays out in proportion to the experience you have, and it charges interest on the experience you lack.

3. Software is an apprenticeship trade

Majors states the premise the whole argument rests on with no hedging: software is an apprenticeship industry. You do not learn to be an engineer by reading books; you learn by doing, and doing, and doing again, on a team alongside people further along than you. Most of the learning happens on the job, all of it takes time, and her estimate is that it takes a solid seven-plus years of writing, reviewing, and deploying code to forge someone the job ladder is willing to call senior. There is nothing magic about the number. The point is that the competence is tacit, accumulated, and impossible to shortcut, because it is made of ten thousand small encounters with reality that no course can stage.

And the thing that makes someone senior was never the code. As Majors puts it, being a senior engineer is not primarily about your ability to write code; it is about your ability to understand, maintain, explain, and manage a large system over time, to hold its models in your head, to have judgement and instincts you can trust. That capacity is built from precisely the work an agent now does for you: the routine implementation, the debugging, the repetitive encounters with how things actually break. The apprenticeship was never a tax on the way to the real work. The apprenticeship was the mechanism that produced the judgement, and the judgement is the real work.

4. The trap is generational, and it compounds

Here the two observations lock together into something neither says alone. The work AI absorbs is the seventy per cent: the routine generation, the boilerplate, the first-draft debugging. That seventy per cent is also the substrate of the apprenticeship, the daily reps through which a junior slowly accumulates the model of the system that one day lets them see what is wrong with the other thirty. Automate the reps and you have not just sped up today’s work. You have removed the path by which today’s junior becomes tomorrow’s senior, the one whose judgement the whole arrangement now depends on to catch what the machine gets wrong.

Majors says it plainly: by not hiring and training junior engineers, we are cannibalising our own future. The senior-only hiring reflex that AI encourages is eating its own seed corn. Every organisation that decides it needs only experienced people who can supervise AI is relying on a supply of experienced people that it has simultaneously stopped producing. Camille Fournier put the question that has no good answer: how do people become senior engineers if they never start as junior ones. The pipeline that makes the supervisor and the work the machine now does are the same work. You cannot keep draining it from one end and expect it to keep filling from the other.

5. The measured cost of skipping the apprenticeship

Intuition is no longer the only evidence. A randomised controlled trial run by Anthropic put fifty-two mostly-junior developers in front of an unfamiliar Python library and asked them to learn it, half with AI assistance and half by hand. On a quiz covering concepts they had used minutes before, the AI-assisted group scored seventeen per cent lower than those who had coded by hand, about two letter grades, and the steepest decline of all was in debugging: the exact skill you most need when your job is catching what AI-written code gets wrong. The tool that produces the code you must supervise erodes the capability you supervise it with. That is not an irony; it is a feedback loop, and it runs the wrong way.

The same study holds the way out, and it matters as much as the warning. The outcome turned less on whether AI was used than on how. The developers who kept their understanding were the ones who treated the model as a tutor rather than a vending machine: asking it to explain the code it generated, posing the conceptual question before pasting the answer, writing some of it by hand to keep the muscle live. Those who offloaded the thinking wholesale lost the most. The lesson is not that AI atrophies judgement. It is that AI used as a substitute for thinking atrophies judgement, and AI used as a provocation to think can sharpen it, and the difference between the two is a deliberate choice an organisation has to design for rather than hope for.

6. What this asks of the people who run engineering

The seductive move is the one to refuse: staff only seniors, let them drive agents, skip the expensive years of growing your own. It works for exactly as long as your seniors last, and not a day longer, and you have given up the means of replacing them. The organisations that come through this will treat the apprenticeship as infrastructure, not overhead, and will protect the conditions under which judgement still forms even though the machine could do the underlying task faster.

In practice that means deciding, on purpose, which work a human should do the hard way because the doing is how they are made, not because it is the efficient route to the artefact. It means seniors who teach, and being willing to pay for the teaching, which has always been the historical failure point of apprenticeship: it collapses the moment the masters will not invest in the apprentices. It means juniors who use AI to gain experience faster rather than to bypass it, which is a real distinction with real daylight between its two halves. Writing the code was always the easy part. Owning it, operating it, understanding it well enough to change it safely at two in the morning when it is on fire, that was the job, and that is the part no agent has taken from you. It has only made it easier to arrive at that moment never having learned how.

Placement: Building, the third of the series' four phases, after Learning and Deciding and before Transforming. The last thirty per cent is the Identity lever in its most practical form, because the question is what a builder is still able to do once the first seventy per cent has stopped teaching them anything. What an organisation gets out of that work is a working system and the people who can keep it. The Build Is the Test opens this stretch of the argument.

(An Organisational Prompt is something you can do now....)

Organisational Prompt

Name the work you will keep doing the hard way

Pick one capability your team is now tempted to hand to an agent end to end, because the agent can produce the artefact faster than a person can. Now ask a different question about it than the efficiency question. Ask: is this one of the tasks through which a junior on this team actually learns the system? Is this where the reps live, the small repeated encounters with how things really break that slowly build the model in someone’s head?

If it is, you have found work you should think twice before fully automating, not because the machine cannot do it, but because the doing is how you make the people you will need to supervise the machine. Designate it deliberately. Decide which parts a developing engineer does by hand, on purpose, with a senior close enough to teach, and which parts the agent may carry.

Then change how the agent is used on everything else. Require that the people working with it ask it to explain, not just generate; that they pose the conceptual question before they accept the answer; that they keep writing enough by hand to know what they are looking at. The team that uses AI as a tutor keeps its judgement. The team that uses it as a vending machine loses the judgement precisely where it most needs it, which is in catching what the machine got wrong. You will not get that distinction by accident. You have to build it in.

Further Reading

Addy Osmani, The 70% problem: Hard truths about AI-assisted coding (2024). The origin of the framing this article builds on: the last thirty per cent, house of cards code, and the knowledge paradox by which AI helps experienced developers more than beginners. Short and worth reading in full.

Addy Osmani, The 80% Problem in Agentic Coding (2026). The sequel, written once agents could carry more of the build. The percentage moved; the shape did not. Read it for the inversion of where the time now goes: problem definition and verification, not execution.

Charity Majors, Generative AI is not going to build your engineering team for you (2024). The apprenticeship-industry argument in full, including the seven-year figure, the definition of seniority as something other than the ability to write code, and the warning about cannibalising your own future. The piece every technology leader making headcount decisions this year should read.

Addy Osmani, AI Won’t Kill Junior Devs, But Your Hiring Strategy Might (2025). The pipeline argument applied directly to hiring, drawing in Camille Fournier’s question about where seniors come from if no one starts as a junior.

Anthropic, How AI assistance impacts the formation of coding skills (2026). The randomised controlled trial behind section five: the seventeen-per-cent comprehension gap, the steep fall in debugging skill, and the finding that how AI is used matters more than whether, with treating it as a tutor preserving understanding.

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.

Mark Burgess spent twenty years working out why distributed systems built on command go brittle, and the answer he reached is the most useful idea available for the question of who, or what, now builds your software. Burgess is a physicist who became a systems researcher, and the tool he is best known for, the configuration engine CFEngine, ran on a principle that sounded eccentric in the 1990s and looks prophetic now: a machine cannot be told what to do; it can only be persuaded to converge on a state it has agreed to hold. Out of that practical work came Promise Theory, a formal account of how autonomous agents cooperate without a central authority forcing them to. It was written for servers. It turns out to be the precise grammar for a world in which some of your builders are people, some are agents, and the line between giving an instruction and making a promise is the line that decides whether the system holds together. This is the foundation the question of identity now stands on, because the old answer, that the builder is a person and you manage people, no longer covers the field.

1. An Agent Can Only Promise What It Controls

Start with the single rule that the whole theory unfolds from, because everything else is a consequence of it. An agent can only make promises about its own behaviour. It cannot make a promise about anything outside its own locus of control, and any statement that appears to do so is not a promise at all; it is a wish wearing a promise’s clothes.

A web service can promise to return a response within fifty milliseconds. It cannot promise that the network will deliver the response to you, because the network is not within its control. A team can promise to ship an interface that behaves to a specification. It cannot promise that the team downstream will use the interface correctly, because the downstream team’s behaviour belongs to the downstream team. The rule sounds almost trivial when you state it. Its consequences are not, because almost every coordination failure in a large organisation is a promise made about behaviour the promiser did not control, accepted as though it were binding, and discovered to be empty at the worst possible moment.

Burgess’s word for what command does is *imposition*. An imposition is an attempt to specify another agent’s behaviour from outside. You can issue impositions all day; the language permits it and management culture encourages it. What you cannot do is make them true. An imposition only changes the world if the agent it is aimed at chooses to make a promise that corresponds to it. The order does not move the agent. The agent’s own promise moves the agent, and the order is merely an input the agent may or may not honour. Command, in this account, is not a force. It is a request with the volume turned up, and turning the volume up does not add control you never had.

This lands hard the moment your builders include agents. You can instruct an autonomous coding agent to follow your security policy. The instruction is an imposition. Whether the policy is followed depends entirely on whether the agent’s actual behaviour, the thing inside its locus of control, converges on the policy. If it does not, you have not been disobeyed in the way a person disobeys. You have discovered that the imposition was never a control in the first place; it was a hope you had mistaken for a mechanism. The agent kept the only promise it was ever capable of keeping, which was a promise about itself, and that promise did not match what you wanted.

2. Promises Are Voluntary, and That Is Their Strength

The second principle is the one that offends managers, and it is the one that makes the whole thing work. Every promise is voluntary. An agent promises because it elects to; the promise originates inside the agent, not outside it. There is no such thing as a promise extracted under command, because the moment you extract it under command you are back to imposition, and imposition does not bind.

The instinct is to treat voluntariness as a weakness. Surely a system you can order around is more reliable than a system that merely agrees to cooperate. The instinct is exactly backwards, and Burgess’s argument for why is the heart of his contribution. A system coordinated by voluntary promises is more resilient than a system coordinated by command, because each agent is responsible for keeping its own promises, and an agent can only be reliably responsible for what lies within its own control. When you build coordination out of promises, you build it out of commitments each party can actually honour. When you build it out of commands, you build it out of obligations no party fully controls, and you have manufactured fragility while believing you manufactured order.

Consider two ways to make a hundred services behave. In the first, a central controller holds the desired state of every service and pushes commands outward, correcting each deviation as it sees it. This is command, and it has a single point whose failure takes down the coordination of the whole. In the second, each service holds its own promise about the state it will maintain and converges on it locally, advertising what it promises so that others can decide whether to depend on it. This is promise-based coordination, and it has no centre to fail, because the intelligence lives at the edges where the control actually is. The second system is harder to draw on a slide and far harder to break in production. Resilience is not a property you add to a coordinated system. It is a property of where you put the responsibility, and voluntary promises put it in the only place that can carry it.

For a fleet of autonomous agents this stops being theory and becomes operational reality within a week of deployment. You will be tempted to run the fleet from a central policy engine that commands each agent’s behaviour. The fleet will work in the demo and fail under load, because the central engine cannot hold enough control over a hundred agents acting in a changing environment to correct them faster than they drift. The configuration that survives is the one where each agent makes and keeps its own promises, advertises them honestly, and is depended upon only for what it has actually promised. The same is true, and has always been true, of teams of people. Burgess’s achievement is to show that it is the same fact in both cases, and to give it a notation precise enough to design with.

3. The Fictitious Coupling Is Where Systems Break

Now the failure mode, because an idea about coordination is only worth as much as the specific way it tells you things go wrong. When you impose an obligation from outside and the system behaves as though that obligation were a real dependency, you have created what Burgess calls a *fictitious coupling*: a connection the system believes in but that nothing in the system actually maintains. Fictitious couplings are the dark matter of brittle architectures. They do not appear on any diagram, because no one drew them deliberately; they accreted out of impositions everyone assumed were promises. And they hold the system’s stability hostage to commitments no agent ever made.

A team depends on another team’s service being available, a dependency no one ever promised because no one was asked to. A scheduled job assumes a file will be present because it has always been present, not because any process promised to put it there. An agent’s output is consumed downstream as though it were validated, when nothing in the agent ever promised validation; the imposition “the output will be correct” was treated as a promise the agent had made, when in fact the agent only ever promised to generate plausible output. Each of these is a fictitious coupling, and each is invisible until the day the unpromised behaviour does not occur, at which point the failure propagates through couplings no one knew anything depended on, because no one knew they were there.

The discipline Promise Theory imposes is therefore a discipline of honesty about dependency. A real dependency is one where the thing you depend on has actually promised the behaviour you are relying on, and has advertised that promise so you could decide to depend on it. Everything else is a fictitious coupling waiting to be discovered. The work of building a system that does not surprise you is, in large part, the work of converting fictitious couplings into real promises: finding the places where you rely on behaviour no one committed to, and either getting the commitment or removing the reliance. This is unglamorous, and it is most of what reliability engineering actually consists of, and Promise Theory is the only framework that gives it a name and a method.

Free making sharpens this to a point. When code was expensive, dependencies were few and deliberate, because each one cost something to build and someone had thought about it. When an agent can generate a thousand lines that quietly assume a dozen behaviours nothing has promised, fictitious couplings breed faster than anyone can audit them. The generated code looks complete. It compiles, it runs, it passes the happy path. What it conceals is a thicket of assumed behaviours, each one an imposition the surrounding system never agreed to honour, each one a coupling that will become visible only when it fails. The maintenance burden that free making imposes is, seen through Burgess, a burden of unaudited couplings: abundance is cheap to generate and expensive to keep precisely because every generated artefact arrives wrapped in dependencies no one promised and everyone will inherit.

4. A Promise Is a Testable Claim

Here the identity question meets the frame this whole inquiry turns on: that a build is a test, an experiment with a result that can disconfirm. A promise is the unit that makes this exact. A promise is a claim about behaviour, and a claim about behaviour can be checked against behaviour. Either the agent did what it promised or it did not. There is no third state, no partial credit, no “it depends on what you meant.” The precision is the point. A promise is a hypothesis stated so clearly that reality can return a verdict on it.

This is why the model fits building so well. When a component promises an interface and fails to keep it, the component has not committed a governance violation to be escalated and apologised for. It has run a test and returned a result, and the result is information you needed and now have. The promise was the hypothesis; the build was the experiment; the broken promise is the disconfirmation, and disconfirmation is the most useful thing a build produces, because it changed your mind before the customer changed it for you. An organisation that treats a broken promise as a failure to be punished will learn to hide broken promises. An organisation that treats it as a result to be read will learn what its system actually does, which is the only knowledge worth having.

Promise Theory also tells you what makes a promise testable, and it is exactly the discipline that vague specification lacks. A promise must be about observable behaviour within the promiser’s control, advertised clearly enough that another agent can decide whether to depend on it. “The service will be reliable” is not a testable promise, because reliability is not an observable state and the boundary of the claim is undrawn. “The service will return a valid response to a well-formed request within fifty milliseconds, for the request shapes in this schema” is a testable promise, because every term in it can be checked and the edge of the claim is visible. The work of making a system promise well is the work of making its claims sharp enough to fail. This is the same discipline that turns a specification from a wish into an artefact reality can answer, carried now from how the build describes itself to who, or what, is doing the building.

5. The Builder Is Now Mixed, and the Model Was Built for It

Every prior thinker who held this ground held it for humans. The questions about the builder were human questions: is this person capable, do they have judgement, has the apprenticeship pipeline that forges judgement stayed intact. Those questions have not gone away, and they sharpen rather than soften, because an agent gets a builder most of the way and leaves the last, hardest portion exactly as hard as it ever was. The edge cases, the integration, the security, the behaviour under real production load: AI delivers a builder to the eighty-percent line and abandons them at the cliff, and the cliff is where competence used to be proved. Software has always been an apprenticeship trade, where judgement is forged over years doing precisely the work an agent now absorbs, and the threat to the pipeline of senior judgement is real and worth naming plainly. A senior who must now supervise work they did not write needs more judgement than ever, sourced from an apprenticeship the new tools are busy hollowing out.

But the reason Burgess holds this ground, rather than a thinker about human craft alone, is that the subject of the question is no longer only human. Some of what builds is an agent, and an agent is an autonomous thing that takes inputs, acts on its own account, and produces outputs you did not write and must now trust or verify. A theory of who can build that only describes people cannot carry a field in which half the builders are not people. Promise Theory can, because it was never about people in the first place. It is about autonomous agents of any substrate, and its definition of an agent, something with a locus of control that can make and keep promises about its own behaviour, fits a coding agent and a senior engineer with the same precision. The questions become symmetrical, and the symmetry is the gift. What can this builder actually promise, given what lies within its control? What is it being asked to promise that lies outside its control, and therefore cannot bind? Where are we depending on a behaviour nothing has committed to? You ask these of the human team and the agent fleet in the same breath, and for the first time you have one model that answers both.

6. What an Agent Cannot Promise

The symmetry has a sharp edge, and the edge is where the discontinuity between human and agent builders cuts deepest. An agent can promise. It can promise an interface, a latency, a behaviour, a refusal to act outside its bounds, and it can keep those promises as reliably as any component ever has. What it cannot do is have anything at stake in the keeping.

A promise between people carries more than the behaviour it specifies. It carries relatedness; the promiser cares, in some degree, whether the promise holds, because the promiser is bound into a web of others who will be affected. A human builder who breaks a promise feels something, even if only the small friction of having let a colleague down, and that feeling does real work, because it is part of what keeps promises kept when no one is watching. An agent feels nothing. It keeps its promise when its behaviour converges on the promise and breaks it when it does not, and it is entirely indifferent to which occurs. It has no relatedness, nothing invested, no stake in the outcome beyond the mechanics of its own execution. The promise is real; the caring is absent.

This is not a sentimental complaint, and it is not an argument against agents. It is a structural fact, and it has a structural consequence everything that follows is built to address. Because the agent has nothing at stake, it cannot generate the energy a team runs on; it cannot share a mood, cannot renew the symbols a group organises itself around, cannot care whether the thing it built was good. Everything a team draws from caring about the work together must, in an agent-heavy configuration, be supplied deliberately by the humans, because the agents categorically cannot supply it. Promise Theory lets you draw the line with unusual precision, and the line is this: the agent can be trusted to keep what it promises, and can never be trusted to care that it did. Design as though both halves are true, because both halves are true, and the configurations that fail are the ones that noticed the first half and forgot the second.

7. Designing for Promises Instead of Commands

What changes, concretely, when you stop coordinating by command and start coordinating by promise? The shift is less in the technology than in where you place responsibility and how honest you are about dependency, and it shows up in three habits worth naming.

The first habit is to make every dependency a promise or remove it. Walk the couplings your system relies on and ask, of each, whether the thing you depend on has actually promised the behaviour you are relying on. Where it has, document the promise as the interface contract it is. Where it has not, you have found a fictitious coupling, and you have two honest options: get the promise made and advertised, or stop relying on the behaviour. There is no third option that does not leave a brittleness in place. This audit is dull and it is the single most valuable thing you can do to a system you intend to keep.

The second habit is to push promises to the edge, where the control actually lives. Resist the instinct to coordinate a fleet of agents, or a set of teams, from a central engine that commands their behaviour, because the centre cannot hold enough control over autonomous parts in a changing environment, and it becomes the single point whose failure takes the coordination down. Let each agent and each team make and keep its own promises, advertise them, and be depended upon only for what it has promised. You will lose the comforting illusion of a single throat to choke and gain a system that does not seize when the centre stutters.

The third habit is to demand that promises be testable, which means demanding they be sharp. A promise stated vaguely cannot be checked and therefore cannot be kept in any sense that matters; it is a fictitious coupling in the making. Insist that every promise an agent or a service or a team makes is a claim about observable behaviour within its control, advertised clearly enough that another party can decide whether to depend on it. The discipline of sharp promises is the discipline of a system that can tell you the truth about itself, and a system that can tell you the truth about itself is the only kind you can safely build at the speed free making now permits.

8. From Who Builds to How They Relate

Promise Theory settles the identity question and, in settling it, produces the next one fully formed. The builder, human or agent, is an autonomous thing that makes and keeps promises about behaviour within its own control, and the model gives you one grammar for both. But the model also marks, with unusual clarity, the exact place it stops being sufficient. An agent can promise everything except to care, and caring is not a private feeling; it is generated between people, in the occasions where a group is bodily present, attending together, sharing a mood. The agent’s structural inability to supply that energy is not a gap in Promise Theory. It is Promise Theory pointing precisely at the thing the next thinker exists to explain.

So the question moves from who builds to how the builders relate, and specifically to where the energy comes from that makes a group of builders more than a set of agents executing in parallel. A team is not a collection of promise-keepers, though it must be that too. It is a group that generates something between its members that no member could generate alone, and that something is exactly what the agent, with nothing at stake and no body to be present with, cannot contribute. To understand how a building team produces and renews that energy, and why an agent-heavy or remote-only configuration can hit every output metric and still go quietly lifeless, the field turns from Burgess to a sociologist who spent his career on the mechanics of human ritual. The locus of control told us what each builder can promise. What a group of builders generates between them, no locus of control contains, and that is the next thing to understand.

Where this sits: Building, the third of four phases; Learning, Deciding, Building, Transforming. Burgess is the foundational thinker on Identity in Building, the questions about who or what is building and what it can actually promise. Interaction follows, and with it the question of where a team's energy comes from once some of the builders have nothing at stake. The Build Is the Test sets out the argument these articles run on.

(An Organisational Prompt is something you can do now....)

Organisational Prompt

Audit one dependency until you find the lie

Take a single service, pipeline, or agent your organisation depends on, and trace one dependency it relies on but you have never examined. Ask the only question that matters: has the thing you depend on actually promised the behaviour you are relying on, or have you simply assumed it because the behaviour has always happened?

Follow the chain. The service depends on a database being reachable; did the database promise reachability, or did someone assume it? The agent’s output is consumed downstream as validated; did the agent promise validation, or did it only ever promise to generate plausible output that someone decided to trust? Keep pulling until you find a coupling no one ever committed to. You will not have to pull far.

When you find it, you have found a fictitious coupling: a dependency the system believes in but nothing in the system maintains. Now do the unglamorous thing. Either get the promise made and advertised, so the dependency becomes real and testable, or remove the reliance, so the system stops betting on behaviour no one committed to. Do not leave it as it is, because as it is, it is a failure waiting for the day the unpromised behaviour does not occur.

Run this once, deliberately, on a system you care about, and you will see your architecture the way Burgess sees it: not as a diagram of components, but as a web of promises, some real and some fictitious, and you will know which is which. Then make it a habit, because under free making the fictitious couplings breed faster than ever, and the only defence is the discipline of asking, of every dependency, whether anyone actually promised it.

Further Reading

Mark Burgess: Thinking in Promises: Designing Systems for Cooperation (O’Reilly, 2015). The accessible entry point, written for practitioners rather than theorists. Read it for the locus of control, the difference between an imposition and a promise, and why coordination by voluntary promise outlasts coordination by command. Everything in this article is developed from it.

Mark Burgess and Jan Bergstra: Promise Theory: Principles and Applications (Volume 1, 2014). The formal treatment, for those who want the notation and the proofs rather than the prose. Heavier going, and the place to turn once the practical idea has convinced you and you want to design with it precisely.

Mark Burgess: In Search of Certainty: The Science of Our Information Infrastructure (O’Reilly, 2015). The wider argument about why certainty in distributed systems is a category error, and why convergence and promise, not command and control, are the realistic basis for running infrastructure at scale. The intellectual backdrop to the whole programme.

Mark Burgess’s collected essays and notes on Promise Theory are maintained at markburgess.org/promises.html, including freely available introductory pieces that work well as a first encounter before committing to a book.

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.

Free generation inverts the scarcity. The code is no longer the expensive part; the precise statement of what you meant is. And that statement now has two faces. Written forward, before the build, it is a specification. Packaged for reuse, after the build, it is a skill. They are the same artefact seen from opposite ends, and the interesting engineering is no longer in either face but in the loop that runs between them: you specify, you generate, you verify, you package the verified thing as a skill, you watch it work, you distil what it actually does back into the spec, and you go round again. The loop is the new unit of building. This article is about what runs inside it.

1. The oldest idea in computing, just returned

In 1953, designing the ARMAC machine in Amsterdam, Edsger Dijkstra wrote that he would describe the machine “in so far as it concerns the user: it will be described what the machine does, not how the machine works.” Historians of computing reasonably call this one of the first explicit statements of the interface concept, the wall between what a thing promises and how it delivers. It is also the seed of every specification language since. The whole inheritance, from design by contract to VDM to TLA+, is a sixty-year attempt to state intent precisely enough that the implementation becomes a derivation rather than an invention. Tony Hoare put the stakes in a sentence: a program that has not been specified cannot be incorrect, it can only be surprising.

So why did formal specification stay a niche pursuit, admired and unused? Two reasons, and they were the same reason wearing different clothes. The notation was forbidding, a second language most engineers were never going to learn. And the payoff arrived too late to be worth it, because when you were going to type every line of the implementation by hand anyway, the bottleneck was the typing, not the thinking, and a rigorous spec saved you nothing on the part that actually hurt. The discipline was sound. The economics were wrong. What has changed is not the discipline but the economics: the typing is now free, the thinking is the whole job, and the artefact that captures the thinking is suddenly the most valuable thing in the building. Formal specification was never wrong. It was early.

2. The spec is the source of truth, not the scaffolding

GitHub Next’s SpecLang project states the new posture cleanly: the specification is the main thing you maintain, and the executable code it produces is secondary, something you will rarely have to inspect. They call it “prose code,” and the distinction from no-code matters. You are not waving at an app builder and hoping. You are still thinking like a programmer; you are simply doing your thinking at the level of intent and letting the model handle the plumbing of getting that intent to compile. The spec is where the work lives, and the work is choosing what the system does and where its behaviour must be exact.

This is Brooks’s distinction made operational. Essential complexity, the part no tool can absorb, is deciding what to build and where the boundaries fall and whether the result is any good. Accidental complexity is everything incidental to that: the syntax, the glue, the boilerplate. The spec is essential complexity with the accidental scaffolding stripped away. Writing it is doing the irreducible work directly, which is why it feels harder than the old way even though the machine is doing more; you have lost the busywork that used to let you feel productive while you avoided the decision. SpecLang’s own loop, which it calls “create by reacting,” leans into this: start deliberately underspecified, run the thing, and refine only the parts that came out wrong. The danger hides in that convenience. Under-specification is a gift only if you can see what the model decided on your behalf and pull those decisions back up into the spec. If you cannot, the model is quietly authoring intent you never stated, and you will not find out until the intent ships.

3. Why prose alone will not hold

The obvious objection is that you already have a place for intent: a Markdown document, a Confluence page, a well-written README. Why does the spec need to be anything more than careful prose? Because prose drifts. The team behind Allium, a behavioural specification language built for exactly this moment, put the problem precisely: conversational context drifts within a session and evaporates across sessions; by the twentieth prompt the model is pattern-matching on its own earlier output rather than on your original intent, and when the chat ends the constraints vanish with it. Prose in a wiki has the same disease more slowly. It captures requirements, but it gives you no machinery for catching the moment two of them contradict each other.

That is the real gap. You can write “users must be authenticated” in one section and “guest checkout is supported” in another, and nothing in the document will flag the collision. A capable model will simply resolve it, silently, in whichever direction its training nudges it, and you will have shipped a decision you never made. A structured specification does the work that diligence alone otherwise has to: when two rules have incompatible preconditions, the form exposes the conflict, so the model does not need to be clever enough to notice. This also answers the tidy objection that a spec alongside code violates single-source-of-truth. Code is not a clean source of truth; it captures intentional and accidental behaviour with no way to tell them apart. Is that authentication quirk a feature or a bug? The code cannot say. You need something outside the code even to articulate “this behaviour is wrong,” and that something is the spec. It is the same logic by which types and tests are not duplication but resilience. This is also where David Parnas earns his place here: information hiding is decision hiding, and a good spec names which decisions everything else depends on and which are free. An agent that can see only an interface cannot weave the cross-cutting tangle that ages a system to death, but only if the spec has said where the seams are meant to fall.

4. The spec is written from both ends

A document becomes a loop when it is written from both ends at once. Allium describes two processes that feed the same artefact from opposite directions. Elicitation works forwards, from intent: a structured conversation that draws out what you actually meant, surfacing the constraints you would never have thought to write down. Distillation works backwards, from the running implementation: it reads what you actually built and writes down what it actually does, including the behaviours nobody ever decided on. One captures what you meant. The other captures what exists.

The value is in the gap between them. When elicitation and distillation diverge, you have found something worth investigating, and the divergence is information rather than error. Maybe the implementation drifted from intent. Maybe the intent was naive and the implementation is right. Either way, the gap is a question the spec is now forcing you to answer, instead of a silent assumption riding quietly into production. This is Ohno’s discipline relocated from the factory floor to the codebase. Standard work, for Ohno, is not a rule carved in stone; it is the current best description of how the job is done, held as a hypothesis that the next observation is allowed to correct. The spec is standard work for intent. Distillation is going to the gemba, standing where the system actually runs, and writing down what is genuinely happening rather than what the plan said should happen. A spec that is only ever written forwards, and never corrected by what the build reveals, is not standard work. It is wishful thinking with good formatting.

Anyone who has met domain-driven design will recognise what is happening here, because this loop is Eric Evans recovered rather than invented. Evans built his discipline on a ubiquitous language, a single vocabulary shared by the people who understand the domain and the people who build the system, kept rigorously the same in conversation and in code so that nothing is lost in translation between them. A behavioural specification is that ubiquitous language given a durable home. His other central move was the insistence that the domain model is a designed artefact, deliberately separated from the database, the framework, and the wiring, none of which the business actually cares about. Watch what distillation does in practice and you are watching exactly that separation enforced: the discipline reads the running code and asks, of every detail, whether a stakeholder would care about it or whether it is mere implementation. The token format goes; the seven-day expiry stays. The database choice goes; the order of the workflow states stays. The question “would the business care?” is Evans’s boundary between domain and plumbing, and what he drew by argument the loop now runs as a step. He taught a generation to describe a domain precisely before acting on it, and the precision was always the point. It is also what makes a specification executable rather than decorative. A vague spec is a wish. A spec written in a real ubiquitous language is something a machine can build against and a property test can check.

5. Verification: how you know the spec is true

A loop that only specifies and generates is an open loop, and an open loop is just a faster way to ship your assumptions. The thing that closes it is verification, and the relevant advance is in how cheaply you can now check a spec’s claims against a build. Anthropic’s work on agentic property-based testing shows the shape of it. Ordinary tests are example-based: you assert that sorting the list [2, 10, 5, 4] returns [2, 4, 5, 10], and you have checked exactly one case and missed every edge you did not think of. Property-based testing inverts this. You state a property that should hold for all inputs, that deserialising is the inverse of serialising, say, or that samples from a given distribution are always positive, and the framework goes hunting for a counterexample.

The properties come from the spec, and a model is genuinely good at reading a function’s name, its docstring, and the way it is called, and inferring the property that ought to hold, because that is reasoning at the level of intent rather than example. The spec states the properties; the agent writes tests that try to break them; the build either survives or returns a result you have to read. Anthropic’s agent found real, merged bugs in NumPy, in tokenizers, in AWS tooling, this way. But keep the honest limit in view, because it is the whole point. When the agent tested a date library, it flagged a function that returned a non-Sunday Easter date, and the maintainers explained it was intended behaviour under a different calendar system. The “bug” was a misread intent. Verification surfaced the question; it could not answer it, because only a human knows what the system was for. This is Beer’s POSIWID and Ohno’s jidoka in one mechanism. The purpose of a system is what it does, not what its spec claims, and the property test is how you discover what it does before the customer discovers it for you. It is the andon cord, wired into the build, stopping the line the instant the build stops keeping the spec’s promise.

Testing has a precise word for the thing a test consults to decide whether output is right: the oracle. It is the source of truth the check appeals to, the judge that says pass or fail. In most testing the oracle is buried and ad hoc, a hard-coded expected value here, a developer’s memory of what good looks like there, which is why tests rot the moment the person who wrote them moves on. The move this whole framework turns on is to make the specification the oracle, named and explicit and outside the code. The property test does not consult a hard-coded answer; it consults the spec. The build is judged against the stated intent rather than against whatever the last person assumed. Once the oracle is the spec, a question with real teeth becomes askable: is the build wrong, or is the oracle wrong? The Easter date was the oracle being wrong, a property asserted that the domain never actually required. Either way you have learned something, and you have learned it because the judge was written down where you could argue with it.

6. The skill is the spec made reusable

The spec’s second face arrived as a standard. In December 2025 Anthropic published Agent Skills as an open standard, and within weeks it had been adopted across a startling range of competing tools. A skill is a folder containing a SKILL.md file: a little YAML frontmatter for metadata, then Markdown instructions, packaging a piece of procedural knowledge that an agent loads only when a task actually calls for it. Strip away the novelty and look at what a skill structurally is. It declares what it can do, what must be true before it runs, what tools it needs, and what shape its output takes. That is a specification. It is intent written for reuse and addressed to an agent rather than to a compiler.

This is why the skill matters to anyone running a technology function rather than writing the code themselves. For most people most of the time, the unit they touch is not the model and not the codebase; it is the skill. The skill is the interface to capability, the thing that is invoked, governed, shared, and audited. And the specification is how that capability gets defined and improved. The two are the same object at different stations of the loop. The early evidence rewards treating them that way: benchmarks show that curated, human-authored skills reliably improve an agent’s performance while skills a model generates from its own parametric knowledge rarely do, and that a small set of focused skills beats one bloated document every time. The discipline that produces a good specification is exactly the discipline that produces a good skill: precision about what it does, clarity about its boundaries, and the restraint to leave out what does not belong. A skill, in Ohno’s terms, is restraint made reusable, and a bloated skill is overproduction in the form of instruction. The waste argument that runs through the rest of this phase applies one level up, to the instructions themselves.

The symmetry runs deeper than reuse, and this is what makes the loop more than a metaphor. The skill is not only the thing the loop produces. It is also the thing that operates the loop. Allium ships its workflow as skills: an elicit skill that runs the forward conversation from intent, a distil skill that reads a running codebase back into a specification, and maintenance skills it calls tend and weed that keep the spec aligned with the code as both move. The capability that turns code into spec is itself a packaged, reusable specification of how to do that. So the loop folds back on itself: skills maintain the spec, the spec defines the skills, and improving either improves your ability to improve the other. This is the point at which a development practice stops being a sequence of steps and becomes a system that compounds.

7. How the loop actually runs

Walk one full turn, concretely, because the detail is where the discontinuity lives. You begin with elicitation: a structured conversation that pulls intent out of a stakeholder and lays it down as a specification, filtering out the implementation ideas that surface along the way. You generate an implementation from that spec. You verify the implementation against the spec’s stated properties, and the build either keeps its promises or returns a result you have to read. You package the verified capability as a skill, with its preconditions and boundaries named on the front. Then comes the return leg, the one organisations forget exists: distillation. You point a distil skill at the running system and ask it not what the code says but what the code means; it filters out the database columns, the token formats, the framework plumbing, and writes down the domain behaviour that is actually there, including the behaviour nobody remembers deciding on. Allium’s own guidance is unambiguous about the status of what comes back: the extracted spec is a hypothesis, to be validated against both the developers who wrote the system and the stakeholders who wanted it. The loop closes when that distilled hypothesis is reconciled with the spec you started from, and the reconciliation is where the learning is.

This has already left the whiteboard. The most rigorous published account is the Kitchen Loop, a framework run over two production systems for more than 285 iterations and over a thousand merged changes with, on the authors’ regression oracle, no regressions. It runs a six-phase cycle, groom the backlog, use the product, turn findings into tickets, branch and fix, review and merge, then regress, and every phase is driven by a skill operating against a single trust model. Two of its design principles are worth lifting out verbatim, because they are the ones an enterprise will be tempted to violate first. The first they call spec-anchored improvement: a self-improving loop must optimise toward satisfying the specification, not toward a proxy metric, because the moment you point the machine at a number it can move, it will move the number and let the product rot in the dimensions the number does not see. The second is drift before failure: an autonomous loop needs continuous trend monitoring, not just a binary pass-or-fail gate at the end, because the failure you can catch is the one you watched coming. The human role, in their telling, moves to where it belongs: asynchronous specification design and backlog curation, not synchronous coding and manual QA. You stop writing the build and start authoring and curating the thing the build is judged against.

8. The half that fails silently

One thing in this loop is genuinely new. When both the unit you author and the unit other people consume are natural-language specifications, the distance between intent, implementation, and reuse can be closed continuously, turn by turn, rather than only at the release boundaries where it always used to be reconciled in a lump. That continuous closure has no clean classical analogue, and it is the real prize. But it depends entirely on the half of the loop that does not feel like progress, and that half is distillation. Generation feels like output; you can watch the skills pile up and the tickets close. Reading the build back into the spec feels like bookkeeping, and it is the first thing cut when a quarter gets tight.

Cut it and the loop does not stop. It degrades, quietly, in a way the research community has now named and measured. The failure mode of an unanchored self-improving loop is not a crash; it is drift. Skill libraries that evolve without a specification to answer to suffer what one recent study calls library drift, where the system keeps changing, keeps scoring well on whatever it measures, and steadily loses the plot on everything it does not. It is Goodhart’s law wearing engineering clothes: optimise the proxy, lose the purpose. This is exactly the failure Beer warned of from the other direction; the purpose of a system is what it does, and a loop that has stopped checking what it does against what it was meant to do has quietly adopted a new purpose without telling anyone. The skill becomes the author of intent that nobody ever stated. You get more capability and less and less idea of what any of it actually promises, which is the precise shape of overproduction Ohno spent a career fighting, now reproduced at the level of instructions rather than parts.

The defence is the same in every serious account of these loops, and it is cheap relative to what it protects: anchor the loop to something the loop cannot move. A specification it must satisfy. An oracle outside the code, one the builder cannot quietly weaken to make the result pass. A trend you watch between gates rather than a gate you hit at the end. The most dangerous specification is not the one that is wrong; a wrong spec gets caught the first time the build contradicts it. The dangerous one is the spec that stopped being checked against the thing it describes and was believed anyway, because nothing contradicts a document nobody reads. The spec and the skill are the same artefact seen from the two ends of one loop. The engineering is not in either end. It is in keeping the loop closed.

Placement: Building, the third of the series' four phases; Learning, Deciding, Building, Transforming. Building enters the cycle at Structure, because a specification has to be constructed before it can do anything, and this article is about the construction. 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 opens this stretch of the argument and From Deciding to Building is the bridge into it.

(An Organisational Prompt is something you can do now....)

Organisational Prompt

Close one loop, end to end

Pick one capability your organisation already builds with AI and currently treats as a pile of code plus a folder of prompts. Just one. Now write its specification: not how it is implemented, but what it must do, under which conditions, and, the part everyone skips, what it must never do. Keep it short. The discipline is not length; it is making the contradictions visible enough that you cannot pretend they are not there.

Then distil. Read the running implementation back and write down what it actually does, including the behaviour nobody remembers deciding on. Put the two documents side by side, what you meant and what exists, and look hard at where they disagree. That gap is not a tidiness problem to be cleaned up later. It is the most useful thing you will learn this quarter, because it is the intent your system has been acting on without telling you.

Now state one property that must hold for all inputs, not one example, a property, and have an agent try to break it. If it cannot, you have a verified claim rather than a hope. Package that claim as a skill, with its preconditions and its boundaries named on the front.

The test of whether you did this well is not whether you produced three documents. It is whether, three weeks from now, the spec still describes the skill, and the skill still keeps the spec’s promise. If they have drifted apart and nobody noticed, you were never running the loop. You were just writing the same thing down in two places and trusting both.

Further Reading

Edsger Dijkstra’s role in the origin of the interface concept, including the 1953 ARMAC line about describing what the machine does and not how it works, is recounted in Dijkstra, Blaauw, and the origin of computer architecture. The cleanest short route into where all of this began.

GitHub Next, SpecLang. The clearest statement of the spec as the maintained source of truth and the code as a secondary artefact, with the “prose code” and “create by reacting” framing this article draws on.

JUXT, Allium. A behavioural specification language built for LLM-era development; read it for why prose alone cannot surface contradiction, and for the elicitation and distillation pair that turns a spec into a loop. The two skills themselves are worth reading directly, because they are specifications of how to specify: elicit runs the forward conversation, and distill reads a running codebase back into a spec, treating the result explicitly as a hypothesis to be validated.

Eric Evans, Domain-Driven Design Reference (2015), the freely available distillation of his 2003 book. Read it for the ubiquitous language and for the insistence that the domain model is a designed artefact kept clean of implementation; the loop in this article is that discipline made executable, and Evans even calls the move that abstracts code back to domain by the same name, distillation.

Yannick Roy, The Kitchen Loop: User-Spec-Driven Development for a Self-Evolving Codebase (2026). The most rigorous published account of the spec-anchored loop running in production, over 285 iterations and a thousand-plus merged changes. Read it for the six-phase cycle and for the two principles that keep it honest: optimise toward the specification, not a proxy, and watch for drift before failure rather than only at the gate. The code is open.

Anthropic, Finding bugs with Claude and property-based testing. Verification at the level of intent rather than example, including the honest limitation that an agent cannot decide what a system was for.

The Agent Skills specification. The open standard that makes the skill a portable, declarative contract; read it as a specification format that happens to be addressed to an agent.

On the failure mode: the library drift paper (2026) names and measures what happens when a self-evolving skill library has nothing to answer to, and Addy Osmani’s Self-Improving Coding Agents is the most practical survey of the loop in the wild, including the periodic-refocusing discipline that combats drift in long runs.

Fred Brooks, No Silver Bullet: Essence and Accidents of Software Engineering (1986). The essential-versus-accidental distinction the whole argument sits on, freely available as Brooks’s own technical report.

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.

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 the articles that follow spend their 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 here, 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 carried forward here. 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 doing the real work 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 is the most expensive thing in this argument. 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 Comes With 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 covers who, or what, is building, and what it can actually promise. Information covers how the build sees and describes itself, and what it must carry. Interaction covers 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 moves is orthogonal, not linear. ELSA is the four moves any change runs through: Event, Language, Structure, Agency; a disturbance, what people call it, how the place is arranged, and who acts. ELSA names where in the movement you are; the three organisational questions are what you 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 of the three has a foundational thinker, the one the other articles here draw on. Identity belongs to Mark Burgess and Promise Theory. Information belongs to John Ousterhout and the discipline of complexity. Interaction belongs to Randall Collins and the ritual chains that generate the energy a building team runs on. The remainder of this article introduces what each of them holds 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 worth taking 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 holds 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 holds 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 questions are about how the builders relate, and its foundational 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 the sharpest and least nostalgic claim here, 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, here, 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 they sit 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 here 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 here 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.

The series runs four phases. The Learning articles ask whether an organisation can perceive at all, Deciding whether it can design under constraint, Building whether it can build an effective response, and Transforming what the change was ultimately for. Each phase enters the same four moves one position later than the last, so the four phases together complete a single turn of the cycle; Building enters at Structure, which is why it begins in construction rather than in a shock. The bridge that arrives here is From Deciding to Building, and the articles that follow take the three levers one at a time.

(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 everything here 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 strongest claim here 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 conscience of this whole argument 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.

Here is what actually moves an organisation. An event throws the received wisdom about what is possible into question. In doing so it opens up a new language of possibility, a way of talking about what could now be done that could not be said before. People reach for that language and start to organise around it, proposing new ways of working that the old vocabulary gave them no way to imagine. Out of those new arrangements a new kind of agency emerges, one that sustains and extends the change without anyone having to drive it. And then the most important thing happens: the completed change enlarges what people can see, which lets them identify and create the next event. Positive change is generative. It does not just solve the problem in front of it; it builds the organisation’s capacity to generate the change after that. This is a flywheel, and understanding it is the difference between an organisation that has to be dragged through every change and one that produces its own.

ELSA names the four movements this process passes through, so you can see which one you are in, which one you are avoiding, and why a change that looked complete keeps coming undone. The four are Event, Language, Structure, and Agency. They are not values, not stages of a maturity model, and not a checklist. They are the actual movements a change passes through to take hold, and the order matters, because each one produces the raw material the next one needs. This article explains each movement in its own terms, shows why they run in the order they do, explains the one transition that breaks the pattern, and shows how that break is what makes change generative rather than a thing you survive.

1. The Four Movements, in One Picture

Before the detail, the shape. A change begins with an Event: something happens that the existing way of seeing cannot account for, and in failing to account for it, opens a question about what is now possible. Then comes Language: people find words for the new possibility, because until it can be spoken it cannot be worked on. Then Structure: the new language gets built into something solid, a process, a team, a system, a budget line, or it stays just talk. Then Agency: people take the new structure and make it theirs, act through it without being told to, until it stops being an imposition and becomes simply how things are done.

That is one full turn. The catch, and the reason this is a cycle rather than a ladder, is what happens after Agency. Once a change is fully owned, the organisation can see things it could not see before; the new way of working reveals new possibilities, new questions, new events that were invisible from where it used to stand. The turn does not return you to where you started, and it does not just leave you exposed to the next external shock. It leaves you standing somewhere new, where you can see further, which means you can find and create the next event yourself rather than waiting to be hit by one. Change is not a line and not even a closed loop; it is a loop with a break in it, and the break is the most important part, because the break is where one change becomes the seed of the next.

2. Event: What Breaks the Old Frame and Opens a New One

An Event is not just news, and not every problem is an Event. Organisations handle most of what happens to them without any change at all, by fitting it into categories they already have. A competitor cuts prices: you have a playbook. A system goes down: you have a runbook. A regulation changes: you have a compliance process. None of that is an Event in the sense that matters here, because none of it requires the organisation to see differently. It is absorbed by the way of seeing that already exists.

An Event is the thing that cannot be absorbed that way. It is the development that does not fit any existing category, that the current playbook has no move for, that exposes a gap the organisation did not know was there. The arrival of a technology that makes a core skill cheap. A failure that the existing safety story said was impossible. A shift in what customers want that the segmentation model cannot describe. What makes these Events is not their size but their fit: they reveal that the organisation’s way of seeing has a hole in it, and the hole was always there, waiting for something to fall through.

But exposing a hole is only half of what an Event does, and the lesser half. The more important thing is that by breaking the received wisdom about what is possible, an Event opens a space that was closed before. As long as the old way of seeing held, certain things were simply not thinkable; they were ruled out so completely that nobody even argued against them. When the Event breaks that frame, those things become thinkable for the first time. The technology that makes a core skill cheap does not only threaten the people who had that skill; it makes a whole class of work newly possible that nobody could justify proposing while the skill was expensive. This is why the Event, not the leader, is the true agent of change. A leader can argue all day for a possibility that the prevailing wisdom rules out, and get nowhere, because the organisation has no room to hear it. The Event creates the room. It is the thing that makes the previously unsayable sayable, and only once something can be said can anyone organise around it.

This is why Events are so often denied. The first response to a genuine Event is almost always to treat it as a non-Event, to force it into an existing category and absorb it after all. The technology gets filed under “tools we already use.” The failure gets filed under “one-off, won’t recur.” The customer shift gets filed under “noise in the data.” Forcing the Event into an old category is not stupidity; it is the path of least resistance, because the alternative is admitting the way of seeing is incomplete, and that admission is expensive. But it is also where the possibility is lost, because an Event that is denied opens nothing. An organisation that can recognise an Event as an Event, rather than flattening it into something familiar, has done the first hard thing, and has kept open the possibility the Event arrived carrying. Most of the failure to change happens right here, before any change has even been attempted, in the refusal to admit that something has happened at all.

3. Language: The Vocabulary of the Newly Possible

Suppose the Event is admitted, and the possibility it opened is still alive. The organisation accepts that something has happened its existing categories cannot hold, and that something is now thinkable that was not thinkable before. Now comes the second movement, harder than it looks: building a language for the new possibility. You cannot manage, plan, fund, or assign what you cannot name. Until the new possibility can be spoken, in words the organisation can actually use, it cannot be worked on at all. It sits there as a felt sense that something has opened up, with no purchase for action. The language is not decoration on the change; it is the thing that enables the change, because it is what lets people point at the new possibility together and start to act on it.

Language work is the work of building new vocabulary, and it is genuinely creative, not a matter of looking up the right term. The organisation has to develop ways of talking about the Event that let people point at it, argue about it, and coordinate around it. This is why the early phase of any real change feels like a period of bad meetings and circular conversation. People are reaching for words that do not exist yet, describing the new thing in terms of old things it only half resembles, contradicting each other because they have not yet agreed on what to call what they are all dimly seeing. That apparent confusion is the work. It is the organisation manufacturing the vocabulary it will need before it can do anything else.

The failure mode here is the opposite of the confusion, and more dangerous. An organisation can skip the language work by reaching for a ready-made vocabulary off the shelf, the consultant’s framework, the vendor’s terminology, the industry buzzword, and adopting it wholesale. This feels like progress, because suddenly everyone has words. But borrowed words describe someone else’s Event, not yours. The organisation ends up fluent in a language that does not quite fit its own situation, and the gap between the words and the reality becomes a permanent low-grade dishonesty that everyone learns to talk around. Real language work produces words that fit your Event, even if they are clumsy, even if they would mean nothing to an outsider. Honest and clumsy beats fluent and borrowed every time.

4. Structure: Making the Words Solid

Language alone changes nothing. An organisation can develop a perfectly good vocabulary for a new reality and still do exactly what it did before, because talk is cheap and reversible. The third movement is Structure: building the new language into something that persists whether or not anyone is talking about it. A process. A team with a remit. A system that enforces a rule. A budget line that funds a direction. A role that did not exist before. Structure is what turns a way of speaking into a fact of the environment, something people run into whether they believe in it or not.

The test of Structure is durability without attention. If the change depends on someone championing it in every meeting, it has not yet become Structure; it is still Language being kept alive by effort. When it has become Structure, you can stop talking about it and it persists, because it is now built into how the work flows. The reorganisation that creates a new team, the pipeline that will not let unreviewed code through, the funding model that pays for the new direction rather than the old one: these are Structure, because they shape what happens by default, without anyone having to argue for them each time.

The strongest Structure is not imposed from the top; it is proposed from inside. Once people have a language for the new possibility, they begin to organise around it on their own, suggesting new ways of working, forming the team that ought to exist, drafting the rule that should hold, building the small tool that makes the new way easier than the old. This is the quiet engine of the whole cycle, and it only runs when the language is genuinely shared, because people can only propose structures they have the words to describe. A leader’s real job at this movement is less to design the structures than to notice the ones people are already reaching for and give them room to harden, rather than overriding them with a structure designed elsewhere. Structures that people proposed for themselves arrive already half-owned; structures imposed on them start the next movement at a disadvantage.

Structure is the movement organisations are best at, and that is precisely the danger. Building structures is what management knows how to do, so the strong temptation is to jump straight to it, to skip the Event and the Language and just reorganise, just stand up the new team, just buy the platform. A structure built on skipped work is a structure built on sand. It encodes either a borrowed vocabulary that does not fit, or no clear vocabulary at all, and so it produces a process nobody understands the purpose of, a team whose remit is contested from the first day, a system that everyone games because the reason for it was never made real. The most common artefact of failed change is a structure that works perfectly and serves no purpose anyone can articulate, because the purpose was never built before the structure was.

5. Agency: The Self-Sustaining Ownership That Emerges

A structure can be in place and the change can still not have happened. People can comply with a new process while privately treating it as an obstacle, follow a new rule while waiting for it to be quietly dropped, work inside a new team while their loyalty and their habits still belong to the old arrangement. Compliance is not the end of change. The fourth movement, Agency, is the point at which people stop treating the structure as something imposed on them and start acting through it as their own, exercising judgement inside it, defending it, extending it, using it without being told to.

This is the difference between a rule that is followed and a rule that is owned. A followed rule needs enforcement; the moment the enforcement relaxes, the behaviour reverts. An owned rule needs no enforcement, because the people inside it would not now choose to act any other way; it has become part of how they understand their own work. Agency is the movement where a change finally stops being something the organisation is doing and becomes something the organisation is. You can see it in the small signs: people improving the new process without being asked, defending it to newcomers, treating a violation of it as a violation of something they care about rather than a technicality.

Agency cannot be installed, and that is what makes it the movement organisations find hardest to force. You can mandate a structure; you cannot mandate ownership of it. Ownership has to be taken, by people, from the inside, and it can only be taken if the three movements before it were done honestly. If the Event was denied, people know the change answers no real question. If the Language was borrowed, people know the words do not fit. If the Structure was imposed without either, people know it is arbitrary, and you cannot own what you know to be arbitrary. Agency is where the shortcuts taken earlier come due. An organisation that skipped the hard early work can get all the way to a fully built structure and then stall here, permanently, with a change that everyone complies with and nobody owns, which is to say a change that has not actually happened and never will.

6. One Change, All Four Movements

The abstraction becomes clearer with a single change walked the whole way through. Take a composite example, the kind of thing that recurs across many organisations: a firm whose product teams have always shipped on a fixed quarterly release, and which now has to move to releasing continuously, many times a day. Watch where the change actually lives at each stage, and watch where it usually breaks.

The Event is not the arrival of the tooling that makes continuous release possible. The tooling is just a capability; an organisation can buy it and change nothing. The Event is the moment it becomes undeniable that the quarterly rhythm is now a liability rather than a discipline, that competitors releasing daily are learning from real users at a rate the quarterly firm cannot match, and that the firm’s whole way of seeing release as a periodic, ceremonial, all-hands event has a hole in it. Most firms deny this Event for a long time. They file continuous release under “risky for a business like ours,” or “fine for consumer apps, not for us,” forcing the new reality into a category that lets them carry on. The denial is comfortable, because admitting the Event means admitting that a rhythm the whole organisation is built around is now wrong.

Suppose it is admitted. Now the Language work begins, and it is messier than anyone expects. The firm has no shared words for what it is trying to become. People say “continuous” and mean five different things: some mean deploying daily, some mean deploying on demand, some mean small batches, some mean removing the release-approval committee, some just mean faster. The meetings go in circles because the vocabulary does not exist yet. This is the dangerous moment when someone reaches for a borrowed language off the shelf, adopts a brand-name methodology wholesale, and everyone suddenly has fluent words for someone else’s version of the change. The firm that does the honest work instead builds its own clumsy vocabulary, words that fit its actual constraints, its actual risk appetite, its actual customers, even if those words would mean nothing at a conference.

Then Structure, the part the firm finds easiest and therefore the part it is most tempted to rush. Now the new language gets built into things that persist: a deployment pipeline that will not pass code without automated checks, a standing rule that batches stay small, the dissolution of the quarterly release committee and the funding of the capability that replaces it. If this Structure is built on honest Language, each piece has a purpose people can articulate. If it was built on a borrowed Language or no Language at all, the firm ends up with a pipeline nobody trusts, a small-batch rule everyone games by relabelling large batches as small, and a committee that was formally dissolved but reconstitutes itself informally because the reason for dissolving it was never made real.

And finally Agency, where the change either becomes the firm’s own or stalls forever. Agency has arrived when engineers release small changes daily without being told to, when they would now find the old quarterly ceremony absurd, when they improve the pipeline unasked and treat a skipped check as a violation of something they care about rather than a rule to be dodged. If the earlier work was honest, this ownership grows naturally, because the change answers a question people genuinely feel. If the Event was denied, the Language borrowed, or the Structure imposed, Agency never comes; the firm gets a fully built continuous-delivery apparatus that everyone operates joylessly and nobody owns, reverting to quarterly habits the moment attention moves elsewhere. The change is complete on every dashboard and has not actually happened.

7. Why the Order Cannot Be Rearranged

The four movements run Event, Language, Structure, Agency, and the order is not a preference. Each movement produces the exact raw material the next one needs, and none of them can run on material that has not been produced yet.

Language needs an Event to work on; you cannot find words for a new reality you have not admitted is there. Structure needs Language to build from; you cannot make solid a vocabulary you do not yet have, and if you try, you will build from a borrowed one instead. Agency needs Structure to act through; you cannot own a change that has not been made into anything yet. And the whole sequence needs to have been done honestly, because each movement carries forward the integrity or the dishonesty of the ones before it. A denied Event poisons the Language. A borrowed Language poisons the Structure. An imposed Structure poisons the Agency. The shortcuts do not disappear; they travel downstream and surface at the end as a change that will not take.

This is why so many changes that look complete on paper quietly fail in practice. The structure is built, the announcements are made, the training is delivered, and a year later nothing has really changed, because the work was done out of order or with steps skipped. The organisation jumped to Structure because Structure is visible and fundable and looks like progress, and skipped the Event and the Language because they are slow, confusing, and produce nothing you can put in a status report. Then it waited for Agency to arrive on its own, and it never came, because Agency cannot stand on an Event that was never admitted and a Language that was never built.

8. The Break in the Loop

The first three transitions are transfers. A disturbance produces something to name; the naming produces something to arrange; the arrangement produces something to act on. Each is a translation: the disruption becomes words, the words become a built thing, the built thing becomes owned practice. The material changes form at each step, but it carries through. The line, despite the translations, is continuous.

The fourth transition is different, and getting it right is the whole point of treating change as a cycle rather than a line. Agency does not produce the next Event. There is no smooth translation from a fully owned change to the next disruption. The next Event, when it comes, comes from outside the entire settled situation that Agency produced. It is not the next logical step; it is the thing the new settled way of seeing also cannot absorb, the new hole in the new picture. The move from Agency back to Event is not a transfer at all. It is a rupture.

This matters practically, and it cuts two ways. The uncomfortable half: arriving at full Agency, at a change completely owned and working, does not protect you from the next change. The very completeness of the settled state is what the next Event will throw into question, and a deeply owned way of seeing is a deeply invisible one, so the new settled state carries its own new blind spots. There is no final structure, no terminal state where change is complete and the cycle stops. But the generative half is the more important one, and it is what the next section is about: the same completeness that creates new blind spots also gives people a higher place to stand, and from that higher place they can see possibilities, and create Events, that were invisible from where they used to be. The break is not only how the next shock gets in. It is how the organisation reaches the vantage point from which it can author the next change itself.

9. The Flywheel: Why Change Generates More Change

Put the cycle together and a property emerges that no single movement shows on its own. A completed turn does not just leave a change in place; it leaves the organisation able to see and do things it could not see or do before. People who have lived through one full cycle have a new language, new structures, and the lived experience of having taken something unfamiliar and made it their own. That experience is itself a capability. It lowers the cost of the next cycle, because the organisation now knows, in its body rather than its slide decks, that change can be admitted, named, built, and owned. And it sharpens the organisation’s eyes: from the new vantage point, things that were unthinkable before become merely difficult, and people start to notice Events, and even create them, that the old position could never have surfaced.

This is the flywheel, and it is the most important claim in this whole account. Positive change is generative. It does not consume itself in solving one problem; it builds the capacity to find and make the next change. An organisation that has turned the cycle honestly a few times stops being something that has to be dragged through transformation by exhausted leaders and becomes something that produces its own transformation, because its people can now see possibility where they used to see only the way things are. The leader’s role shifts accordingly, from forcing change against the grain to keeping the flywheel turning: admitting the Events, protecting the messy language work, giving room to the structures people propose, and getting out of the way of the agency that sustains it.

And here is the part that surprises people. The organisation that becomes good at generating its own change, as a by-product, becomes far better at absorbing change that comes from outside. The capability is the same capability. An organisation fluent in admitting Events, building honest language, and turning that into owned practice does not freeze when an external shock arrives; it runs the cycle it already knows how to run. The same machinery that lets it author internal change lets it metabolise external change, and lets it hear its own internal feedback, the quiet signals from the edges that something is shifting, because a culture practised at recognising Events is a culture that listens for them. Resilience to the outside world is not a separate programme you bolt on. It is what you get for free once the flywheel is turning, because the flywheel is built out of exactly the habits that resilience requires.

10. Reading Your Own Change

The practical use of ELSA is diagnostic. Take any change your organisation is currently attempting, or failing to attempt, and locate which movement it is actually in, as opposed to which one the plan says it is in. The gap between those two is usually where the problem lives.

If the organisation is busy and frustrated and going in circles, with lots of talk and no settled direction, it may be in honest Language work, which looks like failure but is not, or it may be stuck because it never admitted the Event and is trying to find words for something it will not name. If it has reorganised and built and announced, and a year on nothing has changed, it almost certainly jumped to Structure over skipped Event and Language work, and is now waiting for an Agency that cannot come. If people are complying without owning, going through the motions of a change they do not believe in, the structure was probably imposed without the language work that would have made it make sense. And if a change feels genuinely complete, fully owned and working without effort, the useful question is not how to defend it but what it now lets you see: from this new vantage point, what was unthinkable before and is merely difficult now? That question is how you turn a finished change into the Event that starts the next one, which is how the flywheel keeps turning.

The four movements give you a vocabulary for change that does not flatter the straight-line story. They tell you that the confusing early work is real work, that the visible late work is worthless without it, that ownership cannot be commanded, and that arrival is temporary. None of that fits on a tidy slide. All of it is what actually happens when an organisation changes, or fails to.

Where this sits: the series runs four phases, Learning, Deciding, Building and Transforming, and this article sets out the four moves all of them run on. Each phase enters the cycle one position later than the last, Learning at Event, Deciding at Language, Building at Structure, Transforming at Agency, so the four phases together complete a single turn of the same four movements. From Deciding to Building is the bridge into the current phase and The Build Is the Test opens it.

(An Organisational Prompt is something you can do now....)

Organisational Prompt

Pick the most important change your organisation is currently trying to make. Do not ask how it is going. Ask which of the four movements it is actually in.

Be honest about the difference between the plan and the reality. The plan almost certainly says you are in Structure, building the new thing, because that is the movement that produces fundable, reportable progress. The reality may be that you skipped the Event, never admitting clearly what happened that made this change necessary, and skipped the Language, never building words that fit your own situation rather than words borrowed from a framework. If so, the structure you are building is standing on nothing, and no amount of building will fix that, because the problem is underneath it.

Then ask the harder question. For each movement you have genuinely completed, was it done honestly or was it faked? Was the Event admitted or flattened into something familiar? Was the Language yours or borrowed? Was the Structure built on real words or imposed over a gap? You will usually find one movement where the shortcut was taken. That movement is where your change will fail, no matter how well the others were done, because the dishonesty travels downstream and comes due at Agency, as a change everyone complies with and nobody owns.

Fix the earliest skipped movement first. If the Event was never admitted, no language work will land until it is. If the Language was borrowed, no structure will hold until you have built words that fit. Going back to the earliest broken movement feels like regression; it is the only thing that actually moves a stalled change forward.

Then, when that change is genuinely owned and running on its own, ask the question that keeps the flywheel turning. Now that your people can see and do what this change made possible, what was unthinkable here a year ago and is merely difficult now? Name it out loud. That naming is how you turn a finished change into the next Event, and an organisation that does this on purpose stops waiting to be disrupted from outside and starts generating its own change from within. That is the whole point: not to survive one change, but to become the kind of organisation that makes the next one.

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.

A specification is not a system. It is a precise account of a system that does not yet exist, and the distance between the two is the distance this article is about. Deciding ended with an organisation that had, at last, converted its situation into something buildable: a bounded, described, owned account of what it had decided to make true. That account is real work, hard-won. It is also, on its own, inert. Nobody has built anything.

Every phase of this series ends by producing something the next phase cannot directly use. The gap is the point. Learning ended with a capacity, and a capacity is not a description, so Deciding had to begin by applying it to produce one. Deciding now ends with a specification, and a specification is not a system, so Building has to begin by constructing it into one. The transition is never a clean pass. It is a translation, and the thing being translated changes its kind in the crossing. This article is that translation: what deciding actually produced, why it cannot be handed straight to delivery, and where building has to start instead.

1. What Deciding Produced

Deciding ran a particular path. It began with Language; the discipline of describing the domain precisely enough to decide within it at all, Ohno’s work and Evans’s. It moved to Structure; understanding how the parts of the organisation relate when a decision is made, Beer’s work and Conway’s and Ackoff’s. It moved to Agency; the capacity of the people deciding to commit, to exclude, to choose rather than default, Simon’s work and Boyd’s and Kegan’s. And it ended at an Event: not a disruption arriving from outside, but a specific, bounded, buildable thing produced from the inside. The decision, properly made, is the Event. It is the trigger.

This matters because of what kind of object the Event is. It is not a strategy, which is a direction. It is not an intention, which is a wish. It is a specification: precise enough that someone other than its author could build from it, bounded enough that its edges are known, owned by someone who will answer for it. Deciding, at its honest end, does not produce a better opinion about what to do. It produces a thing with edges. And a thing with edges can be handed to someone else, which is exactly what makes the next phase possible and exactly what makes it dangerous.

2. Why the Specification Cannot Simply Be Executed

The intuitive model of what happens next is execution: the specification is correct, delivery is the faithful carrying-out of it, and the work is to manage that carrying-out efficiently. This model is wrong, and the whole of the argument so far has been quietly arguing against it.

A specification is a hypothesis. It is the organisation’s best current account of what should be built, and like every account it was assembled by people of bounded rationality, working from descriptions that were necessarily incomplete, inside a structure that shaped what they could consider. It will be partly wrong. This is not a failure of the deciding; it is the permanent condition of deciding, and the phase named it repeatedly. Schön called the alternative the swampy lowland, where real problems live and textbook procedures do not reach. Building is not the execution of a correct specification. It is the activity in which the specification meets reality and is corrected by it.

Which means the relationship between Deciding and Building is not sequential in the way a plan is sequential. The specification is the input to Building, and the operational knowledge Building generates is feedback that re-enters Deciding for the next pass. The transition is a translation precisely because a specification and a system are different kinds of thing, and the difference cannot be closed by careful project management. It can only be closed by building, and by treating what the building reveals as information rather than as deviation.

3. Why Building Starts at Structure

Each phase of the series enters its cycle at a different point, and the entry point is forced by what the previous group left behind. Building begins at Structure, and the reason is exact: a specification has to be constructed before it can do anything else, and construction is, first, a structural act.

Structure here has the literal Conway meaning. The teams that will build the thing, and the components the thing is made of, are the same shape; the communication structure of the organisation is reproduced in the architecture of what it builds, and this is not a tendency to be managed but a law to be designed with. Building starts by deciding the structure twice over: how the work is divided into teams, and how the system is divided into components, knowing that those two divisions will mirror each other whether or not anyone intends it. Deciding made structure visible as the thing that shapes decisions. Building makes structure the first thing constructed, because everything built afterwards inherits its shape.

This is the cleanest reason the bridge cannot be skipped. An organisation that takes a specification and moves straight to delivery, without first treating structure as the opening design decision, will get the architecture its existing org chart dictates, and discover the mismatch only when the system is built and rigid. Building starts at Structure so that the shape is chosen rather than inherited.

4. What Building Will Argue

Building runs its own path; Structure, then Agency, then Event, then Language; and although its full architecture belongs to the articles ahead, the shape of its argument can be set out here, because it is what this bridge points toward.

After Structure comes Agency, and Agency in Building has a dual meaning that becomes the central move. There is the autonomy of teams: whether the team that owns a component can make decisions about it without hierarchical mediation. And there is the agency of components themselves: in a system of services and software agents, each part makes promises about what it will do and what it will not do, and the coordination between autonomous parts is the promise, not the command. Building takes Promise Theory as its anchor for exactly this reason; it is the account of how autonomous agents, human or software, coordinate without a controller. Then comes Event; what happens when the built thing meets reality, the continuous signal from a system in operation, where Beer’s POSIWID and Ohno’s jidoka return as the disciplines of evaluation. And then Language; what the organisation learns from what it built, operational knowledge becoming the description that feeds the next cycle.

Building is inherently iterative in a way the earlier phases are not. Its final position, Language, feeds straight back to its first, Structure, for the next pass. Continuous integration, continuous delivery, continuous feedback: these are not modern delivery fashions but the Building cycle running fast. There is also a warning this bridge should name now. A system of autonomous parts coordinating through promises still depends on something the structural account cannot supply: the energy that keeps autonomous teams moving rather than draining. The cadence of a building organisation; its standups, its demos, its retrospectives; is not administrative overhead. It is where that energy is generated or lost, and the articles on building treat it as seriously as they treat architecture.

5. The Handover

So the bridge can be stated plainly. Deciding produced a specification: a bounded, described, owned account of what to build, which is a hypothesis and not a certainty. Building takes that specification and begins, at Structure, to construct it into a system; divides the work and the components together; gives the parts genuine autonomy and binds them by promises rather than commands; lets the built thing meet reality and treats what reality says as information; and turns that information into the language that starts the next cycle.

The gap between the two phases is real and it is not a defect. A specification handed straight to execution, treated as correct and carried out faithfully, produces a system that is an accurate construction of a misunderstanding. A specification carried into Building, treated as a hypothesis to be constructed and corrected, produces a system that gets better as it meets the world. The difference between those two outcomes is the entire reason this bridge exists, and the entire reason Building is a phase in its own right rather than a delivery function bolted to the end of Deciding.

Deciding asked how an organisation gets clear on what to do. The Building articles ask the harder and more exposed question: how an organisation builds an effective response, and stays honest with itself while reality tells it what it got wrong. That is where the series goes next.

One orientation before the change of question. The series runs four phases; Learning, Deciding, Building and Transforming. Each enters the same four moves one position later than the last, so the four phases together complete a single turn: Learning at Event, Deciding at Language, Building at Structure, Transforming at Agency. From Learning to Clarity was the previous bridge, and The Build Is the Test opens the stretch this one leads to.

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.

The data platform was approved in under an hour. The business case was clean, the vendor credible, the numbers held, and everybody agreed. Eighteen months later it was technically sound and strategically useless — built to answer questions the company had stopped asking. No one in that room chose badly. They optimised an answer to a question nobody had pinned down.

Most decision post-mortems look for the bad choice. They rarely find one. What they find instead is a decision taken without anyone having established two things: whether the organisation knew what it was deciding, and whether it had picked a sound way to decide it. A decision has two failure modes, and the visible one — the wrong call — is the rarer of them. The dangerous one is structural and almost invisible: a sound-looking choice produced by a process that was never fit for the decision in front of it.

This is the closing instalment on deciding, and its job is consolidation. These articles have moved through bounded rationality and satisficing, ubiquitous language and the discipline of going to see, viable systems and the purpose revealed by behaviour, heuristics and recognition and reflective practice, dissolution and incrementalism and orientation. Behind that variety is a single claim, the Deciding hypothesis: decisions are design challenges, and design is a sequence of decisions under constraint. If that is true, then a decision can be examined the way a design can be examined — not by whether you like the result, but by whether the process that produced it was sound. This article turns the phase into nine methods. Each one is a diagnostic, something you can observe, and a method, something you can do. They fall into three groups, the three levers that run through every phase of this series: Identity, Information, and Interaction. Used together, they answer the two questions a decision actually turns on. Do you know what you are deciding? And have you chosen a sound way to decide it?

The three levers are not a sequence. A decision is exposed to all three at once. Identity concerns who decides and what they are able to see; that is Simon’s territory. Information concerns how precisely the thing being decided can be described; that is Ohno’s. Interaction concerns how the parts of the organisation relate at the moment the decision is made; that is Beer’s. The nine methods are three to a lever. What follows is each of them, and then the consolidated diagnostic a practitioner can use.

Identity: Who Decides, and What They Can See

The Identity questions are about what constrains the decision-maker before the decision begins. Simon is its foundational thinker. Bounded rationality is not a flaw to be corrected by better training or more data; it is the permanent condition of every decider, human or organisational. No one sees the whole problem. The Identity methods do not remove the constraint. They make it visible, so that whatever is excluded is excluded on purpose rather than by accident.

1. Name what you will not do. Can the organisation state, for this decision, what it has ruled out? Simon’s satisficing carries an implication that is easy to miss: a decision is an act of exclusion. To decide is to close options, and if you cannot say which options you are closing, you have not decided. You have added a commitment alongside all the others and called it a choice. Drucker said the same thing in the language of boundary conditions — an effective decision specifies what it must accomplish, and by implication what it declines to attempt. Rumelt’s account of bad strategy is the diagnostic in negative form: bad strategy is the strategy that excludes nothing, the list of good things, the dog’s dinner of goals that reads as ambition and functions as evasion. The method is blunt. Require every proposal to carry an explicit statement of what it rules out. That statement is the decision. Everything else in the document is justification. And exclusion only counts as a decision if the thing excluded was genuinely on the table, which raises the next question: whether the decision was made at all, or merely inherited.

2. Tell choosing from defaulting. When was this decision last consciously taken? Bounded rationality has a second consequence. Most of what an organisation appears to decide, it does not decide. It defaults. The decision premise was set years ago, by someone who has since left, for conditions that have since changed, and it now runs unexamined because nothing has forced it back into view. March named the pattern: getting better at the wrong thing, the competency trap, in which the organisation refines an inherited answer with real discipline and never asks whether the answer still fits the question. Christensen’s incumbents did not choose to miss the disruption; they defaulted into the decision their existing customers and their existing margins had already made on their behalf. The default extends past answers to methods. An organisation inherits not only what it decides but how it decides — the committee, the business case, the steering group, applied to every decision regardless of type because they are simply what the structure produces. Schön named the underlying error, technical rationality: the assumption that every problem is a well-formed problem, to be solved by applying the standard procedure. Most real decisions are not in the textbook. They are in what he called the swampy lowland. The method: for any significant decision, ask when it was last consciously taken, and whether the method now being used was chosen for this decision or simply supplied by habit. If neither has an answer, you are not deciding. You are maintaining.

3. Hold competing designs without closing too early. Are there at least two structurally different options genuinely in play — and do they decide the question in different ways? Boyd’s OODA loop locates the advantage with whoever can hold a situation open longer and re-orient inside it faster, not with whoever commits first. Kegan’s self-transforming mind describes the developmental capacity this requires: the ability to hold a position and its opposite without needing the discomfort resolved before it has been understood. An organisation that collapses to consensus before its alternatives have been genuinely inhabited has not chosen between options. It has ratified the first one and staffed the rest. This is also the method where the way of deciding gets chosen. Two options that differ only in detail can be decided by the same procedure. Two options that are structurally different — build it versus dissolve the need for it, optimise the current system versus redesign it — cannot, and the gap between them forces the organisation to ask which way of deciding actually fits. Gigerenzer’s work belongs here: there is no single best method, only a method matched to its environment, and a fast heuristic will outperform an elaborate analysis in an uncertain world while the reverse holds in a stable one. Klein showed that experts under time pressure do not compare options at all; they recognise a workable one and simulate it forward. Kahneman completes the set with the necessary caution: know when the situation is benign enough to trust the fast judgement, and when it will punish you for trusting it. The method: require at least two structurally different options before any commitment, and make each option name the method by which it would be decided. Where the methods differ, you have found the real decision — which is not which option to take, but how to choose. Holding genuine alternatives, though, depends on being able to describe them precisely enough to tell them apart, and that is the work of the second lever.

Information: How Precisely You Can Describe What You Are Deciding

The Information questions are about whether the organisation can describe the thing it is deciding about with enough precision to decide within it. Ohno is its foundational thinker. Evans, whose ubiquitous language and bounded contexts run through the phase, is the software instantiation of an older and more general discipline, and that discipline is Ohno’s. Gemba is the instruction to go and see the actual place where the work happens, because the description that reaches the decision-maker has been smoothed, summarised, and quietly flattered at every level it climbed. Standard work is the current best description of how a thing is done, written down — not so that it can be obeyed, but so that it becomes the explicit hypothesis the next observation can falsify. The Information methods are the discipline of seeing precisely enough to decide.

4. Use one language for the domain. Do the people deciding, the people building, and the people operating use the same words for the same things? This is Evans’s ubiquitous language. Where a domain expert says one thing, a strategy deck says another, and the running system encodes a third, the organisation does not have a model of its domain. It has three, and the translation between them is exactly where meaning leaks out. Ohno would say the description has drifted from the gemba — that the account on the slide no longer matches the work on the floor. The test is auditory. Listen for translation. Where a meeting needs someone to explain what a term really means, the model is split, and every decision taken on top of it inherits the split without knowing it has. The method is not to mandate a glossary, which produces a document nobody consults. It is to put the people who decide, build, and operate in the same room using the same words until the words mean one thing.

5. Separate what you know from what you assume. For each claim the decision rests on, is it marked as known, believed, or hoped? This is the method that most directly tells you what kind of decision you are in, and therefore how it should be decided. A decision rests on claims, and the claims are not all the same. Some are known. Some are believed on reasonable evidence. Some are hoped, and dressed as believed. Taleb’s distinction is the sharp edge here: a decision in a domain of thin, well-behaved uncertainty can be optimised, and a decision exposed to fat-tailed, consequential uncertainty cannot. In the second domain the only sound methods are the ones that cap the downside, preserve optionality, and proceed by via negativa — removing the fragilising error rather than predicting the unpredictable. An organisation that has not established which kind of uncertainty it faces will choose the wrong method with complete confidence. Parnas gives the constructive form of the same instruction from software: a design should hide the decisions most likely to change, and to hide them you must first know which they are — which assumptions the design rests on and which are likely to change, and which are safe to build on. The method: mark every key assertion in a strategy or design as known, believed, or hoped, then check whether the volatile, consequential assumptions are the ones the decision is most exposed to. If they are, the method must change. Stop optimising and start limiting downside.

6. Make the model visible enough to be argued with. Is the model behind the decision explicit enough that a competent colleague could disagree with it on the substance? Evans treated the domain model as a designed artefact, not a diagram drawn after the fact to decorate a decision already taken. Ohno’s standard work is a hypothesis precisely because writing the current method down makes it challengeable — a thing the next observation at the gemba can prove wrong. Argyris named the failure mode with more force than anyone else here: the model that cannot be challenged is the one held as a theory-in-use, never surfaced, never tested, and defended most strongly by the people who deny holding it at all. Senge’s mental models and Nonaka’s movement from tacit knowledge to explicit are the same instruction approached from different sides. A decision model that lives only inside someone’s head cannot be improved, because it cannot be attacked. The method: make every decision model explicit enough that someone could disagree with it specifically. If no one can locate the thing to disagree with, the model is not visible, and the decision is being taken on faith. A precise description, though, is always taken inside a structure, and the structure has already shaped what the decision is allowed to be. That is the third lever.

Interaction: How the Parts Relate When the Decision Is Made

The Interaction questions are about how the parts of the organisation relate at the moment a decision is made. Beer is its foundational thinker. His POSIWID — the purpose of a system is what it does — is the most unforgiving diagnostic in the series, because it refuses to let an organisation describe itself by its intentions. Ackoff supplies the constructive move: the distinction between solving a problem inside the existing system and dissolving it by redesigning the system so the problem no longer arises. Conway supplies the structural fact the whole lever rests on: an organisation’s communication structure is reproduced in everything it designs, and that includes its decisions.

7. See the decision the structure will allow. Before asking what we should decide, have we asked what decisions this structure can produce? Conway’s law, generalised from software to decisions, says that a structure built around three divisions will produce three-division decisions, and a structure with no forum where two functions meet cannot produce a decision that requires those functions to agree. Alexander made the same observation in architecture: form is shaped by the structure of the context that produces it, and a form imposed against that structure will not hold for long. The decision an organisation reaches is bounded by the conversations its structure permits before anybody sits down. The method: before deliberating, map which decisions the current structure can and cannot produce. If the decision you need is not one the structure can produce, then the first decision is a structural one, and deliberating before you have made it is theatre.

8. Decide whether to redesign the system or optimise within it. When a problem recurs, is it being solved, or is the system that keeps generating it being redesigned? Ackoff distinguished resolving a problem, solving it, and dissolving it, and argued the highest move is dissolution — redesigning the system so the problem stops arising. Lindblom is the honest counterweight, and both are needed. Most organisations cannot redesign their systems at will, and should not pretend they can; they muddle through by small comparative steps, and incrementalism is a genuine method with real strengths in a world too complex to redesign with confidence. The point is not that redesign beats incrementalism. It is that they are different methods, and an organisation should know which one it is using and why it has chosen it. A recurring problem patched the same way every time is the signature of incrementalism applied where dissolution was needed — and applied not as a choice but as a reflex. The method: when a problem recurs, ask explicitly whether the problem lies in the decision or in the system that keeps generating the decision, and choose the method to match. Patch by intent, not by habit.

9. Check what the decision process actually produces. Does the way this organisation decides produce what it claims to produce? This is Beer’s POSIWID turned on the decision process itself. A process that reliably produces delay, or the diffusion of accountability until no one owns the outcome, or the protection of the largest existing budget, has those as its purpose, whatever its stated aim. The gap between what the process claims and what it does is the real strategy of the organisation, and it is observable, which is the standard this series sets for every probe. The military tradition examined earlier in the series supplies the constructive form: a decision is not complete until accountability for it is unambiguous and the process that produced it can be examined honestly after the fact. The method: take the last several significant decisions, compare what the process actually produced with what it claimed it would produce, and decide on the basis of the gap rather than the claim.

Choosing How to Decide

The nine methods do two distinct jobs, and it is worth separating them. Methods four, six, and seven test whether the organisation knows what it is deciding — whether the thing on the table has been described in one language, modelled visibly enough to be argued with, and bounded by a structure the organisation has actually examined. Methods one, two, three, five, and eight test whether it has chosen a sound way to decide — whether it has excluded on purpose, chosen rather than defaulted, held genuine alternatives, typed its uncertainty correctly, and matched redesign or incrementalism deliberately to the problem. Method nine tests both at once, after the fact, by looking at what the process produces over time.

These articles have, in effect, been assembling a small library of deciding methods, and the consolidation worth stating plainly is that there is no best one. Optimisation suits a described, stable, thin-uncertainty decision. Satisficing suits a bounded decision where optimisation is not available at any reasonable cost. Recognition-primed judgement suits a time-pressed domain in the hands of a genuine expert. Heuristics suit an uncertain world. Dissolution suits a recurring structural problem. Incrementalism suits a world too complex to redesign with confidence. Via negativa suits a decision exposed to consequential tails. The error diagnosed here, in one thinker after another, is almost never the wrong option. It is the organisation’s habitual method applied to a decision of a type that method cannot handle — and the misapplication going unnoticed, because the method itself was never chosen, only inherited.

AI sharpens this rather than changing it. As generation becomes cheap, the bottleneck in deciding moves decisively away from producing options and analysis and towards choosing well among them. A model will generate a credible business case, a plausible architecture, and a confident recommendation in the time it once took to schedule the meeting. None of that touches the two questions that actually matter. The organisation that treats AI as a way to produce more decisions faster will accelerate its existing pathologies. The organisation that treats it as a reason to get deliberate about what it is deciding, and how, will have used the tool for the one thing it cannot do itself.

The Consolidated Diagnostic

Nine questions. They are not a scoring rubric. They are the checks a practitioner runs before committing, and again afterwards, and the value is in the questions the organisation cannot answer, because each unanswerable question names a method it does not yet have.

Identity — who decides, and what they can see:

1. Can we state plainly what this decision rules out?

2. When was this decision last consciously taken, and was the method being used chosen for it or simply inherited?

3. Are there at least two structurally different options in play, and do they decide the question in different ways?

Information — how precisely the decision is described:

4. Do the people who decide, build, and operate use one language for the domain, with nobody translating between them?

5. Is each claim the decision rests on marked as known, believed, or hoped, and is the consequential uncertainty correctly typed?

6. Is the model behind the decision explicit enough that a competent colleague could disagree with it on the substance?

Interaction — how the parts relate when deciding:

7. Have we asked what decisions this structure is capable of producing before asking what we should decide?

8. When this problem recurs, are we solving it or redesigning the system that generates it — and is that a deliberate choice?

9. Does the decision process produce what it claims to produce, judged on the last several decisions rather than its stated aim?

If the organisation can answer the first six honestly, it knows what it is deciding and has chosen how. If it can answer the last three, the structure it decides inside is one it understands. If it cannot answer some of them, those are not gaps in the decision. They are gaps in the organisation’s capacity to decide at all, and they will recur under every future decision until they are closed.

Placement: Deciding, the second of four phases; Learning, Deciding, Building, Transforming. These nine methods belong to Deciding because every one of them interrogates a description before anything gets built. The three levers they cluster under, Identity, Information and Interaction, run through every phase and change only which thinker holds each one. Why Your Organisation Can't Decide is the synthesis that follows, and From Deciding to Building the bridge out.

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.

The methods are not the hard part. An organisation can run an exemplary process; two structurally different options on the table, every assumption the decision rests on marked, the domain described in one language, the structure mapped before anyone deliberated; and still produce a decision that goes nowhere. The previous article set out nine methods for deciding well. This one asks the question those methods provoke and cannot themselves answer: why, given the methods, do organisations still fail to decide?

The answer is not that they lack discipline, or courage, or the right framework. These articles have moved through Simon and Ohno and Beer, through Drucker and Ackoff and Conway, through Boyd and Taleb and Klein and a dozen others, and the finding that tends to recur is that the failure to decide is not an absence of something. The failure is the presence of something: a set of mechanisms, each one locally sensible, that combine to make a genuine decision almost impossible. An organisation that cannot decide is not broken. It works as its structure, its language and its inherited premises require. That is the harder problem, and it is the one this article closes on.

1. The Decision Was Already Made

Most of what an organisation treats as a live decision was probably settled long ago. Simon’s bounded rationality has a consequence that is easy to state and painful to absorb: no decision-maker reasons from a blank slate. Every choice is taken inside a frame of decision premises; assumptions about what the organisation is, who its customers are, what counts as success, which options are even admissible; and those premises were set by people who have since left, for conditions that have since changed. The meeting believes it is deciding. Mostly it is ratifying.

So many decision processes feel like theatre because they are theatre, in a precise sense: the performance of choosing, staged on top of a choice the inherited frame has already made. March named the deeper version of this. The competency trap is the organisation getting steadily better at the wrong thing, refining an inherited answer with real skill and never asking whether the answer still fits the question. The skill is usually genuine. So is the refinement. The trap is that both are aimed at a target the organisation defaulted into and never re-examined.

The first reason an organisation cannot decide, then, is that it does not know which of its decisions are still open. It treats settled premises as live questions and live questions as settled premises, and it has no routine for telling them apart. A decision it cannot see is a decision it cannot make.

2. The Description Never Arrived

Suppose the decision is genuinely open. It still has to be decided about something, and that something reaches the decision-maker as a description; a report, a deck, a summary, a model. Ohno’s discipline of seeing exists because that description is never the reality. The description is an account, smoothed at every level it climbed, and the decision taken on top of it inherits every omission blind.

These articles have named the ways this goes wrong. The language is split: the domain expert, the strategy deck, and the running system use three different vocabularies for the same thing, and the translation between them is where meaning leaks out. The uncertainty is mistyped: a decision exposed to consequential, fat-tailed risk is handled with the confident machinery built for thin, well-behaved risk, because no one established which kind they were in. The model behind the decision is invisible: it lives in someone’s head, unchallengeable because it was never made explicit enough to challenge. Each of these is a failure of description, and none of them announces itself. The room feels well-informed. It is well-supplied with confident accounts, which is a different thing.

The second reason an organisation cannot decide is that the thing it is deciding about was never actually described. A polished description of a misunderstood situation is worse than an honest gap, because the gap at least invites a question.

3. The Structure Already Chose

Even a genuinely open decision, precisely described, is decided inside a structure, and the structure has been quietly voting the whole time. Conway’s law, generalised past software, is blunt: an organisation can only produce the decisions its communication structure permits. A structure built around three divisions produces three-division decisions. A structure with no forum where two functions meet cannot produce a decision that requires those functions to agree. The deliberation is real. Its range was fixed before anyone entered.

Here is the mechanism behind a familiar and demoralising experience: the obviously correct decision the organisation simply cannot reach. People are not too stupid or too timid to reach it. The decision requires a conversation the structure does not hold, an agreement between parties the structure keeps apart, an owner the structure never appointed. Beer’s POSIWID is the diagnostic that makes this visible without mercy: the purpose of a system is what it does. If your decision process reliably produces delay, or diffuses accountability until nobody owns the outcome, or protects the largest existing budget, then those are its purpose, whatever the stated aim. Ackoff supplies the escape and also the catch. The recurring problem usually lives in the system, not in the decision, and the real move is to redesign the system; but most organisations cannot redesign at will, and so they patch the same problem the same way, and call the patching a decision.

The third reason an organisation cannot decide is that the structure has already narrowed the decision to the options it was built to produce, and the people deciding mistake that narrowing for the field of choice.

4. Why the Three Compound

Taken one at a time, each of these is manageable. The damage is in how they reinforce one another, and the direction of the reinforcement is not random.

Inherited premises determine what descriptions get commissioned: you rarely gather information about a question you do not know is open, so the settled frame quietly decides what the organisation will trouble itself to see. The descriptions that do arrive are shaped by the structure that produced them: each function reports in its own vocabulary, optimised for its own position, and the structure that keeps the functions apart also keeps their accounts from reconciling. And the structure, in turn, is held in place by the inherited premises, because the current structure looks natural and inevitable to anyone whose decision frame was formed inside it. Identity constrains Information constrains Interaction, and Interaction loops back to confirm Identity.

Hence the stability of the failure to decide, and why effort alone will not shift it. Work harder inside this loop and you get better descriptions of the wrong question, routed faster through a structure that was always going to produce the same answer, in service of a premise no one has examined. The loop does not resist effort. It absorbs the effort and converts it into the appearance of progress. Here is the honest and unwelcome finding of Deciding. The organisation that cannot decide is not falling short of its design. It is performing its design exactly.

5. Where the Loop Breaks

If the three reinforce one another, the question is whether there is any point of entry, and there is. The loop is closed, but it is not equally strong at every point. It breaks at Interaction, because Interaction is where the other two become visible and changeable.

Argument does not shift an inherited premise; the premise is not held as an argument, so argument does not reach it. You cannot, on its own, fix a description while the structure that distorted it stays intact; the next description will be distorted the same way. You can change how the parts relate. You can create the forum the structure was missing, appoint the owner it never named, build the channel that lets a true signal travel. And when the interaction pattern changes, the descriptions change, because new information now flows; and when the descriptions change, the premises become visible, because the organisation is now looking at the question it had defaulted past. Causation runs one way for understanding: Identity, then Information, then Interaction. It runs the other way for intervention: change Interaction, and the rest becomes reachable.

That is the structural reason deciding ends where it does, and the hinge into what comes next. Organisations get clear on what to do not by thinking harder but by changing how their parts relate; and changing how the parts relate is no longer a decision. The thing has to be built.

6. The Deciding Phase Was Always Pointing Here

Step back and the shape of the argument resolves. Its hypothesis was that decisions are design challenges, and design is a sequence of decisions under constraint. Nearly every thinker in these articles has been an instance of that single claim. Simon: deciding is satisficing under cognitive constraint. Ohno: deciding well requires seeing the constraint precisely, at its source. Beer: the structure is the constraint, and it must be designed, not merely inhabited. Ackoff: the highest decision is to redesign the system that generates the problem. Boyd: deciding is the continuous redesign of your own orientation. These articles did not assemble a toolkit of decision techniques. They made an argument, and the argument was that there is no clean separation between deciding and designing; that the moment a decision is taken seriously it becomes a question of design, and the moment a design is taken seriously it dissolves into a sequence of decisions.

The honest end of deciding, then, is not a better decision but a specification: a bounded, precise, buildable account of the thing the organisation has decided to make true. In the end, an organisation that cannot decide is one that cannot convert its situation into something buildable. It stays in deliberation, because deliberation is safe and building is exposed. The capacity to decide and the capacity to build are closer than they look, and the gap between them is the subject of everything that follows.

You cannot decide your way out of the inability to decide. At some point the talking has to become a thing with edges, handed to people who will build it and find out, against reality, whether the decision was any good. That is the next question, and the next problem.

Where this sits: Deciding, the second of the series' four phases; Learning, Deciding, Building, Transforming. These articles ask whether an organisation can turn what it knows into a description precise enough to act on, and this article is the account of why the three levers, Identity, Information and Interaction, hold each other in place and where the loop can be broken. The levers themselves are set out in Events Change Organisations, Not People. From Deciding to Building is the bridge, and The Build Is the Test opens this stretch of the argument that follows.

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.

Two rooms can be built to the same specification and only one of them is alive. You know it on entering, before you could say why: one room is comfortable, settled, somewhere you would choose to sit; the other is correct and dead. The specifications match. The materials match. Something the specification did not capture is the whole difference, and an organisation that cannot name that something will keep producing the dead version and signing it off as done.

Christopher Alexander spent fifty years on that something. He was an architect and a mathematician, after one question. Why are some places alive and most are not? And can the difference be taught? The answer he built is the most complete account in this series of what design actually is. For Deciding he is unavoidable. I have argued throughout this phase that decisions are design challenges, and that design is a sequence of decisions under constraint. Alexander worked that argument out in full first. He was building real buildings, and watching most of them fail to come alive.

1. A Pattern Is a Decision That Recurs

Alexander’s early work, Notes on the Synthesis of Form, treated design as the achievement of fit between a form and its context. A design problem is a knot of interacting requirements; the designer’s task is to find the places where the requirements cluster tightly and the places where they barely touch, and to cut the problem along the loose seams into sub-problems that can be solved nearly independently. Simon reached the same insight about complex systems in the same decade. The two men had little contact and were building one idea: a problem becomes tractable only when it is cut where its real seams are.

Decomposition was the analytical half. The generative half came later, and that is the pattern. In Alexander’s mature definition, a pattern is a recurring problem in a context, stated together with the core of a solution that resolves the competing forces the problem creates. Light on two sides of a room. A place to wait that is also a place to be. The exact form is never specified, because it will be built a thousand times and never twice the same; what is specified is the conflict and its resolution.

Hold on to what a pattern actually is. Not a template. Not a reusable component. A decision that recurs, captured. It is the distilled record of how one conflict of forces was resolved well, written down so the next person facing that conflict reuses the decision rather than the object. Build a library of your patterns and you are not building a catalogue of solutions. You are building a memory of your good decisions. That is a different and far more valuable thing.

2. The Forces Are the Point

The centre of a pattern is the field of forces: the genuine, competing pressures the situation creates. A room needs daylight and needs shelter from glare. An entrance needs to welcome and needs to secure. The forces are real, they pull against each other, and a pattern should earn its place only if its resolution actually holds both rather than sacrificing one.

This is the test Alexander cared about most, and it is the test most often skipped. Used to decorate, lifted in because it is familiar or because it looks like the kind of thing one does, a pattern resolves nothing; it suppresses one force and calls the suppression a design. His word for the result is dead structure. The building stands. The building is also lifeless, because the conflicts it was supposed to resolve are still there, merely hidden under a form that ignored them.

The organisational translation is direct, and it sharpens a distinction these articles have returned to repeatedly: the difference between a decision made and a decision performed. Name the competing forces honestly and resolve them and the decision is alive. It holds. Pick the comfortable option and suppress the inconvenient force and the decision is performed. It looks like a decision and probably will not hold, because the suppressed force is still pulling and will surface again, later and more expensively. He gives the phase its cleanest tool for telling the two apart. Ask of any decision which forces it claimed to resolve, then whether it resolved them or merely quietened the one complaining loudest.

3. The Quality Without a Name

The companion volume of 1979, The Timeless Way of Building, names the thing the patterns serve, and then refuses to name it with a single word. Alexander calls it the quality without a name: the property of being alive, whole, comfortable, free, exact, that some places have and most do not. The refusal was deliberate. Every available word, beauty or harmony or elegance, was too small and would be mistaken for a style.

The quality cannot be manufactured. That is the hard claim, and the one that matters here. You cannot specify wholeness in advance and have it executed, the way you might specify a dimension. Wholeness can only be generated, grown by applying a pattern language honestly to the actual forces of an actual situation. A place tends to come alive when each decision in the sequence genuinely answered the conflict in front of it, and to stay dead when the decisions were taken from habit, or from the catalogue, or to satisfy a sign-off.

For senior technologists this should land as something other than a metaphor. I have never met a technologist who has not seen it: the system, the team structure, the operating model that is correct on every measurable axis and somehow inert. Nobody wants to work in it. Nothing moves easily through it. No single defect explains the deadness. Alexander’s account says the deadness is real, diagnosable, and caused: it is what you get when a thing is assembled from decisions that did not resolve real forces. And it says the quality is observable rather than measurable, which is exactly the standard this series sets for everything it asks you to look for. You cannot put a number on whether a structure is alive. You can tell.

4. Wholeness Is Grown, Not Installed

If the quality can only be generated, then the method has to be generative, and Alexander’s later work is an attempt to say precisely how. Wholeness, he argued, is made of centres. These are local zones of coherence that strengthen one another, and a thing is alive to the degree its centres intensify rather than compete. And it grows by structure-preserving transformation: each healthy change strengthens the centres already present instead of erasing them. Change unfolds what is there. It does not demolish and replace.

That rejects the master plan directly, the big design fixed in advance and executed whole. Anyone who has watched a three-year transformation programme arrive complete and lifeless will feel the force of it. His alternative is piecemeal growth. Small increments, each corrected against the actual state of the whole as it stands, never one grand design imposed at once. In the vocabulary of modern delivery this is iterative development. Alexander reached it decades before the software industry did, and for deeper reasons. Continuous, incremental, structure-preserving change is not a project-management preference. Incremental growth is the only process that produces something alive, because wholeness cannot be specified ahead of the building; it can only accumulate, decision by decision, as each step answers what the last step revealed.

5. The Patterns Movement, and What It Missed

His idea crossed into software. The design-patterns movement of the 1990s took the form of the pattern directly from him, and the influence runs through the catalogues of reusable solutions that a generation of engineers grew up on. In 1996, at OOPSLA, Alexander was invited to address that community, and he used the platform to tell them, with care, that they had taken his patterns and missed his point.

The patterns, he said, were never about reusable solutions. They were about generating life and wholeness, about making places and things that were morally good in the sense that they made the people who used and built them more alive. The software community, he observed, had adopted the mechanism and dropped the purpose: it had a method for cataloguing solutions and had not asked whether the systems it built were good to live inside.

The warning is this series’ warning, and it is why Alexander belongs in Deciding rather than merely near it. Detached from its forces, a pattern becomes dead structure. A framework adopted as a catalogue, applied because it is the done thing rather than because it resolves a conflict that genuinely exists, becomes exactly the framework worship the series has rejected from the start. Alexander is the proof that a powerful idea about design survives only if it stays attached to the question of whether the result is alive. Drop that question and you keep the vocabulary and lose the thing the vocabulary was for.

Where this falls: Deciding, the second of the series' four phases, after Learning and before Building and Transforming. A pattern is a description of a conflict and its resolution, which is exactly what this phase exists to produce. Building then finds out whether the resolution holds under load. From Deciding to Building is the bridge, and Why Your Organisation Can't Decide the synthesis that closes the phase.

(An Organisational Prompt is something you can do now....)

Organisational Prompt

Take a recurring problem your teams keep re-solving, and write it up as a pattern.

Pick something that comes round again and again; a kind of integration that is always painful, a review that always stalls, a handoff that always loses information. Write it as a pattern, in three parts.

First, the context: when and where does this problem arise.

Second, and this is the part that does the work, the forces: the genuine competing pressures the situation creates, named without flinching, including the inconvenient one.

Third, the resolution: the core of what actually resolves both forces, not the form, the decision. Now look at how your organisation currently handles it.

If the current handling suppresses one of the forces rather than holding both, you have found a decision that was performed rather than made, and you have found why the problem keeps coming back. The pattern is not paperwork. It is the captured decision, and writing it honestly is the first time the decision is genuinely taken.

Further Reading

Christopher Alexander: Notes on the Synthesis of Form (1964). Design as the achievement of fit, and the decomposition of a problem along its real seams.

Christopher Alexander, Sara Ishikawa and Murray Silverstein: A Pattern Language (1977). The 253 patterns, each a recurring problem and the core of its resolution, linked into a generative language.

Christopher Alexander: The Timeless Way of Building (1979). The philosophy the patterns serve: the quality without a name, and the generative process.

Christopher Alexander: “The Origins of Pattern Theory” (1996 OOPSLA keynote). His address to the software community on what the patterns movement took from him and what it missed.

The Hillside Group: https://hillside.net/patterns/ - a repository of early patterns from a stalwart of the patterns movement in software.

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.

In 1972 David Parnas asked a question that sounds trivial and is not: given a system to build, on what basis do you divide it into parts? The conventional answer was to follow the steps of the work; one module per stage of processing, the structure of the software mirroring the sequence in which it ran. Parnas built the same small system both that way and a second way, and showed that the two were identical in what they did and entirely different in what they cost to change. One could absorb a change in a single part. The other spread every change across the whole. Same behaviour, same output, opposite futures.

Parnas was a software engineer, and one of the first to insist that software should be a real engineering discipline rather than a craft. But the question he answered is not a software question, and it is why he belongs in Deciding. He found the criterion for where to draw a boundary, and a boundary, as these articles have argued from several directions, is never neutral. It is a decision. Parnas tells you which decision it is.

1. Information Hiding Is Decision Hiding

Parnas’s answer to his own question was the principle he called information hiding. Each module should hide a design decision. The interface, the part other modules can see, exposes only what they need to know in order to use it. Everything else; how the work is actually done, what data structure holds it, what algorithm runs it; is secret, sealed inside the module where the rest of the system cannot reach it and, crucially, cannot come to depend on it.

The phrase is routinely misread as data hiding, the keeping-private of variables, and that misreading loses the whole idea. What a module hides is not data. It is a decision: a choice that could have gone otherwise and may one day have to be revisited. The interface is the part of the decision the rest of the system is allowed to rely on. The secret is the part the rest of the system is forbidden to rely on, so that it can change without anything else breaking.

This reframes what a system’s structure actually is. Two systems can do exactly the same thing and have completely different module boundaries, and the boundaries are the design. They determine what can change independently, what can be built in parallel, what can be understood without understanding everything else. The structure of a system is the set of decisions it has chosen to encapsulate. Build it well and each decision sits behind a boundary, changeable on its own. Build it badly and the decisions are smeared across everything, so that no decision can be revisited without revisiting all of them. Parnas made the structural fact unavoidable: every boundary hides a decision, and the quality of the system is the quality of that hiding.

2. Draw the Boundary Where the Change Will Be

If a boundary hides a decision, the obvious next question is which decisions deserve their own boundary, and Parnas’s answer is the sharp one. Draw the boundary around the decision most likely to change.

This sounds modest and is not. It means the structure of a system should be organised, not around what the system does, and not around the steps of its processing, but around a judgement about the future: which choices are volatile and which are stable. A decision that is likely to change should be sealed inside its own module, so that when the change arrives it is contained. A decision that will never change barely needs hiding at all. The whole architecture is therefore a set of bets about where change will strike, and the bets are made, consciously or not, the moment the boundaries are drawn.

This connects Parnas precisely to the rest of the phase. Simon established that complex systems must be decomposed to be tractable; Parnas supplies the criterion Simon’s account did not, the rule for where the decomposition should cut. Taleb and Christensen taught the phase to attend to volatility, to the consequential change the comfortable forecast leaves out; Parnas is the constructive answer to their warning, because designing for change means deciding, in advance, which assumptions are volatile enough to wall off. And it makes the boundary itself the thing to scrutinise. An organisation reviewing a design should not first ask what each part does. It should ask what decision each boundary is hiding, and whether that decision is one likely to change. A boundary drawn around a stable fact, or around a step of processing, is a boundary in the wrong place, and every future change will pay the bill for it.

3. The Honest Lie of the Rational Process

Parnas was too rigorous to pretend that real design proceeds cleanly. In a 1986 paper written with Paul Clements, he conceded the point most methodologies will not: no actual project ever follows a clean, rational, top-down design process. Requirements are not fully known at the start. People make mistakes. Priorities move. The real path of any design is a mess.

His response was not to abandon the rational process but to separate it from the record of the work. The documentation, he argued, should be written as if the process had been rational, even though it never was, because the person who later has to understand the system needs the rational structure, and does not need, and must not be given, a diary of the false starts. He called this faking it, and he meant the phrase without cynicism. Faking it is not dishonesty. It is the discipline of producing the clean account that makes a system comprehensible and maintainable, independently of the messy route by which it was actually reached.

There is a productive tension here with Schön, and the phase should hold both ends of it. Schön described how design really proceeds: as a reflective conversation with the situation, a thing of moves and surprises and reframings. Parnas does not deny that; he insists, on top of it, that the messy conversation must still resolve into a rational record, because the next person inherits the record, not the conversation. For an organisation deciding what to build, the lesson is exact. The deciding will be messy, and that is fine and normal. What is handed on must nonetheless be a clean, rational specification, because a specification is read by people who were not there when it was argued out, and a faithful transcript of that confusion helps none of them.

4. Software Ages, and the Cause Is Ignorant Change

Parnas’s last great theme, set out in a 1994 paper, was software aging. Software, he observed, degrades over time; not through use, since it does not wear, but through change. Every modification made without regard to the system’s original structure erodes that structure a little further, and the erosion accumulates until the system can no longer be changed safely at all and must be replaced.

His name for the mechanism is exact and unkind: ignorant surgery. A change made by someone who does not understand the design, who cannot see which decision each boundary was built to hide, and who therefore cuts across the boundaries rather than respecting them. Each such change works, in the narrow sense that the system still runs. Each one also leaves the structure slightly less coherent than it found it, until the structure is gone and what remains is merely code that happens to function. The defence Parnas prescribed is documentation and discipline: keep the structure visible and intact, so that every change can be made knowingly.

This is the point at which Parnas speaks most directly to the present. AI now generates and modifies code at a scale and speed no human team can match, and by default that modification is ignorant surgery industrialised. An agent changing a system it does not understand, that cannot see which decision each boundary was protecting, will produce working code and accelerate aging at the same time. The faster the generation, the faster the structure erodes, unless the structure is deliberately documented and the boundaries deliberately enforced. AI does not change what Parnas said. It raises the cost of ignoring it, and it shortens the time you have before the bill arrives.

5. The Decision Comes First, and Always Did

Stand back and Parnas resolves into a single instruction for Deciding. A module boundary is a decision. The decision is a bet about what will change. The structure of a system is the sum of those bets, and the system’s whole capacity to absorb the future is set by how well they were made. Information hiding, design for change, the faked rational record, the diagnosis of aging: four faces of one claim, that the durable value in any built thing is the quality of its decomposition, not the quantity of its code.

This is why AI, far from making design judgement less important, makes it the scarce thing. Generation is becoming nearly free; an implementation can be produced faster than it can be specified. What cannot be generated is the judgement about where the boundaries go, what each one should hide, which decisions are volatile enough to wall off. That judgement is the irreducible human contribution, and Parnas identified it half a century before the tools made it urgent. The organisation that treats AI as a way to produce more code faster will generate technical debt faster. The organisation that treats it as a reason to get deliberate about boundaries will build systems that endure. Either way the rule is the one Parnas stated in 1972: decide what to hide before you build what to show. The decision comes first. It always did.

Where this sits: Deciding, the second of four phases; Learning, Deciding, Building, Transforming. Information hiding is a Deciding discipline because a module boundary is a description of what may change, written before anything is built. Parnas carries forward into Building, where the same judgement decides how much generated code a human ever has to read. From Deciding to Building is where the question changes.

(An Organisational Prompt is something you can do now....)

Organisational Prompt

Take one component your teams have recently built, and ask what decision each of its boundaries hides.

Choose a component, a service, or a module that was built or substantially changed in the last few months, ideally one with AI in the loop. For each boundary it has; each interface, each seam where it meets another part; ask two questions. What design decision does this boundary hide: what choice is sealed inside, free to change without breaking anything outside? And is that a decision likely to change, or is the boundary wrapped around something stable, or worse, around a step of processing? If your team can answer cleanly, the component was designed. If they cannot, it was implemented, not designed, and it is already aging. Then, before the next component is built, write down the three decisions it must encapsulate, and only then generate it. The decisions come first. That is the whole of the discipline.

Further Reading

David L. Parnas: “On the Criteria To Be Used in Decomposing Systems into Modules” (Communications of the ACM, 1972). The foundational paper on information hiding. Twelve pages that changed how software systems are structured.

David L. Parnas and Paul C. Clements: “A Rational Design Process: How and Why to Fake It” (IEEE Transactions on Software Engineering, 1986). Why the documentation should be written as if the process had been rational, even though it never is.

David L. Parnas: “Software Aging” (Proceedings of the 16th International Conference on Software Engineering, 1994). How software degrades through change, and why ignorant surgery is the mechanism.

Daniel M. Hoffman and David M. Weiss (eds.): Software Fundamentals: Collected Papers by David L. Parnas (2001). The collected papers, with commentary. The best single entry point to Parnas’s 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.

She was describing, without using the phrase, what Donald Schön called a reflective conversation with the situation. Schön died in 1997, before any of this was possible; his subject was architects, urban planners, psychotherapists, and engineers working at drawing boards and with paper. But the shape of what he described is the shape of AI-augmented work. Every move is provisional; every output is a response; every specification is a hypothesis the material will shortly refute or refine. The plan does not survive contact with the artefact. The question Schön asked, and that this phase of the series has to answer, is what kind of thinking survives the collision.

1. The Swamp and the Hilltop

Schön’s most enduring image appears in The Reflective Practitioner (1983). The professional landscape, he says, has a high hard ground on one side and a swampy lowland on the other. On the high ground, problems are well-defined; techniques apply cleanly; rigour is possible. In the swamp, problems are messy, confusing, embedded in values and context; rigour in the technical sense is not available and the problems that matter live there regardless.

The dominant epistemology of the professions, which Schön called technical rationality, trains people for the high ground and then sends them into the swamp. You learn a body of scientific theory and a set of techniques; you apply the theory to solve well-defined problems; rigour equals adherence to method. The difficulty, Schön noticed, is that almost nothing of significance in professional life looks like this. Architects do not derive buildings from theorems. Managers do not produce optimisation problems to decide who is promoted. Engineers do not generate systems by deduction. They make moves, watch what happens, reframe, and move again.

Technical rationality is not wrong; it is wrong about where the real work happens. Simon’s bounded rationality, covered earlier in this series, sits on the high ground: an analytic account of how decisions are made when the problem can be stated. Schön’s critique was that most decisions in practice cannot be stated cleanly, and that the act of reaching for method before the problem has revealed its shape is itself where competence fails.

2. Knowing-in-Action

What do practitioners know, then, if not theory? They know how to do things they cannot quite say how they do. A skilled manager reads a room; a surgeon’s hands find the tissue plane; a jazz pianist alters a chord before the ear has named it. Schön called this knowing-in-action: knowledge bound up in the doing rather than ahead of it.

Bourdieu covered the same terrain with habitus, and Giddens with practical consciousness. Nonaka calls it tacit knowledge and describes the process (SECI) by which organisations try to convert it into explicit form. Gigerenzer’s adaptive toolbox, covered in the article just before this one, is its empirical cousin: a repertoire of fast and frugal rules that experienced practitioners select by feel. Klein’s recognition-primed decision is the same idea operationalised for fire-ground commanders. All of these thinkers describe expertise that is demonstrable, real, and resistant to articulation.

The implication for AI adoption is uncomfortable. The most valuable thing inside your organisation, the thing that makes experienced people better than new hires with the same credentials, is the part your specifications cannot capture. This is why document the process and automate it keeps producing automations that work on paper and fail in the building. The process was never the work. The work was the judgement running over the process.

3. Reflection-in-Action

Knowing-in-action is enough when the situation is familiar. The interesting question is what happens when it is not. When the ground shifts, when the artefact surprises, when the result is not what was expected, what does the practitioner do?

His answer is reflection-in-action, which is thinking on your feet. The practitioner does not stop to consult a theory. She reflects on the tacit understanding implicit in her action while continuing to act. She asks, silently and quickly: what assumption did I just make; what does the situation seem to be telling me; what would happen if I saw it differently. Then she makes a new move. The situation talks back again. She adjusts.

Reflection-in-action is not iteration in the modern software sense, though the two are related. Iteration is repeating a process with refinement. Reflection-in-action is conducting a conversation in which both parties may change. The practitioner learns from the situation, and the situation, in responding, takes new shape. Schön proposed five questions to judge whether a reframing is worth keeping: can the problem be solved as now framed; do I like what I get; is the new framing coherent; is it congruent with my fundamental beliefs; and has inquiry been kept moving. These are not metrics. They are the conscience of a practitioner who is still in the work.

4. Virtual Worlds

The reflective conversation needs a place in which to happen. Schön called these places virtual worlds: sketchpads, models, physical prototypes, simulations, any representation that lets the practitioner try a move and see its consequences without bearing the full weight of commitment. The drawing does not have to be right to be useful; it has to be wrong in an informative way.

Virtual worlds may be the most exact anticipation of AI-augmented work in twentieth-century management thought. An AI coding assistant is a virtual world. A generated prototype is a virtual world. A simulation of a process before it is rolled out is a virtual world. The purpose of these artefacts is not to produce the right answer on the first attempt. Their purpose is to let the material talk back, early and cheaply, so that the practitioner can reframe.

The organisations that get most from AI will not be the ones with the best prompts. They will be the ones whose people treat AI outputs as moves in a conversation rather than as finished products. Whether they develop that capacity is not a tooling question; it is a cultural one, which returns us to Argyris and the defensive routines that close reflection down long before the tools arrive.

5. The Specification Delusion

A large part of enterprise technology practice has assumed, for forty years, that the main difficulty is getting requirements right at the front. Waterfall projects institutionalised this. Agile reacted against it but retained the assumption that, given the right techniques, intent could be captured upstream of the build. Deciding of this series has been quietly dismantling that assumption from several directions. Evans showed that a domain model is not discovered before the code; it emerges through the code. Taleb showed that planning under deep uncertainty is a category error. The object-oriented design tradition, profiled in an earlier article, showed that every interface is a decision about what to hide. Schön is the philosophical floor beneath these arguments.

The belief that you can specify what AI should build before building it is, in Schön’s vocabulary, a pure expression of technical rationality. In practice, specification is a reflective conversation. You specify; the model generates; the output talks back; you respecify. Specification is not upstream of the build. Specification is the build, conducted in words rather than keystrokes. Organisations that still treat specification as a one-time activity at the front of a programme are preparing to deliver systems that met the early description and missed the later reality. Organisations that treat specification as a live conversation will produce systems that surprise them, sometimes for the better.

6. Repertoire and the Problem of the New Practitioner

There is a hard edge to this argument that deserves acknowledgement. Reflection-in-action depends on repertoire: the accumulated stock of examples, patterns, and half-remembered analogues the practitioner draws on to see a new case as like some older one. “Seeing as,” Schön called it, borrowing from Wittgenstein. Without repertoire, there is nothing to reflect with.

Here the AI adoption argument gets awkward. The practitioners best positioned to work well with AI are experienced people whose repertoires are deep. The practitioners most threatened by AI are junior ones who have not yet built those repertoires, and whose traditional training pathway (doing simple work under supervision) is the same work AI is now doing. The industry has not yet produced an honest answer to how the next generation acquires repertoire when the apprenticeship work has been automated. “They will learn by reviewing AI output” is the current answer, and it may turn out to be right; it has not been shown to be. If you are planning AI adoption and ignoring this question, you are accepting an unfunded liability on your organisation’s future capability.

7. Beyond the Stable State

Schön’s earlier and less-read book, Beyond the Stable State (1973), argued that there is no stable state to defend; institutions and the societies that contain them are in continuous transformation; belief in a fixed state to which things can return is itself the obstacle to learning. That is the premise of this series. It is also the premise that makes reflection-in-action a permanent requirement rather than a crisis response.

If the ground moves constantly, then every artefact in the organisation is provisional; every specification is a draft, and every structure is a hypothesis about a world already different from the one it was designed for. The practitioner who treats this as catastrophic will suffer. The practitioner who treats it as the normal condition of professional life, which Schön argued it always was, will find the work richer and less anxious. The swamp is not a failure mode. It is where the work happens.

Placement: Deciding, the second of the series' four phases; Learning, Deciding, Building, Transforming. Schön belongs here because reflection-in-action is what deciding actually looks like when the situation will not hold still long enough for a proper analysis. What an organisation gets out of that work is a description you can act on while knowing it is provisional. From Deciding to Building is the bridge into the phase that treats every artefact as a hypothesis.

(An Organisational Prompt is something you can do now to test the ideas of this article in your own organisation.)

Organisational Prompt

Name your reframings.

In the next project review, do not ask what went wrong or what went well. Ask three things:

(1) what the team was trying to do when the work began;

(2) what the material told them that changed their framing;

(3) and what they are trying to do now.

If nobody can answer the second question, the team is either working on a problem too simple to reward reflection or is pretending they never changed their minds. Both are warning signs. A team that can name its reframings is learning in action. A team that cannot is running a script.

Further Reading

Donald Schön, The Reflective Practitioner: How Professionals Think in Action (1983). Demanding but every page rewards patience.

Donald Schön, Beyond the Stable State (1973). The earlier, broader statement of the social theory behind the practice idea.

Chris Argyris and Donald Schön, Organizational Learning II: Theory, Method, and Practice (1996). Where Schön’s epistemology meets Argyris’s diagnostic framework.

Mark K. Smith, “Donald Schön: learning, reflection and change,” infed.org: https://infed.org/mobi/donald-schon-learning-reflection-change/. The most thorough free overview.

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.