Gergely Orosz spent a day inside Anthropic recently and came back with two numbers that sit oddly next to each other.
Jarred Sumner, who created the Bun JavaScript runtime, rewrote it from Zig to Rust in eleven days. Half a million lines, about $165,000 of tokens. Before AI, that job was a year of a small team’s life, which is a polite way of saying it was never going to happen at all. In the same period, the Claude Platform team shipped Claude Managed Agents in roughly six months. Katelyn Lesse, who runs engineering for that platform, reckons the same project would have been closer to two years pre-AI.
Both are real gains. One is around thirtyfold and the other around fourfold, in the same company, with the same models, among engineers of much the same calibre. So what separates them?
Not the tooling. Sumner was the creator of the thing he was rewriting, and its de facto domain expert. He was also working alone, and that turns out to be the detail that matters. Orosz says so plainly: there were no other engineers, which shortened the planning. Managed Agents had to be aligned with other teams at Anthropic, with an internal sandboxing team, and with three cloud providers. Its planning process, Lesse says, looked much like a typical pre-AI one.
The most spectacular productivity story in the piece happened on the only project where nobody had to agree with anybody.
The comparison isn’t clean. A port has a specification to match and a new platform has to invent one, which is slower regardless of headcount. But Lesse’s account of the planning delay is specifically about the number of teams to be brought along, so trust that over the headline multiple.
I’ve been watching a smaller, less glamorous version of the same thing for about a year. Individuals on my teams are demonstrably shipping more. Quarterly planning looks identical. Delivery dates haven’t compressed. The blockers in stand-up are the blockers we had in 2024. All of it is real, and none of it is adding up, and I’ve stopped believing it will on its own.
The gains are real, and mostly individual
Any argument that starts by rubbishing the productivity claims deserves to lose. Faros AI pulled telemetry from more than ten thousand developers across 1,255 teams and found that developers using AI complete 21% more tasks and merge 98% more pull requests. That is not a rounding error, and it matches what I see.
It matches what I do, too. AI cleans up small bugs beautifully. It also does the low-return work you were never going to reach: the third-priority irritations that sat in the backlog for two years because something always mattered more.
Which is where the first uncomfortable thing shows up. That backlog was doing work. When implementing something cost a fortnight, “we’ll never get to it” was a decision, and an unglamorous prioritisation mechanism that mostly functioned. Cheap implementation removes the filter without replacing it. Some of what now gets built delights customers. Plenty of it should have stayed dead. My opinion is that we are seeing a mix, and we don’t have a clear view on which is which so far.
Sumner describes the same mechanism from the other side, and reports no extra free time at all: “There’s so much stuff in Bun that we would not have shipped… I used to have a list of everything I’d like to do in Bun, and it’s pretty much all there!”
For Bun, draining that list is unambiguously good. Bun is a runtime with one owner, a clear technical remit and no go-to-market function. Drain the same list inside a product organisation and forty conversations come out instead of delight, because the only variable that changed is how many people have to agree.
Separate the measured from the felt before going further. In 2025, METR ran a randomised controlled trial on sixteen experienced open-source developers across 246 tasks, in repositories they already knew well. Beforehand, they expected AI to make them 24% faster. Afterwards, they estimated it had made them 20% faster. It had made them 19% slower. METR now treats that result as historical and thinks developers are more sped up in 2026 than their early-2025 figures suggest, which is a caveat worth taking seriously rather than a number to wave around. Perceived productivity is not evidence of productivity, and perception is most of what reaches a leadership team.
Coordination is the part that didn’t get faster
Individual productivity improvements help most when one individual is the bottleneck. That is the whole mechanism, and it is why the gains stop at the edge of the person. Software delivery, past a certain size, is mostly a coordination problem. Decisions, reviews, alignment, handoffs, the slow business of getting several people to want the same thing. Code generation parallelises well. Judgement doesn’t, and that’s the whole problem.
None of which is a new law. Brooks was writing about this forty years before anyone had a coding agent, and Theory of Constraints people have been drawing the same diagram for almost as long. What has changed is the rate at which work now piles up in front of the same gate. A queue that used to grow at the speed of human typing now grows at the speed of a model, and almost every gate in your organisation was sized for the old rate.
My own version runs like this. Leadership wants pace. Leadership also wants a say in everything that lands in the product. Both instincts are reasonable, and together they set a speed limit that no model has any effect on. So I point a team, or my own agents, at several things customers have been asking for, drawn from trends rather than individual requests, and the building is now the easy part. Then product isn’t ready. Or go-to-market isn’t. Or nobody agrees on the shape of the solution, or on the urgency, or on whether we want it at all. Getting round every stakeholder with an opinion on a non-major initiative takes me about a week, purely because of calendars and everyone’s existing work. A week of meetings does not reliably produce agreement. Sometimes it just produces a week.
The second-order effect is the one leaders miss. AI raises the supply of implementation and does nothing whatsoever to the throughput of the approval body. The constraint doesn’t merely stay put. It gets tighter, because there is more work waiting on the same set of approvals.
You can watch that happen in the data. The same Faros study that found 98% more pull requests merged also found pull request review time up 91%. AI-authored pull requests wait 4.6 times longer in review than human-authored ones. Inside the Bun rewrite, the implementation was about 15% of the effort; the other 85% went on getting it to compile, fixing tests and verifying that it worked. Thariq Shihipar, who works across Claude Code engineering, says few tokens go on implementation at all. Most are spent on discovery of unknowns, prototyping, mocking, verification and testing.
Nobody removed the bottleneck. It moved downstream, into the part of the process where humans still have to think.
Why the popular fixes don’t touch it
The industry’s answer to this is to put AI into the coordination layer. AI in all the docs. AI summarising your meetings. AI reading your Slack and telling you what you missed.
These tools collect information, and they are good at it. They do not create alignment. They don’t resolve conflict, or rebuild trust after a bad quarter, or get two engineers with different views on an architecture to converge. Expecting people to read a document and align is nonsense anyway, given how humans actually behave: we align through argument, status, relationships and emotion, and a well-organised summary of a disagreement is still a disagreement.
There’s a nastier problem underneath. If AI is present in every conversation, people stop being honest. The friction, the unsaid thing, the corridor conversation on the way back from the meeting: that’s the real signal, and it’s the first thing to disappear when everything is being transcribed. Technology solves for context well enough. Manufacturing candour is an entirely different problem. Removing privacy destroys candour, and candour is what surfaces problems while they’re still small.
Anthropic’s answer to this is quietly instructive. They kept product requirements documents. For complex work involving lots of people, the PRD survived AI entirely. It lives in Google Docs specifically because the document’s job is to be argued over until agreement is reached. They didn’t build a tool to summarise the disagreement — they kept the surface where it happens. Lesse puts it flatly: “Coordination and alignment remain very important skills for engineers. Even if it gets easier to coordinate groups of people with AI tools, it’s not going away!”
Reading less code is fine, if the guardrails hold
The obvious worry about all this is silos. Every developer now has their own conversation history, their own generated code, their own scaffolding, none of it shared. The mental model of the codebase becomes personal rather than collective, and teams end up producing more while understanding each other less.
I thought that was the argument until I read Orosz’s piece, which has a section headed “Silos no longer a worry”. Anthropic’s platform teams are still six to eight people, unchanged from before AI, but they now run three to eight parallel projects at once. Pre-AI, a team working on more than one project produced complaints about people feeling cut off from their peers. That complaint has stopped.
So silos were a symptom, and a survivable one. What actually broke is that shared understanding used to be the safety mechanism. Code review, tribal knowledge, ask whoever wrote it: the reason it was safe to change something was that somebody nearby understood it. AI breaks that by sheer volume, and the instinct is to try to restore it. That instinct is wrong. It doesn’t scale, and it isn’t coming back.
I’m fine with reading less code. I’m fine with more silos. The condition is that anyone can act safely, and that’s a question about guardrails.
Sumner is running this experiment at full tilt: “How do you merge 100+ PRs a day, and make sure the code works? At this pace, you need to trust the code without the ability to read it all yourself.” Bun’s answer is mechanical. Automated code review. Eleven separate runs of a security scanner on that Rust rewrite. Fuzz testing. Testing run out-of-process, in a different session from the one that wrote the code. A pull request with no test is auto-rejected, and an agent must produce a test that fails without the patch and passes with it before it’s allowed to open the pull request at all.
Anthropic gives two different answers at two altitudes. At system level, Lesse says almost the opposite of Sumner: everyone on the team needs a deep understanding of the system, and “the system they work on cannot become so big that someone doesn’t understand it.” Understand the layer below the one you work on, she adds: if you’re building on queues, understand the queue implementation.
Guardrails replace reading. They don’t replace understanding. You keep understanding affordable by capping how big the system is allowed to get, which is why the team is still six to eight people and why a single project takes at most two engineers.
I’ve now watched the failure mode this predicts, more than once. Tests fail in an area of the code that has nothing obvious to do with the change. Because we’ve optimised the suite (only running the relevant subset on branches, which is a perfectly sensible thing to do), the failure doesn’t surface until the change is on main, where it breaks something else. Every time we’ve traced it back, the root cause has been the same: something at the primitive level wasn’t well enough understood by the person, or the agent, making the change.
The guardrail existed. It had been tuned on the assumption that changes are local, and that assumption quietly stopped being true when everyone started working in parallel with agents. Nobody noticed, because the suite still went green.
That is the problem in miniature. Info-Tech’s AI Adoption and Impact Study, which surveyed 578 applications, engineering and product leaders in June 2026, found 94% reporting productivity gains and only 37.4% describing their AI maturity at the build stage as formal or better. Everyone took the speed on offer. Building the net underneath it turned out to be optional, and most people skipped it.
(I wrote about guardrails as a design choice between a human and an agent in Direct the System, Not the Agent. This is the same idea doing a second job, between humans, at team scale.)
What team-level productivity would actually take
Not a wishlist of AI features. A harder question: which coordination failures are slowing your team down, and are any of them addressable?
After AI adoption the binding constraint is usually decision latency, review bandwidth, unclear ownership or misaligned context. A few of those have partial technical answers. Most need the unfashionable human work: clearer decision rights, better async norms, deliberately built shared context of the kind you create together rather than the kind AI harvests from your Slack.
Anthropic’s answer was structural. Six to eight is about on-call cover, holidays and illness rather than throughput. Lesse rejects the fashionable alternative outright: “One thing I’ve heard from some people is ‘we have two humans and a bunch of agents.’ I reply that this isn’t where we’re at.” Two engineers per project is because each engineer is already running several agents that trip over each other, so adding humans means adding their agents too.
That shifts parallelism from within a project to across projects: a change in how work gets divided, and not one that any amount of AI in the stand-up would have produced.
The answer for the rest of us is more uncomfortable than any single intervention. It means being willing to revamp the whole software development lifecycle, because bolting AI onto each discrete stage optimises the stages and not the whole. Faster requirements into the same review process into the same release train into the same approval committee gets you a faster queue for an unchanged bottleneck. Put a different question to your leadership team: not “where else can we add AI?” but if we were starting this organisation today, knowing what code now costs, how would we build the whole pipeline? Then work out honestly how far you’re prepared to move towards that answer.
Before anyone takes Anthropic as a template, Orosz raises the obvious objection himself: this may only work because they hire the best of the best, and copying it without similar staff “could well result in disappointment.” Anthropic generates around $13.5 million of revenue per employee, against roughly $2.7 million at Meta and $2.2 million at Google. Not the average case, and not pretending to be.
The stronger challenge is that the best counter-example to everything I’ve argued here is a real one. Intercom went all in on Claude Code and doubled merged pull requests per person across their R&D organisation in nine months, then tripled it over sixteen. More than 95% of their pull requests are now created with AI assistance. That is an organisation claiming compounding, not an individual.
Look at what they actually did, though, and it stops being an AI adoption story. Brian Scanlan, the senior principal engineer who led much of it, describes building over a hundred internal skills and thirteen plugins carrying their own guardrails, instrumenting every Claude Code lifecycle event with OpenTelemetry, and running the engineering organisation itself like a product with measured inputs and outputs. They automated pull request approval by pattern matching. And they cut planning cycles from three-to-six months down to six-week goals, not a tool at all, but decision latency, halved and then some.
A hundred skills and thirteen plugins is AI added at each stage, which is exactly what I spent a section dismissing. Intercom didn’t pick between adding AI and redesigning; they did both at once, which makes it hard to credit one lever. I still think the planning-cycle change matters most, because it’s the one figure here with a before and after that isn’t simply “more AI usage”.
Scanlan is clear about the limits of that: “every metric has flaws.” The headline number is merged pull requests per member of the organisation, which is an output measure, and a per-person one at that. Even the best-executed version of this ends up reporting a figure that counts what individuals produced. To their credit, they went after the obvious objection: Scanlan describes the saved time being reinvested into technical debt and defects, with work done alongside Stanford finding that recent changes were improving the codebase rather than degrading it.
Ask the same question of anyone else claiming team-level compounding and the answer is usually structural (queue-shaped work with clear ownership, smaller teams, greenfield code, unusually high trust) rather than better AI.
Both my examples are winners, and organisational redesigns fail more often than they work, so nothing here tells you the odds. What would change my mind: an organisation that bolted AI onto every existing stage, kept the same approval committee and release train and decision rights, and still held team-level gains across several quarters. I haven’t found one, and Intercom didn’t try to be one.
Being early, and what it doesn’t excuse
There’s a reasonable objection to all of this, which is that compounding takes time and we’re early. DORA’s 2026 work on the return on AI investment both concedes the point and answers it. They describe a J-curve of value realisation: productivity dips before it rises, thanks to workflow adaptation, verification overhead and downstream process change. They call that dip “the tuition cost of transformation”, and they warn that leaders read it as failure and pull the funding at exactly the wrong moment.
I can see that dip in my own organisation right now. Our quality signals are moving the wrong way, not dramatically but unmistakably, and in exactly the manner you’d predict when more code arrives at gates built to handle less of it. I’m not writing this from the far side of the curve.
Which raises a fair question about this post. If I’m still in the dip, how do I know the diagnosis is right, rather than early data read pessimistically by someone having a hard quarter? I don’t, not with certainty. What persuades me is that the constraint lands in the same place for Faros’s ten thousand developers, METR’s sixteen and Anthropic’s platform teams, none of whom share my quarter.
Intercom got to the far side. The same programme that doubled their throughput also fed a significant reduction in their defect backlog, and their own measurement now says recent changes improve the codebase rather than degrade it. Nobody avoids the dip. What separates the organisations that come out the other side is what they do while they’re in it.
DORA also name an instability tax (velocity overwhelming gates that were never redesigned to carry it) and, most usefully, find that AI acts as an amplifier. It magnifies the strengths of high-performing organisations and the dysfunctions of struggling ones. It makes your existing patterns stronger without ever fixing them. As DORA’s Nathen Harvey puts it: “The greatest returns on AI investment come not from the tools themselves but from a strategic focus on the underlying organizational system.”
You climb out of the dip by redesigning, or you sit in it and call the whole thing overhyped.
Which brings me to the thing I’d ask of any engineering leader claiming an AI productivity win, including myself. If you can’t point at where the team-level constraint moved, you’re reporting individual wins and calling them organisational ones. Your engineers being faster doesn’t make your organisation faster.