Your teams can now produce more than your organisation can take in, and the numbers leadership watches reward them for it. That is the AI acceleration trap: the signal that says faster is the same one that hides the constraint.
In February I wrote about the acceleration trap, borrowing the phrase from Mike Fisher’s When Change Outruns Us: change that arrives faster than people can make it part of their work. The examples then were reorganisations and transformation programmes. AI adoption fits the pattern better, because it removes the natural brake. A reorganisation needs a decision and an announcement. A hundred extra pull requests a week need neither.
The hockey stick
Gergely Orosz visited OpenAI to see what changed once Codex took over. Venkat Venkataramani, VP of Engineering for applied infrastructure, told him that pull requests per engineer are growing like a hockey stick and that every part of the build-test-deploy pipeline is seeing dramatically more load. On some systems the load is roughly ten times higher, growth that would normally take two or three years, arriving in about six months.
OpenAI has the engineers to rebuild its version control, CI/CD and release process, and by its own account is heads-down on exactly that. Many companies will meet the same pressure with a pipeline sized for last year’s volume.
Where the queue forms
Allen Holub writes: a 10x improvement in development does you no good at all if there’s an upstream or downstream bottleneck that’s throttling the flow of work. Faster production only moves the constraint to the next place where a person, or a process built for people, has to say yes: code review, security sign-off, release approval, and for mobile apps, the store’s own review.
Sulman Choudhry, who leads engineering for ChatGPT, told Orosz: code generation is getting dramatically faster, but getting that code into users’ hands on native mobile is not. When I wrote about Asana’s two-week migration, the one cost that did not shrink was review. A person still had to read every change. That is manageable for uniform, mechanical diffs and it is the ceiling almost everywhere else.
Queueing arithmetic explains why this arrives as a surprise. While work arrives more slowly than it can be handled, waits stay short and nobody notices. Once arrivals pass capacity, the queue grows every day and never drains: the dashboards look healthy on Monday and the release is frozen on Friday. In the meantime the pressure on the reviewer is to skim, which turns review into a rubber stamp. More reviewers is the obvious answer and only a partial one: Brooks’ Law is a reminder of what adding people does to coordination.
The trap closes when strain is answered with more of the same. Review is slow, so a team adds another agent to draft the next batch. Releases queue up, so someone automates opening the pull requests. Every dashboard leadership watches (pull requests merged, features shipped) reads the extra output as progress, so nothing tells anyone to stop.
Open source has already shown where this ends. When Daniel Stenberg closed the curl bug bounty in January, he wrote that the share of submissions confirmed as real vulnerabilities was somewhere north of 15% in previous years and plummeted to below 5% from the start of 2025, and that the never-ending slop submissions take a serious mental toll to manage and sometimes also a long time to debunk. The submissions came from outside, but the mechanism is the same: a fixed-size team facing a rising flow through a review step that cannot scale. Curl could not review faster, so it cut the intake. An internal team cannot close its intake outright, but it can set the same limit on purpose, before the queue sets it for them.
What nobody instruments
A queue is at least visible: work waits, and someone eventually notices. The harder loss is understanding. A change that has been merged has not necessarily been absorbed: someone has to know what it does, why it is there and what it touches, or the next change lands on ground nobody can describe. I made that case in Cognitive Coverage. The integration tax is the same failure between teams, and absorption is its counterpart inside one.
Measuring the queue
Four changes, in the order I would make them:
- Measure the wait, not the output. Track how long finished work sits waiting for a human: time in review, time to approval, and lead time from the moment the organisation learns of a need to the moment a user has the change, as Holub argues. Put the wait on the same dashboard as the output, so a rising output line cannot read as good news on its own.
- Cap what you start at what you can absorb. Set the limit at review capacity, not at how much the agents can write: no more open agent-authored changes per reviewer than that person can read properly. Starting more than that lengthens the queue without adding a single delivery.
- Automate the gates before you widen the funnel. OpenAI’s own answer is agents on the review side: Venkataramani describes agentic code reviews that examine a change through several lenses. That only works if the reviewing agent has something to be judged against, which is why the evaluation harness comes before the agent.
- Run adoption as a loop. One workflow, one measurement, one decision, then the next, as I argued in AI Transformation Is a Loop, Not a Programme. Each pass ends with the result absorbed before the next begins.
Ask the February question again, with AI in it: is your organisation producing faster than its people can take it in? If you cannot answer, you are measuring the wrong thing. If the answer is yes, ten times the output into the same absorption capacity buys you a queue.
Leave a Reply