Where does the time go? #
AI makes first drafts of software really cheap - that bit’s pretty well established, even if the headline speedup numbers are all over the place depending on who you ask and what they measured. So the obvious question is, if devs really do save a load of implementation time, where does it actually go?
The standard answer, and the one baked into most of the productivity numbers you see, is that it goes into finishing sooner. You had ten tasks before AI, you’ve still got the same ten tasks after AI, each one takes less effort to implement, so the whole lot is done earlier and everyone goes home at lunchtime. Lovely.
To be fair to the researchers, experiments pretty much have to work this way. If you change the tool and the task at the same time you can’t tell which one made the difference, so you hold the work still, give half the people the new tool, and time them. That’s just good science. The problem is that real organisations don’t hold the work still, and nobody I’ve ever worked with has finished Tuesday’s ticket by lunchtime and then gone for a nice long walk... they pick up the next thing. Or three next things.
I’ve talked about this before in Tokens are a cost, not a KPI - when development gets cheaper the spec never stays frozen, the increased productivity gets swallowed up by increased ambition, and the 2024 app spec turns into something ten times longer with custom reporting and integrations that were never in scope before. At the time that was mostly vibes, so this post is me going and looking at whether there’s any actual evidence for it.
“More” of what, though? #
Before getting into the studies, it’s worth being a bit careful with the word “more”, because turns out to be just as difficult to define as “faster” was. More could mean more lines of code, more commits, more PRs, bigger PRs, more features, more things on the go at once, more testing and documentation and architecture work, more prototypes, harder work, or work that was never worth doing before and suddenly is. Those are all very different things, some of them are good and some of them are definitely not, and the evidence for each one is really patchy. So I’m going to try and be honest about which kind of “more” each study is actually showing.
Cursor: it takes people a few weeks to get ambitious #
The most interesting one I found is from Cursor and Suproteem Sarkar at Chicago Booth, who looked at 500 companies using Cursor between July 2025 and March 2026, a period where the models got noticeably better. Average weekly AI messages per user went up 44%, which on its own isn’t that surprising - better tool, people use it more, plus the AI hype really blew up in that time period so everyone wanted a go.
The bit I really like though is how the usage changed. When a better model came out, people initially just did more of the same kind of work they were already doing, but after about four to six weeks things shifted, and high-complexity requests grew far faster (about +68%) than low-complexity ones (about +22%). Architecture work went up 52%, documentation 62%, code review 51% and learning 50%. So it looks less like “same work, done quicker” and more like people spent a month or so working out what the thing could actually do, and then started pointing it at harder problems.
That lag is honestly more interesting to me than any of the percentages. Most productivity experiments run for days or a couple of weeks, and reporting within software teams tends to be sprint on sprint, which might mean they’re mostly measuring people doing yesterday’s work with a better tool, and completely missing the bit where they figure out what the tool makes newly possible and change the work itself.
Now obviously this is a vendor telling a story about how great their vendor thing is, so a big pinch of salt is needed here. “Complexity” is inferred from what people typed into the AI, not from any independent measure of the work they finished, the companies are already Cursor customers so they’re hardly a random sample, and better models arriving over time is tangled up with everything else that changed over those nine months. It’s strongly suggestive, not proof, but it lines up really neatly with everything else.
LinearB: the PRs are getting bigger #
LinearB’s 2026 benchmarks come from a genuinely enormous pile of data - over 8.1 million PRs, 4,813 teams, and about 164,000 contributors across 42 countries. At the 75th percentile, AI-assisted PRs were 408 lines compared to 157 for unassisted ones, so roughly two and a half times the size.
Which at the very least tells you AI-assisted work isn’t just the same-sized work turning up sooner - the thing landing in the review queue is a materially different shape.
What it doesn’t tell you is that AI makes PRs bigger, because there’s an obvious selection effect where people might well reach for AI specifically when they’ve got a big change to make. And obviously, lines of code are a terrible proxy for how hard something is (we all know this, we ditched LOC as a productivity metric for a reason). A 500-line generated migration can be completely mechanical and boring, and a 20-line concurrency change can be the thing that keeps you up at night. Physical size and conceptual scope are just not the same thing, and I haven’t found anyone who’s properly measured the second one yet, which feels like a pretty big gap.
Atlassian: what people say they’re doing with the time #
Atlassian’s State of DevEx 2025 surveyed over 3,500 developers and engineering leaders, and 99% said AI saves them some time, with 68% saying it saves them more than ten hours a week. When they followed up and actually asked people what they did with that time, the answers were things like taking on more ambitious work, running more projects at once, juggling more contexts in parallel, and putting the reclaimed time into code quality, new features and documentation.
This is useful because it’s the only thing I’ve found that directly asks the question I am actually asking - you saved some time, so what did you do with it? But it’s also the weakest evidence in this post by a mile. It’s self-reported, it’s from a vendor, and “I saved ten hours a week” is a feeling rather than a measurement. And after METR’s study, where experienced devs were measurably 19% slower and still swore blind they’d been 20% faster, I’m not taking anyone’s word for how much time they saved - including my own.
Demirer: definitely more something #
There’s also a big working paper from Demirer, Musolff and Yang covering more than 500,000 GitHub developers, and the bit that matters here is the top of the funnel - roughly +240% commits and +80% projects associated with devs adopting autonomous coding agents. Whatever happens further down the line, AI adoption comes with a massive increase in production activity, which is about as solid as the “more” part of this story gets.
What it can’t tell you is whether all those extra projects are bigger, better, more ambitious, abandoned after a weekend, or actually useful to anyone. More activity is not the same thing as more value, and that’s a whole other question.
The WIP bit I really want to be true #
The story I would really like to be true goes something like… AI makes starting things cheap, so devs start more things, so there’s more work in progress at any one time, so queues get longer and everything downstream gets clogged up. It’s a lovely neat story, it matches what I see anecdotally, and it would make for a very satisfying argument. And there are signs of it - Atlassian’s interviews describe people running more parallel work, Demirer has way more projects, and LinearB has bigger chunks of work landing in review.
But I haven’t found a decent large-scale study that actually tracks active WIP per developer before and after AI adoption and shows it going up, or shows review queues growing because of AI. So the honest version is that there are signs WIP may be increasing, not that AI increases WIP, and we have to try really hard not to try and claim it as a fact just because it’s convenient (which it very much is, because it’s kind of central to working out where the bottlenecks end up).
Stuff that was never worth doing #
If implementation gets cheaper, the bar for “worth building” drops. The internal tool nobody could ever justify a sprint for suddenly only costs an afternoon, and so does the niche feature one customer keeps asking for, the prototype you’d never have bothered with, or the second and third competing implementation so you can pick the best one rather than going with the first thing that worked. That’s just basic economics - make something cheaper and people find new uses for it that didn’t make sense before, which is exactly what I was saying about tokens too. I can’t find any actual data on this, and I’d love to see someone actually try to measure it - project start rates, abandoned prototypes, how much internal tooling exists, how many options teams explore before picking one - but as far as I can tell nobody has yet.
Studies might be measuring the wrong phase #
Putting the Cursor lag together with everything else, I think there are probably a few phases to how people adapt to this stuff. First you do your old tasks with the new tool, then you spend a while learning what it can and can’t do, then you start changing which tasks you take on and how big they are, and eventually the organisation around you starts changing its processes, roles and controls to match.
Randomised experiments are really good at measuring that first phase, and pretty much blind to the rest. The longer-term observational stuff can see the later phases, but can’t tell you as cleanly what caused what. Which is annoying, because it means neither kind of study gives you the whole picture on its own, and anyone quoting just one of them is probably telling you half a story.
So, same roadmap, just faster? #
I don’t think so. “AI saves implementation time” really doesn’t mean the same roadmap finishes proportionally earlier, and there’s reasonable, if imperfect, evidence that teams spend at least some of that capacity on more activity, bigger changes, and harder work once they’ve had a few weeks to adapt. What happens to WIP is still mostly unmeasured, and the whole idea of a fixed backlog turns out to be an experimental convenience rather than anything organisations actually do.
Which leads to the slightly uncomfortable next question. If AI means we’re producing vastly more first drafts than we used to, how many of them actually make it all the way to released software, and what happens to the rest?