AI gives every organisation two choices. Add agents to the process you already have and measure how much faster it runs. Or rethink how the work is done.
Most choose the first, because faster and cheaper is a business case anyone can sign off: the saving goes in a spreadsheet and the payback arrives inside the year. Rethinking the work has no spreadsheet. So the money goes on doing what we already did, just a bit quicker.
The danger with transformative
technology is using it to perfect the past.
What adding agents to the old process gets you
Report after report puts AI's effect on developer productivity somewhere between 5% and 15%. The figures are low and consistent for a simple reason: almost every one measures a process left exactly as it was, with agents added: the same teams, the same steps, a new tool. A few of the reports say that redesigning the work would do more. None of them measure it.
They also measure one narrow thing: how fast a developer gets through a task. That figure then gets read as what to expect across the whole of making a product, from research and design to deciding what to build, checking it and shipping it.
Developers have changed how they work much faster than the businesses around them. Over half now write less than a fifth of their code by hand, and 90% use an agent at least weekly. Yet in McKinsey's 2026 survey of 1,719 executives, the share who see AI in their earnings is 37%, no higher than the year before, on considerably more spending. The tools changed, the process didn't, and the business can't see the difference.
The slow step moved, but the process didn't
If developers produce several times more and companies see no difference, that extra effort is waiting for someone to review, test and approve it, in steps still staffed and paced for the old volume.
That waiting shows up in pull requests, the proposed changes an engineer asks a colleague to review before they go into the product. LinearB looked at 8.1 million of them across 4,800 teams. Changes written with AI wait 4.6 times longer for a reviewer to pick them up and run around 2.6 times larger. Only 32.7% are merged within thirty days, 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.
Faros sees the same load across 22,000 developers: median review time up 441%, with 31% more changes going in unreviewed because nobody can keep pace. Atlassian found developers saving ten hours a week with AI and losing ten to organisational friction.
Google's DORA research, from nearly 5,000 respondents, calls this amplification. AI makes a strong system stronger and a weak one worse, faster. Adoption now correlates with throughput and with instability at the same time.
Writing code was the slow step, and organisations grew a shape around it: review boards, release trains, squad boundaries, sprints. As teams grew, most of the industry split them by discipline and added people whose job was carrying work from one to the next, a relay run sprint by sprint. Take the slow step away and the shape stays, like a phantom limb. A body keeps its map of a limb after the limb has gone, and feels pain where nothing is. The handovers, the review queues and the fixed release schedules all still ache for a slowness that isn't there. Even before agents, the person who created Extreme Programming and signed the Agile Manifesto described what agile had become:
[Agile is] a devastated wasteland. The life has been sucked out of it. It's a few religious rituals carried out by people who don't understand the purpose that those rituals were intended to serve in the first place.
The usual treatment is aimed at the phantom: more reviewers, tighter sprints, a faster version of the step that has already disappeared. The fix is to redraw the map.
Teams that redrew the map
The clearest case so far is a company that researchers followed for two years through a mandate to double the changes each engineer got merged. Across 802 developers and 196,000 changes, throughput reached 2.09 times baseline with merge and revert rates level, because automated review overtook human review. The checking was rebuilt to match the new rate of production rather than left to absorb it.
A field experiment 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 it the mapping problem: the hard part isn't getting the tools, it's working out where in the work they belong.
Bain puts teams using AI assistants at 10 to 15% and companies that rebuilt the process end to end at 25 to 30%. It notes that writing and testing code was only ever a quarter to a third of the time from idea to launch. A partial rebuild already doubles the number.
What redesigning the work looks like
The first step is doing the same things better. The second is doing different things. Both start from the same place: if the process is the limit, a better assistant inside the old shape won't help. We design the work around the agents, and put people where judgement is needed.
That goes well beyond the build. Take improving a product's user journeys for the outcomes that matter, such as sign-ups or purchases. Agents can run almost all of it as a loop: add the tracking, read what it shows, propose an experiment, build it, release it to a small share of users, measure again, then keep the change or roll it back. A person sets the question, decides what would count as an answer, and signs off before anything reaches a customer. The same arrangement runs a whole product lifecycle: people set the brief at the start and sign off at the end, and agents do the work in between.
Agents do the work between the brief and the sign-off. People decide what is worth building and whether it is good enough.
The team changes shape: fewer people, closer to the decision. When an agent does in an hour what used to take a week, every handover between people is slower than the work on either side of it. Checking becomes the main event, because the limit is now how fast work can be checked, not how fast it can be written.
The people change too. With agents doing the middle of production, a generalist can do far more than before, and the specialists a team still needs are fewer, more senior and deeper. Frontend engineering shows it clearly. A product that once needed a team of frontend engineers now needs one senior one to set the standards the agents build to, with designers building much of the interface themselves.
This is how we work now. Measuring it as a percentage of a process we've stopped using is pointless. We look at outcomes instead: how fast an idea reaches real users, how often we learn something from them, and whether the product moves the client's numbers.
One team, inside the client's
Everything so far is the same work, done better. What's new is the team itself: smaller, more senior, and sitting inside the client's.
With agents doing a share of the making, a small senior team can carry a whole product. Research, design and engineering work on it at the same time instead of taking turns, which people have started calling a collapsed team. The researcher hears what users say about yesterday's build, the designer changes the screen in code, and the engineer spends the day on the parts that need one.
Small multidisciplinary teams of experts, with no handovers, have always been how we work. Across the industry they were hard to build on, because they relied on people who were rare and hard to hire. With less of anyone's day spent on production, people now have the time to broaden beyond their specialism, so the shape no longer depends on finding them.
A team that small can work inside the client's own, which changes what the client is left with. Our people and theirs make one team on one product, which the industry has started calling forward deployed. Their people learn the new way of working by doing it alongside ours. When we leave, it stays with them, along with the know-how to keep it going. No change management programme is needed: the change happens by osmosis.
More loops, not fewer days
Building is now fast enough to happen all the time, in the background, so we ship constantly rather than on a date. The rest of the work isn't any faster. An interview still takes an hour. Framing the problem, the research and the decision on every release still take thinking. What we get from the saving is more goes at the problem, more time for what matters, and more confidence in the answer.
- Design
- Build
- Verify
- Operate
What we're 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 and reports substantive review comments rising from 16% of changes to 54%. 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, human or automated, is a losing battle at this volume. The safety has to live in the system, in releases tried on a few users first, continuous checks, and guardrails that act rather than advise. Each step in capability so far has removed something that looked like a hard limit on the gain. There's no reason to assume the next one won't do the same to whatever we currently think a person has to do.
How far a team compresses before it breaks is unknown too. There is a floor somewhere, set by the accountability a person still carries. Nobody has measured it yet, and we intend to find out where it is.
The research can't keep up with the tools. In the time it takes to run a study, the thing being studied has changed: autocomplete turned into chat, and chat turned into an agent that plans a change, runs the tests and comes back when everything passes. That leaves most of the numbers people quote describing tools nobody uses any more. The claim that developers work 55% faster comes from a 2022 trial of Copilot's autocomplete. A 26% gain published this year comes from trials that started in 2022 too. The widely quoted 19% slowdown did measure agents, but early-2025 ones, and within eight months its own authors said developers were probably faster by then. Nobody has run a controlled trial on what we're using today.
All of this describes mid-2026, and it will be interesting to revisit in six months. Nolan Lawson put where we are well:
An asteroid just hit the earth, and we're still surveying the wreckage. It's hard to predict what will happen after the dust settles… but ignoring the crater altogether seems like the worst kind of denial.