I said it in August. Now there's data.
Back in August I wrote that learning to code matters more in the age of AI, not less. The core of the argument was one line: when generation is free, verification is the bottleneck. And you cannot verify what you cannot read.
That was an opinion. Now two Harvard researchers, Fiona Chen and James Stratton, have put real numbers on it.
Their new working paper uses data from Jellyfish, an engineering analytics platform, covering more than 720,000 workers at 655 companies between 2021 and 2026. They compared companies that adopted AI coding tools earlier against ones that adopted later, and followed the work through the pipeline: code written, code reviewed, features shipped. The paper counts a feature as a resolved Jira epic: a big chunk of work made up of smaller tickets, marked done only once all of it is deployed.
Here's what happened in the year after a company rolled out AI agents like Claude Code or Cursor's agent:
- Pull requests opened: up 36%
- Features shipped: up about 18% (and statistically, the researchers can't rule out zero)
- Time from opening a pull request to merging it: up 56%
The first wave of tools, autocomplete-style assistants like GitHub Copilot, looked even more lopsided. Pull requests rose 25%. Shipped features barely moved, under 2%.
So let's go through what the paper found, and where I think it points.
More code was never the job
The art of engineering has never been about who writes the most code, or who builds the biggest or fanciest project. It's about getting the business task done, and those tasks come with wildly different requirements. If you're building for financial trading, you live and die by latency. If you're building a blog for fun, you have a completely different set of problems. More code doesn't help either of them unless it's the right code.
After agent adoption, lines of code went up 44%. But of the extra pull requests those teams opened, only about 63% ever got merged, compared with 86% of pull requests normally. The authors draw the same conclusion I would: metrics like lines of code overstate what AI is delivering.
The bottleneck didn't disappear. It moved.
That 56% jump in time-to-merge came from both ends: code waited longer for a reviewer to pick it up, and spent longer in active review once someone did. Reviewers also left 39% more comments per pull request, even though the pull requests didn't get any bigger.
And here's the interesting part: bug reports didn't go up. The authors read the longer reviews and extra comments as a sign that the code arriving for review had gotten worse. My read is that human reviewers caught the difference before it shipped.
None of this should surprise anyone who has worked on a team. In the paper's own measurements, engineers spent between 31% and 41% of their time coding. The rest was planning, reviewing, testing, and talking to each other. AI made that minority faster, and now the majority has to keep up.
The "10x AI engineer," in a lot of cases, is someone filling a review queue 10x faster.
I'm not sold on the software factory
A lot of teams are building what I'd call software factories: an agent picks up a ticket from Jira, writes a fix, writes the tests, and opens a pull request in GitHub or Bitbucket on its own. Most of the development flows through that pipeline, and humans show up at the end to click approve.
What scares me is a wall of open pull requests that all pass the tests the AI wrote, with no real human step verifying that the change does what we intended. That's the AI grading its own homework.
The paper can't tell which companies ran agents as factories and which used them interactively. But a factory pours more work into the one stage that's already the bottleneck.
The way I think Claude should be used is as an interactive tool, not a set-and-forget one. A person pulls the ticket, maybe through an MCP connection. They spend real time with the agent brainstorming, researching, and investigating the problem. There are tools built for this kind of decision-making, like Google's recently open-sourced Elephant-Goldfish Model, where AI reviewers who see only the design try to break it before any code exists. Then they use it to generate the right fix. The engineer stays in the loop the whole way, because the engineer is the one driving.
The context is the work
Before the AI boom, one of engineers' biggest complaints was context switching. You'd get deep into a problem, get bumped onto something else, and spin up slowly because your head was still in the first one. Coming back meant rebuilding everything the interruption knocked loose. Programmers went into do-not-disturb mode to protect their focus.
But that painful process of building a mental model of a problem is what makes it stick. It's how you understand the intricacies. It's how you know why the solution had to be built the way it was. And it's what lets you review a change with confidence.
Every AI-written pull request is a context switch where nobody hands you the context. The agent built it, then threw it away when its session ended. You see a result, and it passes the tests, but you never went through the mental exercise of deciding what the best option was.
The paper backs this up in a way I didn't expect. Reviewers overwhelmingly review code they know: 83% of reviews went to someone who had already worked in that part of the codebase, compared with 17% if reviewers were assigned at random. The authors conclude that you can't just move a person onto reviewing unfamiliar code at no cost. And in companies with complex codebases spread across many repositories, agents slowed merges by 70%, compared with 25% in simpler setups.
So what do you do when an AI pull request lands? Don't stop at green tests. Pull it into your agent and make it explain the problem back to you. Play the antagonist.
The token bill
For me, the test is simple to state: do the tokens bring in enough new business that the profit covers what they cost?
Answering it is a different story. How much does shipping a feature two weeks earlier move the bottom line? Two years earlier? Sometimes the answer is obvious. Often nobody knows, and the study can't help: it counts tickets and features shipped, not revenue. That's not a knock on the authors; it's the honest limit of the data.
The cost side has its own trap. Personal AI plans, by many accounts, are priced below what heavy users consume, which is a great deal if you're an individual. Enterprises don't get that deal. They pay API rates, where a big refactor or a rewrite can get expensive fast. Engineers will want to use every token they're given. It falls to business leaders to decide where the consumption stops paying for itself.
Among the workers whose billing the researchers could see, the median engineer spent about $178 a month on agents in July 2026, roughly 2.6% of an entry-level engineer's monthly salary. The top 1% went over $9,000 a month. So for most people, AI is still cheap compared with the human using it. The scary bills live in the tail, and I'd bet that's where those refactors and rewrites sit.
The ladder still exists
Senior engineering has changed a lot. Hand-writing architecture docs and specs, and doing most of the coding yourself, is mostly gone. The work itself is still the work, though. Architects still need those documents, and Claude is great at helping with them, if you go back and forth with it, edit heavily, and check what comes out.
The bigger question is the next generation. Junior engineers today will have Claude in their hands from day one. Will they learn to debug and get into the weeds the way seniors had to?
I don't assume they won't. They might be better at it, because Claude can explain things faster and more clearly than Stack Overflow ever did. But we have to teach them to use the tool to experiment, to investigate, to research, and to learn. Here's how I think the ladder works now:
- Junior: you use the tool to fill your own mind.
- Senior: you make better decisions based on what the tool produces.
- Architect: you take that output, distribute it across a series of systems, and validate it.
Same hierarchy as always. Claude just finds its way into every rung.
The paper gives some reason for optimism here. It found no drop in junior hiring after either generation of tools, which cuts against earlier research showing entry-level jobs shrinking. But it also shows why the ladder matters: senior engineers did 76% of the reviews of other seniors' code, and review is where the bottleneck now lives. If juniors let the agent do all the thinking, they never build the context that turns someone into a senior reviewer, and the scarcest resource in the building has no pipeline behind it.
Perfect code, wrong problem
Plenty of companies already use AI in review: 79% of the firms in the study had adopted an AI review tool, yet only 23% of review comments came from AI. Humans are still doing the deciding, and I think that's correct.
So what happens if AI gets as good at reviewing code as it is at writing it? The paper models this. If review stays at human speed, it projects output leveling off around 58% above pre-AI levels, with about 10% fewer engineering jobs by 2031. If AI speeds up review as fast as it speeds up coding, output could rise as much as 341%, with up to 76% fewer engineering jobs.
That second number is the one that'll end up in headlines. But read the fine print. The authors themselves call it an upper bound, because their model only includes coding and reviewing. It leaves out deciding what to build, testing, and coordinating with customers, all of which they say would become bottlenecks of their own.
That's my point exactly. Engineers are the think engine behind the product. A product manager can write up the feature they want, but engineers decide how it gets owned and built: which stack, how many services, monolith or microservices. Those calls depend on business context that is hard to hand an agent in one shot. AI can make the code perfect, but if the business requirements were misunderstood, perfect code still fails.
I've lived the small version of this. In my August piece I wrote about an agent that found a real performance win in our React app and quietly broke our SEO schema in the process. Nobody had told it what actually mattered.
What about the jobs?
This is the toughest question, and I hold my opinion loosely. I don't think we're about to lose a huge chunk of software engineering jobs, because I think the world wants far more software than it's buying today. If engineering gets easier, more people will get into it, since the barrier to entry drops. Some salaries might soften. Big companies might trim headcount in favor of AI-enhanced developers. But getting to a minimum viable product is fast now, so I wouldn't be surprised by a startup boom, with some engineers becoming business owners instead.
The paper can't settle this one. Its companies are established, mid-to-large firms, and the authors note that startups may behave differently. In their model, total engineering jobs only grow if the world wants a lot more software once software gets cheaper to build. So my optimism is a bet on that appetite. I'd take it.
We're supposed to figure it out
On my own team, headcount hasn't changed. Our code development has accelerated. But our experience matches this paper: we still spend a lot of time reviewing and validating. Even the specs Claude writes for us get reviewed over and over, adjusted, and argued about.
AI made writing code cheap. It didn't make understanding cheap, and understanding is what we actually get paid for. This is the point of engineering, right? We're supposed to figure it out.