Your Bottleneck Moved: How to Find the New One

Anthropic published an engineering post this week explaining that its code merges went from about 2,500 a day in May to over 30,000 a day by September, and that the thing which broke was not the writing of code but everything downstream of it. The company's own summary: coding is no longer the bottleneck, and the developer infrastructure built for human scale is. That is a very large version of a problem most businesses meet in a much smaller form.

Why the end-to-end time did not budge

Total elapsed time through a process is set by its slowest stage, not by the average across stages. So improving a step that was never the constraint produces a real saving in that step and no change at all in how long the whole thing takes.

This is the most common disappointment after an AI rollout. Drafting proposals went from two hours to ten minutes, everyone agrees the tool works, and the time from enquiry to proposal sent is exactly what it was in March. The ten minutes is real. It is sitting in a queue in front of whoever reviews the proposal.

Anthropic's post makes the same point in an unusually blunt way, noting that the latent demand for merging code is practically infinite and that every bottleneck they remove immediately produces more volume. Removing a constraint reveals the next one, and the gain only shows up once the new one is addressed too.

Measure waiting, not working

Businesses measure how long tasks take. The bottleneck shows up in how long items wait, and those are different numbers that rarely resemble each other. A quotation that takes forty minutes of work routinely takes six days to go out.

Take twenty recent items and record two timestamps at each stage: when the item arrived at that stage, and when someone started working on it. The gap is waiting time. Sum the waiting across stages and compare it to the total elapsed time, and in most processes the waiting accounts for the large majority of it.

That exercise takes an afternoon with a spreadsheet and beats most estimates produced in a meeting, because people reliably report how long their own step takes and have no visibility into how long items sat before reaching them. If the stages live in five different systems, assembling the timeline is itself the finding, as in breaking down data silos.

Four places it usually goes

New constraint	How it shows up	What usually helps
A reviewer or approver	Queue in one inbox, growing weekly	Approval thresholds by value or risk
A scheduled event	Nothing moves until Tuesday	Make the routine cases not wait for it
A system limit or re-entry step	Someone retypes output into another tool	Connect the two, or batch deliberately
An external party	Waiting on a client or supplier reply	Ask earlier, chase on a schedule

Reviewers are where most AI projects land, because reviewing is the step that scales worst. Producing ten times as much work does not make a reviewer's day longer, and a reviewer who was comfortably keeping up at the old volume becomes a queue almost immediately. That capacity problem is worked through in quality assurance when AI writes the first draft.

External waiting is the delay businesses tend to accept as fixed. It often is not. Much of the waiting on external replies is caused by asking for information late in the process rather than at the start, which is a sequencing choice rather than a fact about customers.

Not every constraint should be removed

Some steps are slow because they are doing something. A person reading work before it reaches a customer is a control, and removing it to improve throughput trades a visible delay for an invisible risk.

The question to ask at each candidate is whether the step is doing work or holding a queue. A weekly meeting that approves routine items under a certain value is holding a queue, and a threshold rule replaces it without losing anything. A reviewer checking numbers on a priced quotation is doing work, and the fix there is to narrow what they check rather than to skip them.

Removing a control and calling it an efficiency gain is how a speed improvement turns into a quality problem six months later, which is the pattern described in what happens when AI scales a broken process.

Expect to do this more than once

Fixing the constraint moves it. That is the normal outcome rather than a sign the work failed, and the useful posture is to treat bottleneck hunting as a recurring activity rather than a project with an end.

A quarterly pass is enough for most businesses. Re-run the twenty-item timing exercise, see where the waiting concentrated this time, and fix that. Three rounds of that usually produces a bigger end-to-end improvement than any single tool purchase, and the current state is worth keeping visible on a simple dashboard rather than rediscovering it each quarter.

Before you automate the next thing

Check that the step you are about to speed up is the constraint. The honest version of that check is the waiting-time measurement, and it is cheap enough that skipping it is hard to defend.

Drawing the process first makes the queues visible, which is what process mapping is for, and building the decision into the test is the discipline in designing a proof of concept that decides. Where the constraint turns out to be the quality of your records rather than any step, that is its own project, covered in quality data as the real bottleneck.

Frequently Asked Questions

How do I find the bottleneck in a process?

Look for where work waits rather than where work is hard. The bottleneck is the step with a queue in front of it, so find the stage where items pile up and sit. In most small businesses that queue is invisible because it lives in somebody’s inbox or in a folder called to review, which is why the obvious answer, the step that feels most effortful, is usually wrong.

Why did automating a step not speed up the whole process?

Because total time is set by the slowest stage, not by the average of all of them. Making a fast step faster changes nothing end to end, and making the bottleneck faster moves the constraint somewhere else rather than eliminating it. If drafting went from two hours to ten minutes and your turnaround did not change, the constraint was never drafting.

What usually becomes the bottleneck after AI automation?

Four candidates account for most cases. A person who reviews or approves, because their day did not get longer. A scheduled event such as a weekly meeting or a nightly batch, which sets a floor on how fast anything can move. A system with a rate limit or a manual re-entry step. Or an external party, such as a customer or supplier who still replies in two days.

Should I just automate the new bottleneck too?

Sometimes, and not reflexively. Some constraints exist for a reason, particularly review and approval on work that carries consequence. The useful first move is to check whether the bottleneck is doing real work or just holding a queue. A weekly meeting that exists to approve routine items can often be replaced by a rule; a person checking customer-facing output usually cannot.

How do I measure this without a system?

Take twenty recent items through the process and record two timestamps per stage: when the item arrived and when work on it started. The gap between those is waiting time, and summing it across stages usually accounts for most of the elapsed total. One afternoon with a spreadsheet gets you a picture accurate enough to act on, and it beats any estimate made in a meeting.