The Model Was Never the Bottleneck

Three months into the rollout, a leader says it out loud: "We gave everyone Claude. Why aren't we shipping faster?"

It is a fair question. The license is paid, the tools are in every editor, the demos were real. And the burndown looks the same as last quarter. The uncomfortable answer is that the tool worked exactly as promised, and the promise was smaller than anyone measured.

You were never mostly writing code

Picture a normal feature. Five days from idea to merged. It feels like five days of engineering, because engineering is the visible part, the part with a person in an editor looking busy.

Now watch where the five days actually go. One day is three meetings to agree on what to build. Half a day is waiting for the one person who understands the billing module to answer a Slack message. Half a day is hunting for an API contract nobody wrote down. Two days is writing and debugging the code. A day is the pull request sitting in a review queue.

Coding was two of the five days. The AI cuts those two days to an afternoon. You saved a day and a half. The other three and a half days did not move, and now they are the whole visible cost. The team is not slower. You are finally seeing where the time was going all along.

The frictions the AI just exposed

You know these. You lived them last week.

The meeting that should have been a spec. Three alignment calls to decide what to build. The model writes it in twenty minutes. The twenty minutes were never the problem, and no tool speeds up a meeting.

The one person who knows. Half the work stalls waiting for the engineer who holds the payments module in their head. The model can read your repo. It cannot read a teammate's memory, and that memory is a single point of failure you have been routing around for years.

The contract that lives in someone's head. The AI asks for the shape of the API. Nobody can point to a document. It was "just known." So the work waits on a hallway conversation, same as before.

The vague ticket. "Improve onboarding." The model resolves ambiguity in the code, not in the intent, so it ships a confident, fast, wrong thing, and you find out what you actually wanted after three rounds of rework. Point speed at a blurry target and you reach the wrong place sooner.

And behind all of it, the code finished Tuesday still merges Friday, because the review chain never got faster while the writing did.

The good news is buried in the bad

This is not a failed rollout. It is the most honest measurement your organization has had in years.

The AI did the expensive-looking part for free and handed you a precise map of your real constraints. Most teams never get that map. They stay convinced the bottleneck is engineering capacity, hire more engineers, and watch the meetings and the waiting and the rework scale right up with the headcount. You now know better. The gate is not the coding. It never was.

The fixes are boring, and they already work

None of this needs a new tool. It needs the intent written down before the meeting, so the meeting shrinks or disappears. It needs the context committed to the repo, so the one person who knows stops being a bottleneck and becomes a file the model reads. It needs priority decided once, in writing, so the team ships fast in one direction instead of fast in five.

I have written each of these down already. That context is not a dev job is the load-bearing idea: half of what the AI needs lives outside engineering, in the heads of the people who own the why. The spec-driven loop is how the intent gets written before the code. And paying the setup tax once is how the tribal knowledge stops walking out the door every evening.

Run the test on your own week

Next time something takes too long, do not guess. Time it. Split the hours into two piles: hours the AI was writing code, and hours of everything else. The deciding, the waiting, the re-explaining, the approving.

If coding was the thin slice, stop asking the model to go faster. It already did. The next speedup is not a tool you can buy for the team. It is a process you have to build, and now you know exactly where to point it.