# Redesign the work, not just the tooling Status: draft. Owner: Andrew Flett. Last reviewed: 2026-09-23. Canonical: https://agentic.madebymany.com/knowledge/redesign-the-work A steady supply of reports now puts AI's effect on developer productivity at somewhere between 5% and 15%. The figures are surprisingly low, suspiciously consistent, and they all arrive at the same recommendation: keep the teams, keep the process, add the tool, expect a modest return. They also measure one narrow thing, how fast a developer gets through a task, and they get read as what to expect across the whole of making a product: the research, the design, the decisions about what to build, the checking, the shipping. Almost all of them measure the same arrangement. Agents are dropped into a process designed for people, the process carries on as before, and the gain is whatever that process allows. > Put agents into a process built for people and you get an efficiency gain. Design the work around agents and you reach the real opportunity, most of which is still unrealised. [Over half of developers](https://blog.jetbrains.com/research/2026/08/how-much-code-do-developers-really-let-agents-write/) now write less than a fifth of their code by hand. One in five writes none at all without AI. Around a fifth hand almost everything to an agent. That is a change of job rather than a speed-up, and it took about eighteen months: the same survey of 15,000 developers has [90% using an agent at least weekly](https://blog.jetbrains.com/research/2026/08/ai-coding-agent-adoption-2026/) by mid-2026. Organisational output has not moved with it. The share of companies reporting any effect on earnings is the same this year as last, on considerably more spending. ## Last year's number measures a different technology AI capability is not improving gradually. It leaps, the leaps come months apart rather than years, and each one changes what the tool is rather than how fast it goes. Autocomplete became chat, chat became an agent that plans across files and runs the tests, and one agent became several running at once. A figure from last year is a measurement of a technology that has since been replaced. That is the problem with the figures in circulation. [The 55%](https://arxiv.org/abs/2302.06590) is from 2022, one task, autocomplete. [The 26%](https://pubsonline.informs.org/doi/10.1287/mnsc.2025.00535) was published this year from trials that began in September 2022. [The 19% slowdown](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) ended in June 2025 and [its authors say](https://metr.org/blog/2026-02-24-uplift-update/) it is already out of date. All three measured GitHub Copilot, which [fell from 29% adoption to 21%](https://blog.jetbrains.com/research/2026/08/ai-coding-agent-adoption-2026/) in the year to mid-2026 while Claude Code went from 18% to 39% in five months. > The question is where this goes in six months and how radically an organisation could work as a result, not what autocomplete did to a traditional process in 2025. The studies also measure the wrong thing. They timed a developer typing, with a tool suggesting the next few lines. That is not how software gets written any more. A developer describes what is needed, and an agent plans the change across the codebase, runs the tests, reads what failed, fixes it and comes back when everything passes. No controlled trial has caught up with that. ## The bottleneck moved and the process stayed where it was If developers produce several times more and companies see no difference, the work is going somewhere. It is going into the queue behind them, and that queue can be measured. [LinearB looked at 8.1 million pull requests](https://linearb.io/blog/8-million-prs-engineering-productivity) across 4,800 teams. AI-assisted pull requests wait 4.6 times longer for a reviewer to pick them up, run around 2.6 times larger, and merge within thirty days 32.7% of the time against 84.4% for everything else. Two thirds of the work is produced and then sits in a queue built for a fraction of the volume. > The time the tool saves is real. It is being spent again on everything the tool sits inside. [Faros](https://www.faros.ai/blog/ai-acceleration-whiplash-takeaways), across two years of telemetry from 22,000 developers, shows the same pipeline under the same load: median review time up 441%, and 31% more pull requests merging with no review at all because nobody can keep pace. [Atlassian](https://www.atlassian.com/teams/software-development/state-of-developer-experience-2025) found developers saving ten hours a week to AI and losing ten hours a week to organisational friction, which is the same finding from the other side. > Writing code was the slow step, and every review board, release train, squad boundary and sprint definition was shaped around that fact. Take the slow step away and the shape remains. [Google's DORA research](https://dora.dev/dora-report-2025/), from nearly 5,000 respondents, calls it amplification: AI makes a strong system stronger and a weak one worse, faster, and adoption now correlates with throughput and with instability at the same time. A multiplier applied to an unchanged process returns roughly what the process allowed before. [McKinsey's 2026 survey](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai) of 1,719 executives has the number: 37% report AI contributing to earnings, unchanged on the year. ## Where the process changed, the number moved A mid-sized company set a mandate to double merged pull requests per engineer, and [researchers tracked](https://arxiv.org/abs/2607.01904) 802 developers and 196,000 pull requests to April 2026. Throughput reached 2.09 times baseline with merge and revert rates level, because automated review overtook human review. The verification layer was rebuilt to match the new rate of production rather than left to absorb it. [A field experiment](https://www.hbs.edu/faculty/Pages/item.aspx?num=68814) across 515 startups told half of them how other firms had reorganised production around AI, and changed nothing else. Those firms found 44% more uses for it, were 18% more likely to win paying customers, and made 1.9 times the revenue. The authors call the difficulty the mapping problem: the hard part is not getting the tools, it is working out where in the production process they belong. Even the consultancies concede it. [Bain](https://www.bain.com/insights/from-pilots-to-payoff-generative-ai-in-software-development-technology-report-2025/) puts teams using AI assistants at 10 to 15% and companies that rebuilt the process end to end at 25 to 30%, and notes that writing and testing code was only ever a quarter to a third of the time from idea to launch. ## The other way round If the constraint is the process, a better assistant inside the old shape is the wrong move. The move is to design the shape for what is now doing the work, and place people where judgement is required. We already run parts of this. A conversion programme operates as a loop of agents: instrument the product, read what the numbers say, propose an experiment, build the variant, ship it behind a flag, measure again, keep it or revert. A person sets the question, decides what would count as an answer, and holds the gate before anything reaches a customer. The same arrangement runs a product lifecycle, with people on the spec at the front and the gates at the end, and agents doing the span between. > Agents do the work between the spec and the gate. People decide what is worth building and whether it is good enough. That is a different shape of team, not a faster version of the old one. Fewer people, closer to the decision, because handoffs cost more than they used to and coordination no longer buys the thing speed used to need. Verification becomes the main event rather than the tail, because the constraint is now how fast work can be checked rather than how fast it can be written. Team shape is the intervention; the licence was never the intervention. We are early. The ambitious version of this is not a forecast, it is next quarter's work. We would rather say that with our own numbers. We do not have them yet. ## What we are not sure about The biggest unknown is how much of the review work that is human today stays human. A year ago the received view was that code review is the bottleneck. Since then Anthropic has [run multi-agent review on most of its own pull requests](https://www.infoq.com/news/2026/04/claude-code-review/) and reports substantive review comments rising from 16% of pull requests to 54%, a figure that says as much about how little human review was happening before as it does about the agents. Vercel's engineering position goes further: [relying on review at all](https://vercel.com/blog/agent-responsibly), human or synthetic, is a losing battle at this volume, so the safety has to live in the system, in canary deployments, continuous validation and guardrails that execute rather than advise. Each step in capability so far has removed something that had looked like a hard limit on the gain. There is no reason to assume the next one will not do the same to whatever we currently think a person has to do. > Today's bottleneck is not tomorrow's. Every leap so far has removed something that looked like a hard limit. How far a team compresses before it breaks is unknown too. There is a floor somewhere, set by the accountability a person still carries, and nobody has measured it. And the evidence decays faster than it is produced. All of the above describes mid-2026 and should be re-read rather than quoted in a year. ## Related agentic skills - [mxa-plan](https://agentic.madebymany.com/skill/mxa-plan) - [mxa-measure](https://agentic.madebymany.com/skill/mxa-measure) - [mxa-orchestrate](https://agentic.madebymany.com/skill/mxa-orchestrate) - [mxa-verify-pr](https://agentic.madebymany.com/skill/mxa-verify-pr) - [mxa-verify-promote](https://agentic.madebymany.com/skill/mxa-verify-promote)