On April 22, Sundar Pichai wrote on Google's blog that three-quarters of the company's new code is now generated by AI and approved by engineers. In October 2024 the share was about a quarter. Last fall it was about half. Microsoft's Satya Nadella, in April 2025, put his company's figure at 20 to 30 percent of the code in its repositories.
I believe the number, though it seems odd that two tech CEOs are citing it. It's basically just lines of code, a measure the software industry spent forty years learning not to trust, with a new name in the author field.
They should know better, but here we are.
We Have Measured This Way Before
In February 1982, some of the managers on Apple's Lisa team decided to track each engineer's progress by lines of code. Every Friday, each engineer turned in a form with the number of lines written that week. Bill Atkinson had just rewritten QuickDraw's region engine around a simpler algorithm. Region operations got almost six times faster, and the code got about 2,000 lines shorter.
When he reached the box on the form, he wrote -2000. A couple of weeks later, management stopped asking him to fill it out.
The story survives because anyone who has built anything recognizes it. His best week came out negative.
Commit counts and contribution graphs came next and broke the same way. A one-character fix and a month of design each show up as one commit, and the graph can't tell them apart. Once the count becomes the target, people produce the count.
Why It Was Always Hard
Cal Newport's explanation is that knowledge work never had a clean measure of output, so visible activity filled the gap. In Slow Productivity he calls this pseudo-productivity: "the use of visible activity as the primary means of approximating actual productive effort." Emails sent, meetings attended, lines written, commits pushed, slack messages responses.
In June, Newport carried the argument into AI.
He pointed to a survey of 6,000 digital workers who said AI saved them 11 hours a week on average, while only 13 percent reported any improvement in company performance. Nobody measured those 11 hours. They're what the workers believe. The interesting part is the distance between what people feel and what the company shows. Newport's read: "AI isn't so much creating new problems as it is magnifying the types of problems that have long existed."
Why Agents Make It Worse
On October 8, Andreessen Horowitz published "You Need a New CFO." In it, a growth-stage CFO asks the finance team to build agents, and within two weeks they have 50. "They weren't all useful," the authors write, but everyone got to watch an agent produce real work.
I'm not going to critique that. Watching a tool do real work is how a team starts to believe in it. And there's a fair case for counting: leaders need an early signal, and the P&L is slow and noisy. Fifty agents in two weeks says the team is trying the thing. It says nothing yet about whether the business is better off. That gap is wider with agents than it ever was with people.
A person producing visible activity still had to spend their own hours on it. The day had a ceiling, so the productivity theater did, too. An agent produces visible activity at much lower marginal cost. The count can climb without limit while results stay flat.
In land navigation, a pace count tells you how far you've walked. It says nothing about whether you walked in the right direction or towards the right point. The course grades you on the points you find.
If your azimuth is correct, the pace count is a useful tool in helping you reach your goal. If not, it’s just a measure of how far you’ve walked in the wrong direction.
Issue 0014 made the same argument about dashboards: agentic tools pushed the cost of building an additional view lower and left the cost of creating trust in it completely unchanged. Agents extend the pattern. Building has gotten cheaper. Knowing how an agent actually did is no easier than knowing what a person did, and in most cases, no more relevant.
Three Kinds of Agent Work
The count also hides that agents do three different kinds of work.
Some do work a person used to do. That saves time, but the saving only reaches the P&L if the freed hours go somewhere: to other work, to a hire that doesn't happen, to faster delivery.
Some do new work nobody did before, and it's worth doing. The margin check no one had time to run. The follow-up that used to fall through. New capabilities that didn’t exist, or were prohibitively expensive.
And some do new work nobody did before because nobody needed it. Reports no one reads. Summaries of summaries. Pseudo-productivity, now at machine speed.
An agent count adds all three together and reports the total as progress. Pulling them apart means deciding what the business is trying to accomplish before deciding what to count. For a business, the P&L is where the argument gets settled. Every other number is a guess about what will actually impact it.
Four Questions
- For each agent you run: is it replacing work a person did, doing new work worth doing, or doing work nobody needed?
- Where it replaced human work, where did the freed hours go, and does the P&L show it?
- Where it does new work, which line of the P&L should it move, and by when?
- If you turned it off for a week, who would notice?
Three-quarters of Google's new code is a fact about the code. The P&L is the only place to learn whether it was ever a fact about the business.