The constraint was never how fast your people could type. It was how much your organisation could decide.
You remember the demo. A function in four seconds. A test suite conjured from a comment. Someone in the room said “imagine this on every desk”, and a few weeks later it was: a seat for every engineer, a line in the budget, a slide for the board.
Six months on, look at the roadmap. Has it moved faster?
If you are honest: not really. The engineers say the tool is wonderful. The demos still land. The delivery dates did not. And you have a feeling you cannot quite put into a sentence — that you paid for speed and got busyness.
You are not imagining it. It has been measured, several times and several ways, often by people who wanted the opposite result.
What the numbers say
Experienced developers got slower and believed they got faster — in early 2025. In a randomised trial, METR had sixteen experienced open-source developers complete 246 real tasks in codebases they knew, with and without AI tools. With AI they took 19% longer — and afterwards still believed AI had made them 20% faster. Treat the number as a snapshot: the tools have moved since, METR’s own later work found the signal noisier, and some later estimates lean the other way. What has not moved is the finding underneath it: people are poor judges of whether AI made them faster, and the feeling and the measurement can point in opposite directions.
Individual output rose. Company delivery did not move in step. Faros AI, which sells engineering analytics, published telemetry from more than 10,000 developers across 1,255 of its customers’ teams. Where AI adoption was heaviest, people merged 98% more pull requests — and review time per pull request rose 91%. At the level of the organisation — deployment frequency, lead time, change failure rate — the same data showed no corresponding improvement. One vendor’s customers and a correlation, not a trial. But hold on to the shape: the output went up, and then it queued.
Ten hours saved, ten hours lost. Atlassian’s 2025 State of Developer Experience asked 3,500 developers. Sixty-eight percent said AI saves them more than ten hours a week; fifty percent said they lose more than ten hours a week to organisational inefficiency — finding information, switching tools, waiting on other people. Self-report, but 3,500 of it, all saying the same thing.
The benchmark saw it first. Google’s DORA programme found in 2024 that every 25% rise in AI adoption was associated with a 1.5% fall in delivery throughput and a 7.2% fall in stability. In 2025, at 90% adoption, throughput finally turned positive — and stability was still going the wrong way. DORA’s word for what AI does is amplifier.
Most enterprise pilots have not shown up on the P&L. MIT’s NANDA initiative reported — from executive interviews, a leadership survey and 300 public deployments — that 95% of the pilots it examined had no documented P&L impact. Read that word carefully: often nobody had defined a baseline to measure against. The report is not peer-reviewed, the sample is not a census of enterprise AI, and NANDA has an agent story of its own that sits neatly beside its diagnosis. It is an industry signal, not a law of nature. The signal is still worth having: the tools mostly improved individuals, and the organisations mostly could not say what that did for the business.
Different studies, different people, different instruments — and no single one of them proves what follows. What they share is a direction, and it recurs wherever anyone has looked: measured gains in individual productivity do not, by themselves, turn into faster organisational delivery. Something in between is eating the difference.
The thing in between is the coordination system
Fred Brooks worked it out in 1975: add people to a project and the work does not divide neatly, because every new person must coordinate with every existing one — n(n−1)/2 conversations to keep straight. The cost is not the doing. The cost is the agreeing.
What changed in the last two years is not that agreeing got harder. It is that doing got cheap — suddenly, and without the agreeing getting any cheaper. AI changes the economics of production faster than it changes the economics of coordination. When code, documents, analyses and customer replies cost almost nothing to produce, everything that was cheap by comparison — context, governance, prioritisation, the decision itself — becomes the expensive part. The constraint does not disappear. It moves.
It moves into the coordination system: the chain of stations a piece of work passes through before it counts as done. In software: engineering → review → security → architecture → legal → compliance → release → operations. In a bank, a hospital or a logistics firm the stations have other names, but there is a chain, and it moves at the speed of its slowest station — which is rarely the first one.
Inside that chain sits the head: its human decision-making component. The few people who review, resolve the conflicts, hold the architecture, decide which of two good ideas ships. It is small because judgement does not parallelise, and it is where the chain most often slows.
Now hand every engineer a tool that makes them produce more. You have not multiplied your capacity to deliver. You have multiplied the volume entering the chain at its first station, while every station after it runs at the speed it always did. In Faros’s telemetry the rise in review time is not a side effect of the gain; it is where the gain went.
That is the feeling, in a sentence — the one at the top of this piece, now with its evidence: the constraint was never how fast your people could type. It was how much your organisation could decide. AI attacked the wrong side. You did not buy speed. You bought more things to coordinate.
We felt it with three
This is not an argument from a distance. We run our own company on AI agents — not one assistant per engineer, but a handful of agents working forty-odd repositories, with one person at the head.
One night last week, three of those agents were working the same estate at once. Two drafted the same architecture decision under the same number, independently; one had to renumber across four repositories. One handed over a release, correctly — and twelve seconds later a routine merge from another put it silently back into draft, where it sat invisible for three hours until a third noticed. That release turned out to carry half of a feature whose other half was not ready, and would have switched off a live capability for a real customer. A peer caught that too, by reading production rather than the code.
Nothing on that list is a failure of intelligence. Every agent did competent work. Every problem was coordination: two producers, one decision; one artefact, two writers; one release, two halves. Three agents, one head — and the head’s evening went on refereeing.
Now imagine four hundred engineers, each with an agent, each producing more. Imagine the head.
Fewer hands, higher altitude
If the coordination system is the constraint, the answer is not more producers at its first station. But be precise about the problem, because it is easy to take this the wrong way. Autocomplete is not the problem. An engineer running an agent on the boring half of their week is not the problem. Unowned, unreviewed, unintegrated volume is the problem — output that nobody is accountable for, arriving at stations that never got faster. The fix is not to take the tools away. It is to put ownership, measurement and integration where the decisions are made — in the hands of the few people who already own them — so that what the agents produce at scale arrives already coordinated.
Three kinds of leader who own what AI produces at scale — while the engineers keep their assistants. Two of the three come with a product we sell, and you should read what follows knowing that; the shape would be the same if we did not, but that is exactly what someone selling a shape would say, so weigh it.
The platform leader owns the paved road — the specs, the project rules, the checks, the deployment lane — and runs agents that keep forty repositories on it. When a standard changes, forty pull requests appear, already conforming, already tested, because the agent inherited the rule rather than an engineer having to remember it. The head stops reviewing whether code follows the standard and reviews only the standard. That inheritance has one precondition: the rules must exist somewhere an agent can read them at the moment it writes. A standard in a wiki is a PDF to an agent. This is what we built SystemDox to be — a company’s specs, checks, project rules and architecture decisions, versioned in git and served to every agent over MCP, with the agents’ own decisions written back.
The support leader owns the customer’s voice and runs an agent that answers the questions customers actually ask — the ones the business has already decided the answers to, answered before anyone asks, from the company’s own words. Not a chatbot that improvises: a colleague that knows the approved answer, says nothing else, takes the enquiry when it cannot help and books the appointment when it can. That is Ema Answers: it reads the business’s own website, answers only from that, and hands the lead or the booking to a person with a name.
The business leader owns a number and runs an agent against it — pipeline, churn, unit economics — pulled, reconciled and explained every morning without a ticket to the data team.
Notice what each has that “a seat for every engineer” does not: a name. Someone is accountable for what the AI produces, because the AI produces it for them, against an outcome they own. The output reaches the head already coordinated, because the head asked for it.
This is close to what the evidence says the winners do. MIT’s 5% — the pilots that did document a P&L effect — let frontline managers drive adoption rather than a central programme, go deep on one workflow, and insist on systems that learn from feedback. DORA’s 2025 model of what makes AI pay lists a strong internal platform and a clear, communicated stance on AI among the capabilities that turn the amplifier the right way. Accountable owners on a paved road — that is the shape, in both. It is not a central AI committee; MIT’s data is unambiguous that those underperform. The leaders we mean are the ones closest to the outcome. Fewer hands, higher altitude — the altitude of ownership, not of hierarchy.
And strip the software away: it was never about coding assistants. The marketing team that can produce fifty campaign variants and approve none of them any faster. The legal team with a queue of AI-drafted contracts that each still need one lawyer’s judgement. The service desk that can answer instantly and has nobody to decide what the answer should be. The progression is the same everywhere — human productivity → AI productivity → coordination bottleneck → organisational architecture → an AI-native operating model — and most companies are at the third step believing they are at the second. Getting to the fifth is not a tooling decision. It is a decision about where judgement sits, who owns it, and what the agents inherit from it.
Monday
Three moves, in order.
1. Name the owners. Write down, by name, who is accountable for what AI produces in your company. If the honest answer is “everyone”, it is no one, and that is your problem in one line.
2. Measure at the company level. Lines of code, pull requests, hours saved — those are the metrics that told Faros’s teams they had doubled while their companies stood still. Measure lead time, change failure rate, questions answered without a human, revenue per decision. If a number does not move at the level of the business, the tool has not worked, whatever the demo says.
3. Build the paved road before you scale the traffic. Specs the agents inherit. Checks the agents cannot pass without. A release lane where nothing reaches production without the head’s approval — of outcomes, not keystrokes. Encode the coordination once, so every agent’s work arrives already coordinated. It is the unglamorous work that turns the amplifier the right way, and it is almost always skipped in favour of buying more seats.
The question worth asking is not how many of my people have AI. It is who, by name, is accountable for what our AI produces — and does the way we deployed it make that person’s job easier, or bury them?
If you gave it to everyone, you already know.
Interest declared above, restated here: this is the shape we run PuglieseWeb on — a handful of agents, one accountable head, a paved road they cannot leave — and two of the three leaders above have a tool we sell: SystemDox, which starts free on one repository, for the platform leader; Ema Answers for the support leader. If you want the whole shape applied to an organisation larger than ours, where those leaders are three different people, that is what we do.
Sources: METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (July 2025) · Faros AI, The AI Productivity Paradox (2025) · Atlassian, State of Developer Experience 2025 · DORA, Accelerate State of DevOps Report 2024 · Google Cloud, Announcing the 2025 DORA Report · MIT NANDA, The GenAI Divide: State of AI in Business 2025 · Frederick P. Brooks Jr., The Mythical Man-Month (1975).