# Writing Code Isn’t Shipping Code > Source: > Published: 2026-10-27 18:39:29+00:00 ## A funnel that shouldn’t exist There’s a stat that I heard a few weeks ago - when developers start using autonomous coding agents, their commits go up by roughly 240%, their projects go up by roughly 80%, and their releases go up by roughly 30%. Same population of developers, same underlying capability, three wildly different numbers depending on where in the pipeline you measure. The obvious question is “where did the rest go”, but I think the more interesting question is why we ever expected those three numbers to be the same in the first place. Nobody sane thinks “I wrote 240% more commits” should translate one-for-one into “I shipped 240% more software”, and yet the whole vibe around AI coding tools kind of assumes exactly that, the implicit model where more code in means more product out, at roughly the same ratio. It doesn’t work like that, and I think the size of the gap between those numbers is the most intriguing part of this series so far. ## The study behind the funnel The numbers come from [Demirer, Musolff and Yang’s NBER working paper](https://www.nber.org/papers/w35275), *Writing Code vs. Shipping Code*, which in its September 2026 revision looks at telemetry from about 500,000 GitHub developers alongside their AI tool usage, using a matched event-study design - basically comparing developers before and after they start using a given generation of tool, matched against similar developers who haven’t adopted yet, to get at something closer to a causal estimate than a simple before/after. They split tools into three generations - plain autocomplete, interactive coding agents (the chat-with-your-codebase kind), and autonomous agents (the kind that go off and do multi-step work with less supervision) - and the cumulative effect on coding activity scales up with how much autonomy the tool has: autocomplete is associated with about +30%, interactive agents with about +180%, and autonomous agents with about +240%. Which is a pretty clean demonstration that the more of the actual typing you hand over, the more code-shaped stuff comes out the other end, no great surprise there. The surprise is what happens when you keep following that same autonomous-agent effect further down the pipeline. It’s still +240% at the commit level, but only about +80% at the project level, and only about +30% at the release level. The effect doesn’t vanish, thirty percent more releases is still a genuinely substantial effect for any team to have found from somewhere, but it attenuates hard, and it attenuates in a very particular shape, getting smaller the further you get from “code was typed” towards “software went out the door”. The paper also estimates something called the elasticity of substitution between AI and human effort, which comes out at around 0.23. I’m not going to pretend I’m an economist, but the best ELI5 version I can do is: AI and human effort are strong complements and weak substitutes, meaning you mostly can’t just swap one for the other, you need both, and having loads more of one doesn’t let you get away with much less of the other. Which is really just the technical way of saying what the funnel already showed you - implementation is one input among several, and cranking that one input up doesn’t crank the whole system up by the same amount, because the other inputs are still needed and they didn’t get 240% cheaper too. ## Don’t call the missing 210 points “waste” The naive way to read +240% commits against +30% releases is to assume “well, 210% of that was pointless then”. That gap isn’t a bin full of discarded work, it’s a bunch of things that are genuinely hard to tell apart from the outside: bigger projects that take longer to get anywhere near releasable, work that’s still mid-flight and hasn’t reached a release yet, experimentation and iteration that improves an existing project without itself being a new release, things sat in a review queue, integration work, and yes, probably a chunk of stuff that just never goes anywhere. Those metrics aren’t a literal conversion funnel where you can subtract one from the other and call the remainder loss. The useful, defensible observation is that the effect attenuates as you move downstream. Anything more specific than that is guessing, we don’t have the data. ## DORA 2024: things get better locally and worse overall This is where it gets properly weird, because [DORA’s 2024 report](https://dora.dev/ai/gen-ai-report/report/) found that a 25% increase in AI adoption was associated with several things getting *better* - documentation quality up about 7.5%, code quality up about 3.4%, code review speed up about 3.1% - and at the same time, delivery throughput down about 1.5% and delivery stability down about 7.2%. Which is a non-intuitive result, really. We can say several local, individual-level things genuinely improved, the code you’re writing is a bit better documented and a bit better reviewed, and yet the system as a whole still got slightly worse at actually delivering software reliably. DORA’s own theory was that this might be down to bigger batch sizes and teams skipping delivery fundamentals they’d normally lean on, essentially cashing in the implementation gains as bigger changes rather than steadier ones. Again, I should point out that this is observational survey data with a statistical model behind it, not a randomised trial, so it’s an association, not proof that AI adoption *caused* the drop in stability - there could be other things about the kind of team that adopts AI early that also make delivery a bit messier, but it’s a genuinely horrible result. ## DORA 2025: and then the story changes However, 2024 is practically a century ago in AI terms. [DORA’s 2025 report](https://dora.dev/research/2025/dora-report/), drawing on nearly 5,000 technology professionals plus over a hundred hours of qualitative interviews, found that the relationship between AI adoption and delivery throughput had flipped to positive, and AI adoption was now also positively related to product performance. The relationship with delivery stability, though, stayed negative. I’m including both years deliberately, rather than just quoting the 2025 numbers because the honest version of this story has a wobble in the middle of it and I think it’s super interesting. DORA’s own framing for 2025 is that AI acts as an “amplifier” - it makes strong organisational systems stronger and, presumably, does the opposite for weak ones - and I think that’s a reasonable way to explain both years’ results. What I can’t tell you with any confidence is *why* the throughput relationship reversed. It could be better tooling, it could be organisations getting better at absorbing the extra implementation capacity, it could be a different sample of companies, it could even be changes in how DORA’s own model works year to year. It’s probably some mixture of all of those. What I can say is that it’s consistent with the idea of a system that initially gets destabilised by a sudden capacity increase and then gradually adapts, but that’s not quite the same as “and then everyone got good at AI”. ## LinearB: the PR stage looks different too [LinearB’s 2026 benchmarking data](https://linearb.io/library/engineering-benchmarks-and-research) gives you a look at what’s actually happening in the review queue specifically, and it’s another place where the funnel shape shows up. Agentic pull requests sit waiting for pickup for an average of 17.6 hours before anyone looks at them, against 3.4 hours for unassisted PRs, and only 32.7% of agentic PRs get merged within 30 days, against 84.4% for unassisted ones. That could imply “developers don’t trust AI code” but lets bear in mind where the data comes from. It’s observational telemetry, so we don’t know whether agentic PRs are slower to get picked up because reviewers are wary of them specifically, or because the work behind them tends to be bigger or more speculative to begin with, or because people reach for an autonomous agent precisely on the kind of task that was always going to sit around longer anyway. A long wait doesn’t prove reviewer fear, and a low 30-day merge rate doesn’t prove the code’s bad, it might just mean these PRs take longer to land full stop, get abandoned more often, or get folded into something else before they’re ever formally merged. What it does show, pretty solidly, is that “a PR got created” and “software got shipped” are nowhere near the same event, and AI-associated work seems to travel through that gap differently to everything else. ## Somewhere in here, the bottleneck moves Put the Demirer funnel, both years of DORA and the LinearB pickup numbers next to each other and you get a fairly intuitive systems picture, even if none of the individual studies proves it on its own. If one stage of a pipeline - in this case, writing the code - suddenly gets a lot more capacity, and the stages after it don’t get more capacity at anything like the same rate, then queues form at whichever stage didn’t speed up, the constraint just moves house and the throughput of the whole system ends up looking a lot more modest than the improvement at the one stage you actually sped up. Implementation was never the only stage in a pipeline - problem selection, then implementation, then verification, then review, then integration, then release, then actually getting adopted and used by someone. AI can touch any of those stages in principle, but it very obviously hasn’t touched them all equally or all at once, and until it does speeding up the first one mostly just tells you where the queue is now. This is not a criticism of AI tooling, it’s just what production systems always do when you dramatically increase capacity at one single stage and leave the rest of the chain more or less as it was. ## Maybe it’s a settling-in problem Taking the DORA reversal together with [Cursor’s finding](https://cursor.com/blog/better-models-ambitious-work) that teams take four to six weeks before they start pointing better models at harder work, there’s a hypothesis that AI initially expands implementation capacity faster than anything else, the existing system can’t absorb that cleanly and shows it through instability, bigger batches and stalled queues, and then over time teams adapt their tooling, their process and sometimes their architecture, and more of that original gain finally makes it through to something that actually ships. It’s a tidy story and it fits the shape of the evidence reasonably well. It is not, however, something any of these studies actually proves happened. ## And even a perfect pipeline has a wall at the end of it And there’s one more attenuation point worth naming, which is that even if you fixed every single bottleneck between typing the code and releasing it, you’d still hit a wall that has nothing to do with engineering at all. No amount of implementation speed forces a customer to want the thing, forces legal to sign off on it, forces a stakeholder to actually respond, or makes anyone adopt what you just shipped. Demirer’s paper notes more software entering the world without a correspondingly large increase in aggregate usage, which is exactly the shape you’d expect if attenuation keeps going past release, out into implementation-then-release-then-use-then-outcome, and that’s a genuinely different problem to the ones sitting inside the SDLC, because it’s got nothing to do with your review process and everything to do with whether anyone out there actually wanted the thing in the first place. This isn’t “AI productivity is fake”, and the +30% releases figure on its own is still a proper, meaningful jump for whoever’s getting it. It’s that coding capacity can’t just be multiplied straight through a whole delivery system and expected to come out the other side in the same ratio it went in, because shipping software was never just a function of how fast you can type it, it depends on a pile of complementary human, technical and organisational capacity that didn’t get 240% cheaper at the same time the typing did. Which is a far less exciting thing to put on a slide than “240% more commits”, but it’s the bit that actually explains what’s going on and - unlike the slide - it’ll still be true next quarter.