Thank you for opening up the latest article in 'The Intelligent Commit' newsletter, my thoughts, research and analysis on Artificial Intelligence and how AI is reshaping the software development lifecycle. I hope you find it insightful, subscribe, and engage.

A few weeks ago I was on a night out in Leeds with the Axiologik engineering team, when the conversation turned to work, as it always does. "Are principal engineers the only ones who actually care about code quality?", we asked ourselves. As we talked about the impact of AI, one of the team delivered a killer line.

"In ten years," he said, "nobody will care how you did your job, as long as the div's aligned and the code compiles." Everyone laughed, and he might just be right.

That line inspired this article, because behind the light humour is a genuine question about what code review is actually for.

It's Friday, and I've got a meeting. Ship it.

If we are being honest we would admit that code review was always two things at once, either a conversation about quality between people who cared, or a rubber stamp for those who were busy. We measured both as if they were the same, because the approval looked identical either way. Every engineer reading this knows the four letters. LGTM. Looks Good To Me. Sometimes that means "I read this properly, I understand it, I stand behind it." And sometimes it means "I trust you, it's Friday, I've got a meeting, merge it."

I'll admit to typing out LGTM on plenty of changes I didn't fully open, and if you've been in the role as long as me, so have you.

The rubber stamp isn't new. The question is whether AI is turning it into the default.

The research has been telling us this for years, long before the AI wave. Google's study of how it reviews code found that a major hurdle for reviewers is comprehension, i.e. building a mental model of the change before you can judge it. Mäntylä and Lassenius found that roughly 75% of the defects in reviews concerned evolvability, naming, structure, understandability, rather than functionality. The review was never just the 'bug net' many think it is. It was how a team kept its code understandable and maintainable, and how the people who cared taught everyone else to care.

More code is "compounding cognitive debt across the team as engineers struggle to understand code they did not write".

Now feed that process a firehose. DX, measuring across more than 400 companies, found self-reported AI-authored code reached 52% by the second quarter of 2026, up from 27% a quarter earlier, and over the past year the median pull request has grown nearly two-thirds in size, from 44 to 72 lines. And it isn't just bigger changes, a study of Microsoft's early-2026 rollout of coding agents, across tens of thousands of engineers, found adopters merged roughly 24% more pull requests than they otherwise would have. A quarter more pull requests, each nearly two-thirds bigger, means the code arriving for review has roughly doubled, while the number of humans reading it hasn't moved. The 2025 DORA report describes AI as an amplifier. It can increase throughput, but it also magnifies instability if the surrounding delivery system is weak.

Under load, the rubber stamp wins.

Faros AI put numbers on it. Across two years of telemetry from 22,000 developers and more than 4,000 teams, median review time rose to more than 5x its baseline in high-adoption periods, and bugs per developer increased 54%. Significantly, pull requests merged with no review at all were up by almost a third, yet nobody had decided oversight was optional.

"We do not believe this reflects a deliberate decision to bypass oversight. The more likely explanation is that reviewers cannot keep pace with the volume of AI-generated code arriving for their attention."

Faros's read, and mine, is that reviewers simply couldn't keep pace, so the safety step got skipped. And before you assume 'strong foundations' will save you, the same telemetry found mature, high-performing engineering organisations deteriorating at much the same rate as everyone else, which sits awkwardly against DORA's 'amplifier' framing. The Friday-afternoon LGTM is no longer the exception; AI is quietly turning it into the default.

There's a reason it got so much harder, and it isn't just volume. Of course, not all AI code is equal here. A developer can read line autocompletions as they type, which is a different beast from an agent implementing and submitting a whole feature on its own, and it's the agent end of the spectrum where we see challenges emerging.

When you review an agent's code, you may be the first human ever to read it.

Review a colleague's pull request and you're checking reasoning that's sitting in front of you, and where it isn't, you can go and ask them. Review an agent's, and you are frequently, as one developer put it in the "AI Slop and the Software Commons" study, "the first human being to ever lay eyes on this code". The author who could explain the "why" can't be questioned, and whatever reasoning the agent had vanished the moment the diff appeared. That's why context tops every complaint. In Qodo's 2025 survey, 78% of developers reported productivity gains, yet 65% said AI misses relevant context during refactoring, and around 60% say the same of review.

