For twenty years we laughed at anyone who measured productivity by lines of code. It was the favorite joke at any meetup. Well. In 2026 the metric is back, with a new badge and a nicer name. “AI adoption”.
What the data says
Fiona Chen and James Stratton, PhD candidates at Harvard, published a working paper with data from 725,938 workers at 718 companies, taken from an engineering analytics platform. According to the coverage by ComplexDiscovery, after companies adopted coding agents:
- lines of code went up about 30 percent
- commits went up 20 percent
- pull requests went up 23 percent
- resolved issues changed by an amount statistically indistinguishable from zero
- the time from submitting a pull request to merging it went up 49 percent, from about 7 days to more than 10
In plain words, the code arrived, the software did not. Production went up, delivery stayed flat, and the queue grew. The authors point to code review as the new bottleneck. My reading is simple. The gain only shows up if the company also invests in the capacity to review.
Tokenmaxxing, the new lines of code
Meanwhile, at the big companies, the usual thing happened when a metric becomes a target. According to CNBC, in late May Amazon shut down an internal leaderboard after discovering employees were tokenmaxxing, burning tokens just to climb the ranks. Back in June, The Decoder reported that Meta’s CTO Andrew Bosworth wrote that token usage alone is not a measure of impact of any kind.
And yesterday Amazon published a memo from its engineering leadership. It says metrics like token usage, adoption of AI tools, and code changes and reviews are “deeply flawed”, because they are disconnected from what matters. It also has one sentence I wish I had written. “If your work does not benefit from current AI tooling, that is a finding, not a failing.”
It took a trillion dollars for us to rediscover that a line of code is not a KPI .
The honest part
Every source has some bias. The paper has not gone through peer review yet, and the data comes from a company that sells engineering metrics. The Amazon memo does not throw those metrics away either. It asks people to use them “with care and judgement”. What I bring here is my own perception, from talking with engineer friends about the companies where they work, at meetups, over coffee, in late night messages. Everybody is opening more pull requests, and everybody is waiting longer for review. The story is always the same, only the company logo changes.
The business side, because there is always one
Factories have understood this for decades. Inventory sitting still is waste. A pull request waiting for review is inventory. It cost money to produce, it gives no value to anyone yet, and it gets older every day in the queue. If a company produces 23 percent more pull requests and delivers the same thing, it did not become more productive. It grew the inventory, and it paid the token bill for that.
And the cost does not disappear. It moves. It leaves the person who writes and goes to the person who reviews. I talked about this in What Do We Expect From Code Review and in Comprehension Debt. When you measure volume, the reviewer pays the bill.
Boring, and on purpose
The way out is boring, as always. Measure what reaches the customer. Lead time to production, problems solved, incidents, and how long a pull request waits in the queue. Treat review capacity as an investment, not as friction. Smaller pull requests, better context, someone with protected time to review. And when AI does not help with a task, write it down as data, with no guilt at all.
More code was never the goal. Working software in the hands of the customer always was.
Pax et bonum.