August 25, 2026

The 10x AI Engineer

AI changed everything. But did everything really change? Anthropic put a number on it, two hundred percent more output per engineer, straight three times, and Boris Cherny posted it on launch day. The demand moved with it. I have been in a room where fifteen PRs a day was the target, and the answer to any pushback was, what's the problem? Anyone can blast that out. They were right, and that is the uncomfortable part: producing code really did get that cheap. Which is why everyone now calls review the bottleneck. But what about understanding? Is that a bottleneck? I was not sure, so I spent a week on the numbers. Here is what I found, and how to actually become a 10x AI engineer.

Start with the year, because the year is the argument. In 2017, researchers followed 78 professional developers and logged 3,148 hours across everything on the machine, not just the editor. Typing code came out at five percent. Understanding it came out at fifty eight. Finding it took another twenty four. This was before Copilot, before agents, before any of it. Writing was already the smallest part of the job, which means making it faster was always going to move less than people expect.

Then Anthropic measured what the speed costs. In January 2026 they took 52 developers, gave some of them an AI sidebar, and quizzed everyone on code they had written minutes earlier. The ones who wrote it by hand scored 67 percent. The ones who used AI scored 50. Anthropic's own write up calls that gap nearly two letter grades. And that was a chat window, not an agent.

Now hold the 200 against what those same companies measured on themselves. Anthropic's own research team came out at 50 percent. Meta, 51 on diffs per developer. Microsoft's agentic rollout, 24. Google, internally, about 6. Four of the largest engineering organisations on earth, each one measuring itself, and every measured number lands between 6 and 51. The number in the room is 200.

What was promised, what was measured
200%51%6%
advertised by Anthropicthe highest any of them measuredthe lowest, Google internally
Four of the largest engineering organisations on earth, each one measuring itself. Every measured number lands between 6 and 51.
Anthropic launch post, March 2026 · Meta 51, Anthropic 50, Microsoft 24, Google 6, each measured internally

The volume, on the other hand, is real and it is enormous. Pull requests are being created at 47.5 million a month, and coding agents account for more than ten million of them from a standing start in 2025. The share of code that AI writes crossed half in a single quarter. None of that is in dispute, and none of it is the interesting part.

The interesting part is what happens to the person looking at it. Eighty six programmers were asked to judge AI written assertions. On the correct ones they were 74 percent accurate. On the wrong ones, 49. A coin flip. Their confidence was the same either way, and when the code came with a vague explanation attached they got less accurate and more confident at the same time.

Here is the pair that carries the whole argument. An economics working paper tracked more than 100,000 GitHub developers with usage telemetry across a year of agent adoption. Lines of code written, 17.3 times more. Files touched, 3.9 times. Commits, 2.8. Pull requests, 2.5. Releases actually shipped, 1.3. Every rung down the pipeline the gain shrinks. Seventeen times the code, one point three times the software. Everything in between is where it went.

NBER · agents, Feb to Dec 2025
17.3x2.5x1.3x
lines of code writtenpull requests openedsoftware actually released
Every rung down the pipeline the gain shrinks. Everything in between is where it went.
NBER Working Paper 35275 · 100,000+ GitHub developers with usage telemetry

And a lot of it goes out unread. Merges with no review at all rose 31 percent. In small repositories the median time from an agent opening a pull request to merging it is one minute, and 72.6 percent are merged inside five. Nobody read that. We are not reviewing this code, we are waving it through, and a green test run is quietly doing the job a person used to do.

Which is Paul Graham's point arriving early. When producing costs almost nothing, the value moves to deciding what to produce. Taste and judgment stop being the soft part of engineering and become most of it.

So: more code, more output, more of everything. Is any of it useful? In August 2026 Boris Cherny, who built Claude Code, posted the numbers from Anthropic's own automated maintenance routines. 388 pull requests opened. 180 merged. That is at the company that makes the tool, after AI review and human review both. He never said what happened to the other 208.

We have always thrown work away. Over-engineering, speculative abstractions, features nobody asked for. That was the old waste, and it was bounded by how fast a person could type. It is not bounded any more. So the question stops being whether we are 10x and starts being 10x of what. Across 11,048 closed agentic pull requests, 33 percent of the rejections leave no recorded reason at all. Nobody is keeping the ledger.

I keep seeing the same shape in people, too. The engineer becomes a tunnel to the agent. Thinking gets optional, then rare. It is tempting to call that brain rot, and I am not going to, because the researchers behind the study everyone cites for it have publicly asked people to stop using that word. Their actual finding is narrower and worse. Of 18 people quizzed on an essay they had written minutes earlier, zero could quote their own work. That was essays, not code, and it is still a preprint. Nothing rotted. It never went in.