Code review was a conversation between an author who could explain and a reviewer who could ask. Agent-generated code removes one side of that conversation, leaving the reviewer to reconstruct intent from the code alone, and then we wonder why they're drowning. Review used to ask the author whether they had thought this through. Increasingly the only question left is whether the reviewer can afford the time to find out.

Every sprawling, duplicated, nobody-reads-it line is more code a future agent has to retrieve, compare and reason over before it can safely make the next change.

Back to the trigger for this piece and the line down the pub. If the machine writes the code and can read it back well enough to change it later, do we actually care whether a human can follow it? For a lot of throwaway code, maybe we don't. It compiles, it works, and we move on, just as my colleague suggested.

Two things to call out at this point.

Security is the obvious one. Developers largely know AI-generated code is more likely to be vulnerable, and plenty ship it anyway, as I wrote about before. Humans have always shipped the odd vulnerability, but what's new here is that the insecure line may arrive with no author to interrogate. That's a review problem as much as a security one.

Secondly, "the AI can work out the context" argument isn't free. GitClear analysed 211 million changed lines and reported a fourfold rise in duplicated code blocks, while the share of changed lines classified as cloned rose from 8% to 12%; copy-pasting overtook refactored, moved code for the first time in its dataset, and the share of refactoring changes fell from 25% in 2021 to under 10% in 2024. Every sprawling, duplicated, nobody-reads-it line is more code a future agent has to retrieve, compare and reason over before it can safely make the next change. That can mean more tokens, more spend, and more room for the agent to lose the thread. Poor code used to waste engineer hours; now it wastes context windows too. Maintainability didn't stop mattering when humans stopped reading, but it changed who pays the price.

There's always a solution out there, so now for some good news.

Machines can absorb the firehose, so humans can review what matters.

A good AI reviewer assigns itself the instant a pull request opens, summarises the change so a human can catch up in seconds, and flags style issues, deviations from best practice, duplication and likely bugs, on every single PR, tirelessly, and often for free. And before you say it, no, this isn't the same as marking your own homework, although I'd recommend the AI reviewer is a different model from the author, while still cautioning that different isn't the same as independent, as models can still share similar blind spots.

An AI reviewer never types LGTM to get to a meeting or to leave early to go to the pub.

It's the machine's always-on patience doing the mechanical review a tired human was skipping anyway. An AI reviewer never types LGTM to get to a meeting. For the repetitive, mechanical layer, it may be the most consistent reviewer you have. Consistent, mind you, but not infallible.

One further caution however is that Qodo's telemetry identified that once an AI review tool is enabled, 80% of pull requests show no recorded human comment or review at all. That doesn't prove nobody read them, but it's a strong signal. The machine can absorb the mechanical layer, or it can become the new rubber stamp. Which one you get is an engineering leadership decision.

What it still won't tell you is whether the code should exist at all.

Review didn't die. It lost its author, and for those down the pub we argued that it's losing the people who cared. Our job as leaders is to rebuild both.

So here's where I'd put the effort.

  • Automate the prerequisites, rather than the judgement itself. Put an AI reviewer and your scanners on every pull request before a human looks. If a machine can reliably catch it, a person should never spend time on it. That's what we did years ago with linters. Even better, get your coding agent to wait, fix and loop on the mechanical findings automatically; the judgement calls still come to you.
  • Make the agent show its working, and keep its diffs small. Require coding agents to attach the task, its constraints, the acceptance criteria and the verification performed to the PR, so the reviewer has intent they can interrogate. You get similar benefits when your human coders capture the same. And if we decompose work into small increments, we avoid the risk of a PR so big that it can't be reviewed responsibly.
  • Treat LGTM as a smell, and zero-human-review merges as an incident. Dependency bumps and generated files aside, once an AI reviewer sits on every pull request, 'reviewed' becomes ambiguous. Count the merges of meaningful code that no human read, put that rate on a dashboard next to your change-failure rate, and watch it. And if you're in a regulated industry, remember code review is often a segregation-of-duties control too. There, a zero-human-review merge may not just be a smell, it may be an audit finding.
  • Stop asking whether the code is clean. Ask whether it should exist. Linters and automated checks handle much of 'clean'. Human judgement is for whether it fits your architecture, whether the people or systems maintaining it will still understand it in six months, and what it'll cost you to keep.
  • Protect the people who still care. They're maybe your scarcest asset. Don't let a rubber stamp replace a conversation, and don't let your principals be the only ones left who care.

