Tuesday night, in one of my app repos.
My coding agent finished a feature, pushed the branch, opened the pull request, and typed the merge command.
Same session. Same hands. Ninety seconds between opening the PR and merging it.
I stopped it and sat there for a moment.
Code quality had nothing to do with why I stopped. Nobody had read a line of it.
Author and reviewer were about to be the same machine.
Check your own queue
How many of the PRs waiting on you this morning were written by a model?
And how honestly did your last "LGTM" reflect what you actually read?
Sixteen years of building enterprise integrations, and I still caught myself doing this. Approving my own agent's diffs on momentum, because tests were green, everything looked plausible, and I wanted the feature.
Call that what it is. A signature.
Open source hit the wall before we did
Watch what happened across open source in the last few months.
- curl shut down its bug bounty after years of low-quality AI-generated reports made triage unaffordable
- Ghostty moved to zero tolerance on undisclosed AI pull requests
- tldraw now auto-closes external PRs entirely
- GitHub is publicly weighing a kill switch for PR floods
One maintainer said it plainly this month. Letting AI write the code might be fine. Reviewing on vibes is not.
None of this reads as anti-AI to me. It reads as triage by people whose scarcest resource ran out.
Numbers we already had
None of it should surprise anyone, because the research is two decades old.
SmartBear's study of 2,500 reviews at Cisco found reviewers catch 60 to 90 percent of defects, at roughly a tenth of what the same bug costs once it reaches production.
Buried in the same research sits a finding almost nobody quotes. Detection collapses once a single sitting passes about 400 changed lines. Past that point you are scrolling.
Microsoft's internal studies found 20 to 30 percent fewer production defects in reviewed code.
And CodeRabbit measured AI-generated PRs at roughly 1.7 times the issue rate of human ones.
Put those together. More defects per line, arriving faster than ever, into a review practice that was already saturated at human writing speed.
Here is my opinion, stated plainly.
Code production stopped being the bottleneck. Review capacity is the scarce resource now, and most teams still plan as if typing speed is what limits them.
What I changed after Tuesday
I stopped trusting my own discipline and made the sequence mechanical.
In my repos, a merge command now refuses to run unless a review verdict was recorded on the pull request itself. On the PR, as a comment the next reader will find in two years, rather than in my head or a chat log.
An approval on a large diff refuses to arm the merge unless the verdict says how the review was actually done, in passes, section by section. A single-pass approve on a thousand-line diff is a signature, whoever signs it.
And every merge runs in one shape. Squashed, with the branch deleted behind it, so history stays honest and nothing is left to rot.
One thing surprised me. This gate exists for me as much as for the agent.
My agent was never the problem. My repos had a merge path with no review step in it, and the agent found that path by doing what I asked, quickly.
What a gate cannot do
Honesty requires this section.
A gate cannot make a lazy review a good one. I can still skim a diff and type a verdict that claims more than I checked.
What it can do is make silence impossible. No path remains where code lands on my default branch without a recorded human judgment.
That turns out to be most of the battle. My failure mode was never "I reviewed badly". It was "I did not review and nothing noticed".
If you lead a team, whether people use AI to write code stopped being an interesting question. They do, and they should.
Where, precisely, does a human judgment get recorded before that code reaches your default branch? Answer that one.
If your answer is "the approve button", read the 400-line finding again and then look at the size of the last PR you approved.
Your turn
Who reviews the machine's work on your team, and where does that review actually live?
If this was useful
I work through this in public, the wins and the freezes both, mostly on LinkedIn and YouTube. If the real version of building in the open is useful to you, that is where it lives. Find me on X, GitHub, and the work at next8n.com.
Top comments (0)