The other day, I received a review request from a colleague. There were a staggering 100 files in the diff—my jaw dropped.
It is impossible for a human to implement such a large-scale change manually. They definitely used an AI agent. The task involved migrating CSV exports within the project to an Excel format. If these 100 files had been replaced mechanically—for instance, simply changing /path/hogehoge.csv to /path/hogehoge.xlsx across the board—I wouldn’t have had any complaints, and a 100-file diff would have been fine.
But no. The changes included logic modifications, file deletions, creations, and migrations of test locations. I get that significant changes were involved, but bundling it all into a single Pull Request? And then just… expecting someone to eyeball it for four hours? My typical PR review is under ten minutes. This behemoth even included DB schema modifications, which had zilch to do with replacing CSVs with Excel files. Model changes and new controller/action additions, too. Rails folks will know the pain.
I pointed out the clearly unnatural code, leaving nearly 30 comments. Two weeks later, another request. I was flummoxed. Sure, the issues I flagged were fixed, but what else was there? Approving it meant it was going live. But a diff this massive? It’s a business team’s dream for minor fixes down the line, and a nightmare to untangle if we ever needed to revert. Conflicts galore.
So, should I approve it?
It brought to mind advice from a veteran engineer during my internship: “The responsibility for the implementation lies with the reviewer.”
Maybe he was just trying to ease my junior jitters about submitting PRs. But it hammered home that a review is a task that demands ownership. Real ownership.
I nudged my boss about it via Slack. His response?
“I’ve only verified the code’s validity!
There are a lot of changes, so I haven’t tested the actual functionality yet!
Please list the updated APIs and test them on the develop branch!
If you let me know, I’ll help with testing on the develop branch too.
↑
Just pass this along to the PM as is.
On the contrary, you’ve checked the PR thoroughly. If it were me, I’d just approve without a second thought.”
Anyway, let’s not dwell on my colleague’s… shall we say, optimism (though it’s unlikely he’ll ever read this in English). The point isn’t just about one bad PR. It’s about a trend: taking code reviews lightly because AI is doing the heavy lifting. We marvel at the sheer volume of code an AI can spit out, but the humans reviewing it? They’re still just humans.
And I’ve seen enough hot takes on tech blogs to make me sick. “I let AI handle not just the implementation but the review too!” No. Just… no. A review is far more than just looking at code. It’s a political dance, a strategic maneuver.
Does it actually meet the business requirements? Are there hidden redundancies or gaping holes? Will this bomb with customers? Does it align with our team’s soul? Is the database going to scream under the load?
You don’t glean that from syntax alone. Reviews are built on the bedrock of daily conversations, shared understanding. (Sure, maybe you could train an AI on every Slack message, but what’s the point of that level of digital archaeology?)
“But what about solopreneurs?” you might ask. “Wouldn’t AI reviews be perfect for me?” Maybe. But its current capabilities are, frankly, abysmal.
More importantly, I have zero desire to have an AI rubber-stamp code generated by another AI. If that’s your jam, knock yourself out. But my stubbornness—call it old-fashioned—insists that the final decision to ship something rests with a human.
And let’s ditch the blind faith in AI-generated code. Case in point: Bun recently migrated from Zig to Rust using what they called “VibeCoding,” merged directly into main without any reviews. That’s a level of trust in AI I just can’t fathom, even for my own tiny projects. Honestly, I trust it about as far as I can throw a server rack.
Just yesterday, I refactored the social login for my project, SuperRails. Previously, one user, one login method. Now, multiple logins per user. I handed the reins to GPT-5.5 for the implementation, creating a PR. My own review uncovered:
uidandproviderfields remained in the database schema.- The
devise-omniauthablegem, which I use, doesn’t support multiple logins. - A missing
destroymethod for linked accounts.
None of these were AI hallucinations. They were actual, functional bugs. Stuff an AI missed.
Why Does the Human Review Matter So Much?
This isn’t about luddism. It’s about recognizing that software development is fundamentally a human endeavor. Code reviews are a critical gatekeeping mechanism, not just for catching bugs, but for fostering shared knowledge, ensuring alignment with business goals, and maintaining the long-term health of a project. When we offload that entirely to AI, we risk creating brittle systems and losing the crucial human element that makes software truly resilient and valuable.
This is where the entire notion of AI-assisted code generation starts to fray at the edges for me. It’s an incredible tool, no doubt. But the idea that it can replicate the nuanced judgment call of a seasoned developer—the political acumen, the user empathy, the architectural foresight—is, frankly, a pipe dream. The PR I described at the start? It would have been approved by an AI, no doubt. And then what?
Who’s Actually Making Money Here?
Let’s not kid ourselves. The companies pushing AI coding tools are making a killing on the promise of efficiency. They sell dreams of faster development cycles, reduced costs, and happier developers. But the reality is often a much messier, more expensive process when you factor in the inevitable debugging, refactoring, and the sheer risk of deploying untested, AI-generated code. The real money, the sustainable revenue, still comes from building reliable software. And right now, that still requires human oversight.
The sentiment from the veteran engineer still echoes: the buck stops with the human reviewer. Trying to shortcut that process with AI is a gamble, and it’s one I’m not willing to take. Not yet, anyway.
🧬 Related Insights
- Read more: AI Agent Tests Break: Microsoft’s New ‘Trust Layer’ Unveiled
- Read more: Open Source AI Frameworks Compared: PyTorch vs TensorFlow vs JAX
Frequently Asked Questions
What are the risks of AI-generated code reviews? AI-generated code reviews risk missing subtle logic errors, security vulnerabilities, and deviations from team standards that a human would catch through contextual understanding and experience. They can also lead to a false sense of security, encouraging over-reliance on automation.
Can AI replace human code reviewers entirely? No, not for complex or critical systems. While AI can assist by identifying syntax errors or obvious code smells, it lacks the nuanced understanding of business requirements, architectural context, and political considerations that human reviewers bring. The final sign-off should remain human.
How should developers approach AI-generated code in PRs? Treat AI-generated code with healthy skepticism. Review it thoroughly, as you would any code written by a junior developer, paying close attention to logic, potential side effects, and adherence to project standards. Don’t blindly trust it, and be prepared to make significant edits or reject the PR if necessary.
