Watch a relay team practice. The coach does not time the runners. The coach watches the handoffs, because the race is decided where the baton changes hands, and every runner knows the frustration of waiting at full speed for a teammate who is not there.
Organizations are relay teams, and AI is the fastest runner anyone has ever added to the track. The mistake almost everyone makes with a fast runner is assuming the race gets faster. The race gets faster only if the baton arrives at the fast runner's hand and leaves it without waiting. Where the baton waits, that is your race.
The hops so far
The constraint has been relocating for years, and each hop tells the same story:
First hop: generation. For most of computing history, producing the work was the constraint. Typing, drafting, coding, designing: if you wanted more of it, you hired more threads. That stage is functionally solved now. A model writes at hundreds of tokens a second against a human's forty words a minute, and the task horizon, the length of work a system completes unaided, has been doubling roughly every seven months, METR, March 2025. Nobody plans around the cost of producing a first draft anymore.
Second hop: verification. The instant generation stopped being scarce, review became the cost center. A team that can produce forty drafts a week with the review capacity for four does not have a forty-draft team. It has a four-draft team with a thirty-six-draft backlog. The evidence for this hop is not a metaphor, it is a measurement: in METR's early 2025 trial, experienced developers on their own repositories finished 19 percent slower with AI in the loop, because the speed landed upstream of the real constraint, and the surplus accumulated as cleanup. The review layer is where the money went, and the teams that noticed first built contracts, evals, and proof gates instead of hiring reviewers to read faster.
Third hop: judgment. Verification, too, is becoming machine-assisted: eval suites run on every change, drift alarms watch the outputs, sampling catches what the suite misses. As verification industrializes, the constraint moves one hop upstream to the only thing that cannot be mass-produced: deciding what is worth doing, what good means in this particular case, and which risks are acceptable. Judgment does not transfer, does not parallelize honestly, and is trained on real misses over real time. Teams that solved generation and verification now queue at the door of the few people whose judgment they trust, and the queue is longer than ever.
Each hop is permanent. Nobody un-solves a stage, and each solved stage hands its capacity, and its queue, to the next one.
The queue is the compass
The good news is that the constraint announces itself, if you let it. Work in any system accumulates exactly one place: in front of the node that cannot keep up. That is not a metaphor either. It is the oldest finding in operations thinking, and it has never needed adjusting for AI.
So the monthly question is not "how do we use AI better?" It is "where is the pile?" The pile is review backlogs. The pile is unanswered decision requests. The pile is briefs waiting on one founder's calendar. Whatever it is, that pile is your constraint, and new capacity anywhere else is furniture.
Four signals read the queue honestly:
- Where work waits the longest, measured, not remembered.
- Which meetings exist mainly to unblock a specific stage.
- What the fastest people in the organization are actually doing on a Tuesday, because your best threads gravitate to the constraint whether or not anyone planned it.
- Where errors are caught, because the stage that catches everything is downstream of the stage that misses everything.
Capacity at the node, humility at the pace
Two disciplines follow, and they are the whole operating model:
Add capacity only at the node the queue names. If generation is the pile, more models help. If verification is the pile, contracts and eval suites help, and another model does not. If judgment is the pile, then the highest-leverage purchase in the company is the founder's or leads' protected time, and no tool touches it. Speed added at the wrong node slows the system, and the 19 percent number is what that looks like when someone finally measures it.
Expect the node to move, and move before it does. The uncomfortable truth about this series is that every fix decays. The eval suite that cleared the verification pile will hand the constraint to judgment. The judgment you hired will hand it to direction-setting. The organizations that thrive are not the ones that solved their constraint once. They are the ones that re-asked "where is the pile?" on a calendar, re-staffed the answer, and kept the org chart honest enough to admit the baton had moved.
The race was never decided by the fastest runner. It was decided by the handoffs. It still is.
FAQ
How often should we re-check where the constraint is?
Monthly for the measurement, quarterly for the staffing decision. Constraints move faster than org charts, so the check needs to be cheap and the response needs to be incremental: protect time, add contract capacity, adjust the eval suite. Reorganizations are too slow to chase a queue, and usually arrive just in time to fix last quarter's constraint.
We have piles everywhere. Where does the first capacity go?
Behind the pile that touches customers or money first, then the pile your best people keep gravitating toward. When constraints are everywhere, the system is not actually flowing end to end yet, and the first move is picking one path from idea to shipped and clearing it completely, because a partially improved system just moves the pile somewhere less visible.
Does the constraint ever stop at judgment?
For the next while, judgment and direction look like the deep end, because they are the least machine-assisted stages. But the hop after that is already visible: teams with strong judgment now bottleneck on agreeing on direction, which is a trust and alignment problem, not a talent problem. The stages keep moving because the stages are made of humans and habits as much as tools.
What is the one-sentence version of this series?
Buy speed at the node the queue names, expect the queue to move when you do, and never mistake the fastest runner for the fastest team.
Related reading
- Ten People, One Hundred Agents
- The Review Bottleneck Is the Real Cost Center in AI Teams
- From Pull Requests to Proof
- Speed Is Not the Multiplier
- Judgment Does Not Transfer
- Human Judgment Is the Scarce Layer
- Teams Ship at Their Weakest Area, Not Their Average
- How to Navigate a Changing System
If your queue has moved and your staffing has not, book a discovery call.