The Bottleneck Moved and Teams Did Not

Five bottlenecks across forty years. Goldratt’s discipline. Compilation, integration, communication, deployment, all downstream of the keyboard. The fifth move went upstream and the team did not move with it. Private decisions, rotting docs, agents without a kitchen. The hardest part was never writing the code.

There is a pattern in the way software actually gets built. The bottleneck, the thing that decides how fast a team can really move, never sits still. It shifts every decade or so, the industry chases it for a few years, beats it down to a manageable size, and then quietly discovers it has moved somewhere else. I have watched it move four times. The fifth is happening now, and most of the industry has read it as a story about tools when it is in fact a story about how teams are arranged.

The pattern has had a name for forty-two years. Eliyahu Goldratt published The Goal in 1984 and named what every operations team had already half-noticed: the throughput of any system is set by its single slowest step, and the work of management is to find that step, exploit it, subordinate everything else to it, then invest to remove it. The catch, which gets less attention than it deserves, is the last step. Once you remove the constraint, a new one will appear somewhere else in the system, and the discipline begins again.

The constraint always moves. The only question is whether you notice when it does.

In our discipline the constraint has moved roughly once a decade. The interesting thing about the first four moves, in hindsight, is that they all sat at the same end of the work.

The first four moves

The 1980s. Compilation. Builds took hours. Linking a serious C++ codebase was a coffee break with overflow. The industry attacked the problem with incremental compilers, distributed builds, faster languages and faster machines, and within a decade the build had stopped being the thing that decided how fast you could ship.

The 1990s. Integration. Branches diverged, big-bang merges took weeks, and a team of twenty engineers could spend a quarter trying to reconcile parallel work. Continuous integration, in its early Cruise Control form and then in the Jenkins generation, dragged that constraint out of the work. By the end of the decade integration had stopped being where the time went.

The 2000s. Communication. Distributed teams, late discoveries of misalignment, the gap between what the customer asked for and what the engineering team thought it had heard. Kent Beck’s 1999 book and the Agile Manifesto that followed were the response. A whole generation of practices designed to make the conversation cheaper and more frequent. By the late 2000s communication had stopped being the thing that broke teams, in the cases where the teams used the practices.

The 2010s. Deployment. Code sitting on a branch waiting for a release window. Manual ops, downtime, three-month release cycles. The DevOps movement, infrastructure-as-code, Kubernetes, the whole continuous-delivery stack. Jez Humble and David Farley’s 2010 book was the field manual. By 2020 most serious teams could ship multiple times a day, and deployment had stopped being the constraint.

All four of those constraints sat at the same end of the work: producing, integrating, or shipping code. The implicit assumption underneath every methodology of the last forty years has been that the slowest step lives downstream of the keyboard, somewhere between the developer typing and users running the result in production.

That is the assumption that has just collapsed.

The fifth move

In the last two years AI coding agents have arrived in development workflows in earnest. Cursor, Claude Code, the next generation of agents that follow. They write code at a velocity no human can match. They write tests, they debug, they scaffold whole features in an afternoon that would once have taken a week of careful keyboard work.

The industry has read this, almost unanimously, as the productivity miracle the previous forty years were building toward. Anyone with a credit card can now build a website. A founder can ship a prototype over a weekend. The dominant mental picture of AI-assisted development is one person at a keyboard, talking to an agent, and shipping.

This reading is a trap.

What it forgets is everything professional development teams have spent the last forty years caring about: architectural coherence, sustainability, security, the thousand small decisions about coding standards and naming and helpers-versus-inlining that determine whether a system you build tonight will still be habitable in six months. None of that is supplied by the agent. None of that is supplied by the person at the keyboard who does not know that any of it exists.

The trap is not that the agent does bad work. The agent does, increasingly, very good work for the prompt it was given. The trap is in believing the keyboard-to-deploy step has become so cheap that the rest of the process can be ignored. It has not. How the team arranges itself around the agent has become the entire game.

Where the constraint actually went

The fifth move is not where most teams have looked for it. It did not land at the back of the work, where the previous four constraints lived. It moved to the front.

The next chapter is the good news for professional developers. What makes someone a professional has not gone anywhere; it has moved upstream.

The new constraint is upstream of every line of code. It is in how a team arranges itself to get the most out of this new instrument. Who sits at the keyboard. What they know. What vocabulary they bring. How their work hands off to the next member of the team. Whether the team’s combined articulation produces something coherent or just produces something fast.

This shows up in three specific ways, and any team running agents in earnest will recognise all three.

1. Private decisions. An engineer settles a meaningful architectural choice in a forty-minute conversation with their agent and ships the work. The only record of how the team got there lives inside one private chat thread. By Thursday a colleague is having a different conversation with a different agent and reaching a different conclusion. Both are sensible. Both are inside the same codebase. Neither knows the other exists.
2. Decaying documentation. Institutional knowledge rots inside documents written for an older version of the system, the dynamic I went into at length in the second article in this series. Every team has a wiki, an architecture doc, a README. Six months ago they were correct. Now the system has migrated databases, the auth flow has been rewritten, two services have been merged into one, and the wiki still confidently describes the previous state. When the agent reads it, the agent does its best with what it has been given, and is now wrong with confidence.
3. Agents without a kitchen. Three engineers, three branches, three Claude or Cursor sessions running independently. Each one solves its piece coherently. None of them is aware of what the others are doing. Where a human team would have walked past each other in the kitchen and noticed the collision, the agents have no kitchen.

Each of those failures is a different face of the same constraint. The team has not arranged itself, at the front of the work, to give the agent and the rest of the team a shared, current account of what is being asked for and what has already been decided. The keyboard-to-deploy step has become very fast. The “what should we be writing, and who should be saying so” step is now where the team’s throughput lives or dies.

The new discipline

The chapter that comes next develops this argument at the level of the individual. The prompt is not the work; the prompter is. Not all prompters are equal. The vocabulary brought to the keyboard by a founder, a product manager, a designer, or a senior developer each produces a different artefact from the same instrument. The discipline that makes a professional AI-native team work is the orchestration of those vocabularies.

Goldratt’s discipline applies. We have to find this constraint, name it, exploit it, subordinate everything else to it for a while, and invest to remove it. None of those steps has happened seriously yet at industry scale, which is why we are in the moment we are in.

The hardest part of building software was never writing the code. It is being clear, together, about what to write.

— Barrie