The Wait Did Not Get Faster

One Point Two Five

Take a change that needs a hundred days to travel from request to customer. Thirty of those days are coding. Twenty-five are other hands-on work: specifying, reviewing, testing, releasing. The other forty-five are waiting, in a backlog, in a review queue, for an approval, for a release window.

Now make the coding three times faster, which is roughly what AI assistance promises.

a change that takes 100 days:
  coding                30 days
  other hands-on work   25 days
  waiting               45 days

coding 3x faster:       10 + 25 + 45 = 80 days    1.25x faster
coding 20x faster:     1.5 + 25 + 45 = 71.5 days  1.40x faster

Three times faster at the keyboard is a quarter faster at the customer. Twenty times faster is barely better. This is Amdahl's law, from 1967: speeding up one part of a process is capped by that part's share of the whole. The arithmetic is not news. What keeps surprising organisations is where the rest of the time actually goes.

coding 3x faster,
waiting cut by half:  10 + 25 + 22.5 = 57.5 days  1.74x faster

Leave the coding at three times faster and halve the waiting instead. The whole path moves more than any coding speedup could ever move it. The wait did not get faster when the work did. It was never in the work.

A Motor in an Old Factory

This has happened before. In “The Dynamo and the Computer”, the economic historian Paul David asked why electricity took so long to show up in factory productivity. His answer was the factory. By the early 1920s, he wrote, “only slightly more than half of factory mechanical drive capacity had been electrified”, and that was “four decades after the first central power station opened for business.”

For most of those years factories used what was called group drive. Electric motors turned sections of the old overhead shafting, and the belts and line shafts built for steam stayed where they were. The new power source sat inside a building designed around the old one. The gains came only with unit drive, a motor on each machine, when the shafting came down and whole factories could be redesigned: lighter, single-storey, laid out around the flow of work rather than the line of the shaft.

A delivery process built for human-speed coding is the shafting. Approvals, review queues, release windows and hand-offs between teams were all sized for a world where writing the code was the slow part. AI is the new motor, and most organisations have bolted it onto the old line shaft.

Where the Queue Went

The vendor reports agree on what that looks like, from three directions. DX's Q3 2026 report, covering more than 500 companies, finds weekly pull requests per developer up 75.5% over four quarters, and organisations producing the most AI code waiting 105% longer for a first review. LinearB's 2026 benchmarks, built from 8.1 million pull requests, report agentic pull requests waiting 5.3 times longer to be picked up than unassisted ones. Faros AI's Acceleration Whiplash report finds pull requests merged without any review up 31.3%. The queue either grows or gets skipped.

At the extreme end, Anthropic's merge volume rose from about 2,500 changes a day to more than 30,000 in four months, and the bottleneck moved to source control and CI built for human scale. That story, and what it did to review, is told in Reviewing Intent, Not Lines.

None of this is a new observation, and it should not be presented as one. Google's DORA 2025 report already calls AI an amplifier, magnifying an organisation's existing strengths and weaknesses. The finding is settled enough. What is missing is a way for a particular team to find its own shafting.

Waiting Is Not Work

That is what ABSORB is for: Agentic Bottleneck, Speed and Output Readiness Baseline. It is a diagnostic for one question, whether an organisation can turn faster AI-driven coding into faster, safer delivery, and it starts by splitting every stage of a typical change into two numbers instead of one: the hands-on time and the waiting time. AI shortens only the first. The constraint is found from the second.

Around that measurement sit eight dimensions where speed can stall, from flow and verification to ownership and the junior pipeline, each scored from evidence rather than impressions. The weakest one caps the result; a strong platform does not offset failing verification. And instead of a single maturity grade, the assessment decides which kinds of change can run with less human review: none beyond an AI check for documentation and test-only changes, one human for routine features, a named owner and a second reviewer for payments and migrations, explicit sign-off for anything critical. Readiness for each tier comes from the lowest of four scores, verification, governance, platform and ownership, because a safety case is only as good as its weakest part.

The whole thing runs as a single page in the browser. It sends nothing anywhere, which matters when the answers describe where an organisation is weak.

The View From Outside the Machine

Most of the work published here over the past year has been about the machine itself. Governance-Driven Design formalises intent before an agent runs. Governance-as-Infrastructure compiles that governance into constraints the run cannot cross. The Synthesis Gate puts the human exactly where ambiguity enters a workflow. Before the Arm Acts records when an agent paused and what a person decided, and Capability-as-Infrastructure asks what should survive while software is rebuilt around it. Each is an inside view: how an agentic system should be built and governed.

ABSORB is the first view from outside. It does not describe the machine; it asks whether the factory around it has been redesigned. A team that scores low on governance and intent is the audience for Governance-Driven Design. A team that cannot show who approved a change, or why, needs the kind of record the earlier work describes. The autonomy tiers follow the Synthesis Gate's logic at the scale of a whole delivery path: people stay wherever judgment has not yet been made checkable. The diagnostic says where; the earlier work says how.

Built to Be Wrong

A readiness framework is easy to write and hard to test, so ABSORB states in advance what would count against it. Eight hypotheses carry thresholds fixed before any data exists. If the stage the assessment names as the constraint matches the stage with the longest measured wait in fewer than 60% of teams, that claim fails. If two people scoring the same team land more than half a point apart per dimension on average, the scoring fails. Failures are to be published, and thresholds change only through a dated calibration log.

The assessment collects some of that evidence itself. Two colleagues can score a team separately, swap short codes, and see the statements where they disagree most, which is usually where one of them has seen evidence the other has not. A decision record asks for a prediction with a date, such as lead time from 32 days to 24 by the end of January, and at the next assessment says whether it happened and whether the constraint moved. Over a few rounds, a team learns how well it reads its own system.

Nothing has been tested yet. The framework is open, archived with a DOI, and marked plainly as a proposal. The first case where it is wrong will be worth more than another version.

Taking Down the Shafting

The forty-five days of waiting in that opening change were never coding problems. They were approvals designed for slower work, review capacity sized for fewer changes, ownership left unclear because it rarely mattered. A faster motor changes none of them.

The general shape is the one David found in the factories. A new capability arrives first, and the organisation around it changes later; the gains wait for the redesign, not for the technology. One point two five is what a new motor on old shafting looks like. One point seven four is what starts to happen when someone measures where the work waits and takes a section of the shafting down.

Related