One rule underpinning all of the above is that the agent can't own what it shipped. Every agent-authored change needs a named human owner, someone who can explain why it exists and will carry the consequences of shipping it.

Back to the pub. My colleague might be right that in ten years nobody will ask how you did the job. Yes, the div can be aligned, the code can compile, and yet the whole thing can still be a slow, expensive mistake that no one read and no one owned. What I'm wary of losing isn't the ritual of approval, it's that someone cares, and whether ten years from now engineers will still sit around talking about code quality on a night out.

AI can review code, and it already handles much of the mechanical layer more consistently than tired humans do. Whether anyone still cares to do the rest is on us.

Thank you for reading my latest article. Please share your experiences and engage with the discussion. I am not always right, but I try to be insightful and thought-provoking.

  • Be honest, what proportion of the LGTMs on your team last month were a genuine conclusion versus those that were simply a busy stamp?
  • When your team reviews an agent's pull request, is anyone reconstructing intent, reviewing against the plan, or just skimming a diff and approving?
  • Do you know your zero-human-review merge rate, and would you be comfortable seeing it next to your change-failure rate?

Please reach out if you'd like to continue the discussion.

Sources

  1. Caitlin Sadowski et al., "Modern Code Review: A Case Study at Google", ICSE-SEIP 2018 — https://sback.it/publications/icse2018seip.pdf
  2. Mika V. Mäntylä and Casper Lassenius, "What Types of Defects Are Really Discovered in Code Reviews?", IEEE Transactions on Software Engineering, 2009 — https://aaltodoc.aalto.fi/server/api/core/bitstreams/cab054e8-0c06-47ab-8754-54bb09a0a6d3/content
  3. DX, "AI-authored code has nearly doubled, but so has PR size", Q2 2026 (400+ companies) — https://getdx.com/blog/ai-authored-code-has-nearly-doubled/
  4. Emerson Murphy-Hill, Jenna Butler and Alexandra Savelieva, "Adoption and Impact of Command-Line AI Coding Agents: A Study of Microsoft's Early 2026 Rollout of Claude Code and GitHub Copilot CLI", arXiv, July 2026 — https://arxiv.org/abs/2607.01418
  5. DORA, "2025 State of AI-Assisted Software Development", Google Cloud, 2025 — https://dora.dev/dora-report-2025/
  6. Faros AI, "The AI Engineering Report 2026: The Acceleration Whiplash", March 2026 (22,000 developers, 4,000+ teams) — https://www.faros.ai/blog/ai-acceleration-whiplash-takeaways
  7. "AI Slop and the Software Commons", arXiv preprint, 2026 — https://arxiv.org/abs/2604.16754 (quoted in Addy Osmani, "Agentic Code Review", June 2026 — https://addyosmani.com/blog/agentic-code-review/)
  8. Qodo, "2025 State of AI Code Quality", June 2025 (609 developers) — https://www.qodo.ai/reports/state-of-ai-code-quality/
  9. GitClear, "AI Copilot Code Quality: 2025 Research", February 2025 (211M lines analysed) — https://www.gitclear.com/ai_assistant_code_quality_2025_research
  10. Google, "Gemini Code Assist and GitHub AI code reviews", Google Cloud Blog, 2025 — https://cloud.google.com/blog/products/ai-machine-learning/gemini-code-assist-and-github-ai-code-reviews