In August 2026 I was one of five engineers building the backend of a procurement intake system for a global CPG manufacturer, with each of us driving a Claude Code session against the same repository. Somewhere in the second week a five-story-point package went from claimed to delivered, with tests, in about fifty minutes. That number is not the interesting part. The interesting part is what happened to the rest of the schedule once numbers like that became normal.
The plan said it first
Our implementation plan went through several versions before the build started. Version 2.7 replaced the time model. Story points stayed as the unit of scope, but the conversion to calendar time was cut to roughly 0.2 to 0.3 machine-days per story point including review, with each machine running two or three Sonnet packages in parallel per day-cycle. That turned a 271-point backend into a four-to-five-week build across three machines.
The same version of the plan added a sentence I have quoted more than any other since: “The bottleneck is no longer coding.” It then listed what the bottleneck was instead: external calendar gates such as sandbox credentials and security review slots, which agents cannot move; human review and approval capacity, because every package still needs its review serviced and merged; and integration serialization, because one person owned the single migration head.
That list was correct. We just did not fully believe it until the queues formed.
How the model tiers were set
The plan assigned models by role. Opus plans, orchestrates, integrates and reviews. Sonnet implements and reworks. Haiku does mechanical extraction and formatting. The integrator’s orchestration session was the single longest-running context in the build and dominated token burn, so it was moved to a cheaper Opus tier two days in, and the review model was pinned explicitly a few weeks later so that “Opus” meant one thing everywhere.
Then came what the plan calls the model-economy policy, adopted after a burn review in the second day-cycle. Opus reviews once per package. Reviews of high-risk packages run on a different machine from the one that wrote the code. The integrator verifies inline instead of commissioning a second Opus pass. Rework is capped at two rounds before it escalates to a human. Target package size is eight story points and one coherent contract.
Every one of those rules is about spending the scarce thing carefully. The scarce thing was never Sonnet’s time.
What the cycle times looked like
The process review on 20 August recorded a few cycle times side by side. A five-point package, self-claimed: about fifty minutes from claim to delivery. A high-risk package the same day: built by 09:36, verdict around 14:30, about five hours, and one reroute of the review in the middle cost roughly three of those hours. Another high-risk package went through dispatch, delivery, rework and re-review inside one day.
Read those together. Build time is minutes to an hour. Review and routing is hours. The reroute alone cost three times the build.
The single door
In late September the integrator went on leave for a week. A ruling made the two remaining leads each other’s authority, so nothing waited on the absent person. That worked for most of the build. But for one workstream, a security-sensitive sign-on change, every ask and every approval was routed through one person who was also the second approver on a parallel pilot.
The measured result, from a comparison the contract steward wrote on 29 September: one merged pull request in twelve days, with 260 hours to the first reviewer comment. Over the same window the pilot, which had two approvers and the sponsor’s daily attention, merged 20 pull requests with a median of 20 hours to first review.
The comparison was nominally about coordination substrate, git-only versus a hybrid with the tracker. Its author refused to let that be the headline: “Most of that gap is not the substrate.” The largest delay was a people-topology effect. Its third recommendation was “Fix the topology, not only the tooling,” meaning give the slow workstream the same two-approver shape the pilot had. No tool fixes a single door. It only shows you the queue.
The numbers that did come from the substrate
The same report did find things the substrate explained. The git-only side spent 69 percent of its commits on reminders, 85 of 124, that a tracker would have generated for free. The hybrid side spent 38 percent of its commits exporting tracker state back into git, produced about 1,509 work-item revisions in a week, and triggered a notification flood of roughly 16,000 mails that the team then had to silence. Output tokens per merged pull request were 0.28 million on the hybrid side and 5.9 million on the git-only side.
I include those because they are real, and because the report’s own caveats are the model for how to present measured results. One like-for-like data point. Cache reads dominate both sides. The fast git-only completions were self-merges with no review, which is a lane, not a review. If you only read the table you learn the wrong lesson.
What changed in how I plan
I now plan a build with agents by counting human minutes, not machine hours. The questions I ask before kickoff:
How many people can approve, and are any of them a single door for anything? What are the external gates, and what is the fallback if each one stays closed? Who owns the serialized resources, migrations above all, and what is the queue discipline? How many review rounds are we willing to pay for before a human looks?
Coding capacity is the one question I no longer ask. The agents will outrun whatever answer I give.
What I’d tell you to do
- Write the sentence “the bottleneck is no longer coding” into the plan, then list what it is instead. The list is the plan.
- Assign models by role and set a spend policy for the expensive one: review once, verify inline, cap rework rounds.
- Measure claim-to-delivery and claim-to-merge separately. The gap between them is your real schedule.
- Never let one person be the only approver for a workstream, especially during leave. A second door is cheaper than any tool.
- When you publish a comparison, lead with the caveats that would change the reading. Your team will trust the next number more.