We are living in a strange time. AI writes most of our code now, and honestly, I love it. I generate more code in a day than I used to write in a week. But somewhere along the way, something quietly broke : nobody is reading the code anymore.
Think about it. AI generates the code, AI reviews the PR, AI writes the tests and we, the engineers, have reduced ourselves to a merge button. We flex about how many PRs we merged in a day, how many tokens we burned, how fast we shipped. Volume has become the new vanity metric.
In this article, I want to talk about why this is a trap, what it's silently costing us, and what a saner workflow looks like.
Note: This is not an anti-AI rant. I use AI to write code every single day and I'm not going back. This article is about how we use it, not whether we should.
The numbers don't lie
Before you think this is just me being paranoid, the industry data is genuinely alarming :
- AI-generated code has 1.7x more bugs than human-written code — 1.75x more logic errors and 1.57x more security findings.
- 45% of AI-generated code contains security vulnerabilities as per Veracode's analysis.
- 58% of developers trust AI output without testing it, and security review coverage is 20-30% lower for AI-generated code.
Major players are getting hit by this too, not just weekend side projects. We are shipping faster and breaking more, and the curve is getting steeper, not flatter.
But honestly ? Bugs are not even the scariest part for me.
You lose the mental model
This is the issue I've personally faced, and it bothers me way more than any bug count.
When I write code by hand, I earn a mental model of the system for free. I know where things live, why that weird edge case exists, which function talks to which. When something breaks at 2 AM, that mental model is what tells me exactly where to look.
When I generate huge volumes of code and don't review it, that model never forms. Week one, I roughly know what's happening. Week four, I'm a stranger in my own codebase. I've lost the surface of the code — what it's doing, where it's doing it, and why.
With hand-written code, understanding was a byproduct. With generated code, understanding is a task — and we are skipping it.
Now here's the obvious counter-argument : "just spin up an AI instance and ask it what's happening in the codebase". Sure, it'll give you an answer. But an explanation on demand is not the same as understanding. It doesn't give you the confidence that what you're pushing is actually good, and during an incident, you don't have time to rebuild context from scratch through a chat window. You're debugging your own product like an outsider.
What else silently creeps in
Bugs and lost mental models are the headline issues, but a few more things sneak in when nobody is reading the code :
- Security holes AI reviews don't catch — AI reviewers are decent at spotting patterns, but business-logic vulnerabilities (broken auth flows, missing ownership checks, that one endpoint which trusts client input) need someone who understands the product, not just the code.
- Architectural drift — every generation session reinvents its own patterns. Three different ways to call the same API, duplicate helpers, inconsistent error handling. Each PR looks fine in isolation; the codebase as a whole slowly turns into a patchwork.
- Hallucinated or bloated dependencies — AI happily imports packages you never audited (sometimes packages that don't even exist, which attackers now exploit). Your supply chain grows without anyone deciding it should.
- Rubber-stamp reviews — a 3000-line PR gets a "LGTM 🚀" because no human can meaningfully review that volume. The review process still exists on paper, it just stopped doing anything.
- Skill atrophy — if juniors never read or review code deeply, the next generation of senior engineers — the ones who are supposed to catch all this — never gets built.
So what's the workflow ?
Let me be clear : we can't go back to the era of writing everything by hand, and we shouldn't. That ship has sailed and honestly, good riddance. The answer is not less AI, it's a better pipeline :
- Generate with AI — go wild, this is where AI shines.
- Let AI do the first few review passes — linting, obvious bugs, style, test coverage. It's genuinely good at this and it filters out the noise.
- Then a human reviews. Every time. — not to nitpick variable names, but to answer the questions only a human can : Does this match the architecture ? Does this handle our edge cases ? Do I understand what this does well enough to debug it in production ?
That last pass is not about distrusting AI. It's about the engineer earning back the mental model. The review IS the understanding. Skip it, and you're not saving time — you're borrowing it from your future self at a very bad interest rate.
AI should raise the floor of code quality, not replace the ceiling. Use AI to review the code, but never let it be the last one to review the code.
Shameless plug : I'm building something for this
This problem bothered me enough that I started building a tool for it : Argus — an open-source, free to use VS Code extension that makes that final human review pass actually doable.
The idea is simple : instead of staring at a raw diff, Argus walks you through the PR like the author is sitting next to you. For every hunk it answers two questions — why did this change and what could go wrong here — so you build the mental model while you review, not after the incident. It's local-first (your code never leaves your machine, it runs on your own gh and Claude CLIs) and you can submit the review to GitHub without leaving VS Code.
It's early and I'm actively working on it. If the problems in this article resonate with you, give it a spin and tell me what's broken — the code is on GitHub.
Merged PRs per day is a vanity metric. Understanding your own system is the real one. Generate as much code as you want — just make sure a human read it before it shipped.
I hope you find this article interesting. Thanks for reading. Until then, bye 👋