AI hasn't (yet) transformed coding productivity
A new paper analyzes AI's impact on programming, which is one of the ripest fields for disruption. Based on open-source software contributions, the authors estimate that 30% of code was written by AI as of the end of 2024, which is in line with what's been previously reported by some large tech companies. More interestingly, they estimate that coders' productivity increased by only 2.4% compared to a pre-AI baseline. If that's true, it's an important nuance that's often missed by the "AI is doing x% of the work" headlines.
It might not be true! They define productivity as commits per user, which might understate the impact here—open-source development often isn't a full-time job, so maybe people are producing that output more quickly and working fewer hours. But it passes the smell test to me.
In the canonical software management book The Mythical Man-Month, Frederick Brooks gives this breakdown for how programmers actually spend their time. (Things have changed since he published that in 1975, but not in ways that really affect this analysis, so I'll relegate them to a footnote.1)
1/3 planning what to do
1/6 writing functional code
1/4 component testing - does your code work as you want in isolation
1/4 system testing - does your code work as you want in the context of your larger system
Component testing today includes writing tests in your code that will tell you if things go wrong, so let's count half of that as "writing code" too. That makes the total time spent coding 1/6 + 1/8 = about 30%. The AI tools available at the time of this study were almost purely focused on writing code, so they couldn't help with things that take 2/3 of a programmer's time.
Still, if 30% of time is spent writing code, and AI wrote 30% of that code instantaneously and perfectly, you'd get a 30%*30% = 9% increase in productivity. But it's definitely somewhat less than that:
Code "written by AI" generally includes autocompletes (where you start writing something and it fills in the rest); that's far from a 100% speedup, since it only saves you the time actually typing out the commands, not the time thinking of what to start writing in the first place.
Even code fully written by AI (through a chat interface or an autonomous agent) requires time to give it context, review the output, and iterate when it gets something wrong—which is especially common when you're working in an existing codebase, as most development involves, rather than starting from scratch.
And "percent of functions written" (the paper's definition) isn't the same as "percent of work done"; in my experience AI is more likely to write new helper functions than to reuse or modify existing ones, which would make it appear to be producing more than it actually is. This is likely a small effect at most.
The paper's 2.4% improvement, versus the theoretical maximum of 9%, implies that even the AI-written code takes humans about 75% of the time they would have normally spent. That's perhaps a little bit lower than I'd expect, but not far out of the ballpark, especially for a time when AI coding assistants are brand-new and might take a learning curve to use.
But there's a big caveat: data from December 2024 is already practically obsolete, because AI coding models in particular have taken massive leaps forward in the first few months of 2025. The new reasoning models are now helpful in the "planning stage", helping translate rough ideas into instructions that a coding model can use. The core coding models are getting better, and agent systems are able to deliver larger chunks of their work without human intervention. I still wouldn't bet that any of these have radically transformed productivity yet, but they're pushing the envelope in more dimensions, and as tools keep improving and people become better at using them, the impact will accelerate.
So although I think productivity growth in the low single digits was correct at the end of 2024, and is still probably roughly correct today, I don't think it'll stay that way for too long.
Planning takes up less time now—running code has become millions of times cheaper and faster over the decades, so it's better to try ideas early and iterate—but that's been replaced by more review of others' code. And the nature of system testing has changed; some tools have made it easier but the scope has expanded, so it's probably a similar share in total. All of those changes are moving time between facets that aren't "writing code," so they don't really affect the analysis above.