Those researchers had a name for it, and it is the right one. Cognitive debt. Work that got done without the understanding that normally comes attached to it. The balance never shows up anywhere. No test goes red. Nothing breaks on the day you take it on. You find out months later, when someone asks why the code does what it does and the honest answer is that you do not know, because it was never yours. Now multiply that by more than half your codebase. That is an organisation that cannot explain most of what it ships.

Which would be survivable if something else could answer for it. Nothing else can. There is a live database of court cases involving AI generated content: 1,935 of them. Zero AI systems have ever been sanctioned. All 149 sanctions landed on a person, 144 of them lawyers. Air Canada tried arguing its own chatbot was a separate entity responsible for its own statements and was thrown out. And the case count went from 16 in 2023 to over a thousand this year with a third of the year still to run. Sixty three times more cases. The accountability moved zero.

AI Hallucination Cases · live, August 2026
014963x
AI systems ever sanctioned, out of 1,935 casessanctions, every one on a personmore cases than three years ago
The database has a column for the AI tool. No AI has ever appeared in the party column.
AI Hallucination Cases database · 144 lawyers, 3 judges, 2 self-represented

The tools say as much themselves. Every provider's terms hand the output back to you: you asked for it, you accepted it, you shipped it, it is yours. There is no clause anywhere that carries it the other way, and there is not going to be one. So the buck stops exactly where it always stopped. With the founder, the CTO, the team lead, the engineer whose name is on the commit. When it goes wrong at two in the morning, nobody is going to accept "the agent wrote it", and nobody should. Understanding is the one part of this you cannot delegate to something that cannot be held responsible for it.

So what do you actually do

None of this is "use AI less". All four of these are about deciding once, in advance, which changes a human still has to hold in their head, and then making that decision run itself.

Build a classifier that runs on every pull request. A small program that fires when a PR opens, looks at what it touches, and decides whether a human needs to read it. Three buckets: ship it, auto merge, you read this one. Route by blast radius, not by difficulty. The signals are already in the diff and none of this needs a model: which paths were touched, whether it crosses a service boundary, whether it reaches auth, money, migrations or infrastructure, and whether it can be undone. Start with paths, that alone gets you most of the way. Write the rules on a calm Tuesday afternoon, because a human classifying at two in the morning always classifies it as fine. This is not a new idea, just an unapplied one. NASA has sorted every system containing software into six classes for decades, and the same shape exists as DO-178C levels and ISO 26262. What does not exist is any engineering organisation publishing one for AI assisted changes.

Review the conversation, not just the diff. The what survives in the code. The why lives in the thread that produced it, and we throw that away every time. A diff that moves retries from 3 to 5 and adds exponential backoff looks fine, approve it. The thread behind it says the connection pool was exhausted and someone said just bump it for now. Nothing in the code says that. Capturing design rationale is a forty year old research field that mostly failed, because somebody always had to stop working and write it down. With an agent that objection is dead. The conversation is a byproduct of the work now, so keeping it is not discipline, it is just not deleting it.

Write every pull request for whoever reads it in six months. That person is you, and you will have forgotten. Not because anything went wrong, but because the reasoning was never yours in the first place. Carry enough for a stranger to reconstruct the decision: what problem it solves, what else was considered, what it touches, and what breaks if you delete it.

Make it uniform across teams. If one team's "you read this one" is another team's auto merge, you do not have a policy, you have preferences. And once an agent moves work between repositories, which is now normal, the weakest standard becomes the organisation's standard. Write it as a numbered procedure, not a principle. Linux 7.2 shipped exactly that in August 2026: a nine step sequence an AI assistant must follow to find and fix a bug. Not guidance. A sequence.

All of this costs time, so it is fair to ask what it buys. Meta measured its own automated review layer across more than 535,000 reviewed changes. Median review wall time down 35 percent. Revert rate a third of what unreviewed changes ran at. Production incident rate a fiftieth. Now hold that against the other large telemetry set: across 22,000 developers on more than 4,000 teams, median time in review rose 441 percent and incidents per pull request more than tripled. Both are real telemetry from real organisations, pointing in opposite directions. The visible difference between them is whether the organisation built a review layer. That is not proof of causation, and one of the two carries an arithmetic error in its own abstract, which is reason enough not to lean on it too hard. But it is the closest thing to evidence that this is worth the effort.

There is a measured price for skipping it, too. Across a year of agentic contributions, the more a project merged without review, the more corrective maintenance and security weaknesses it accumulated. The work does not disappear. It moves, and it lands on whoever is holding the pager.


Watch, read, and build

More posts

June 17, 2020

Traveling Workstation. Nomad Ergonomics. The Ideal Setup.

Read

October 17, 2016

Fun Learning about JavaScript and ES6!

Read

Get the latest updates