Code review used to be the part everyone complained about. Slow, nitpicky, the thing standing between you and shipping.
And for a while, AI coding agents made it feel optional. The agent writes the code, the code compiles, the tests pass, ship it.
But have you ever wondered, what does that actually look like once you zoom out to the whole industry, and not just your own repo? Not great. Somewhere between 40 to 62% of AI-generated code got shipped with security or design flaws by March 2026, and roughly one in five breaches this year traces back to AI-written code, according to industry analysis on the verification gap. Code generation got really fast. Verification did not pick up the same pace. Testing AI coding agents properly is where that gap actually lives, whether your team has staffed for it or not.
Let's get specific.
In late June 2026, security researchers at Adversa AI disclosed something called GuardFall, a shell-interpretation bypass that worked against 10 of 11 popular open-source AI coding and computer-use agents, including Aider, Cline, Goose, and OpenHands. The agents were checking the raw command text for danger before running it, but bash rewrites that text through quoting, substitution, and expansion before it actually executes. So a command that looks harmless to the safety check can still detonate once the shell gets its hands on it. And only one tool in the survey actually held up!
And it's not just an edge case for people running agents locally. A scan of 5,600 vibe-coded apps already in production found 2,000 highly critical vulnerabilities and 400 exposed secrets, some of them exposing medical records and payment information. Georgia Tech's Vibe Security Radar tracked the trend line getting worse, and not better: 6 confirmed AI-generated vulnerabilities in January 2026, 15 in February, 35 in March.
Well, that's exactly the part people get backwards.
Better models didn't remove the need for verification, they just moved the bottleneck. Generating a solution stopped being the hard part a while ago. Deciding whether you can actually trust that solution is the hard part now, and 55.4% of enterprise decision-makers already name agent reliability and hallucination management as their top production challenge. The code compiles, the tests pass, and reviewers still have to reconstruct what the change was even trying to do before they can tell if it's safe.
I'm not writing this from the outside. I recently worked with an early-stage startup that's figuring out their PMF before going full-throttle. I was the first layer of internal testing for the product, which was a self-evolving super agent (keeping it a bit vague, can't reveal more than this lol), and my entire job was catching bugs before the core users on it ever saw them. I also built an internal tool which was an agent chain based on strict rules that pulled the agent's data logs and evaluated them to ensure that the self-learning from feedback and real-life scenarios aren't being hallucinated, and if the agent is trying to manipulate the guidelines itself. Also, I generated reports on latency and probable slowdowns, because "it seems to be working" isn't a testing strategy, numbers are.
Before that, I spent time at Keploy building and improving sample apps specifically to demo API testing. So when I say testing agent output is a real, staffable job and not a checkbox, that's not a hot take pulled from a headline, it's what I got paid to do.
And to be fair to the agents themselves: they are genuinely fast, and genuinely useful. I use Claude Code, Antigravity and Codex daily, and I'm not about to pretend otherwise. The problem was never that the code they write is bad on average. The problem is that "on average" is exactly the wrong bar for security and correctness, because the failures cluster in the 5-10% you didn't specifically check.
(And yes, this post was drafted by an agent skill I built, and I'm going to go through and edit it before it goes anywhere near publish. That's not irony, that's the actual point: the draft can get the facts and the structure right, but deciding which of my receipts actually belong here, and how hard to steelman the agents, is still a job for a human. Mine, in this case.)
Stop reviewing agent output the way you review your own code, and start reviewing it the way you'd review a fast junior developer's very first PR: assume competence, verify everything, especially the parts that touch execution.
Concretely: never let an agent pipe raw, unreviewed strings into a shell without a real evaluator in between, GuardFall exists because teams assumed string-matching was enough. Budget actual human review time as a fixed cost of using these tools, not a nice-to-have. And track your own vulnerability trend line the way Georgia Tech tracked the industry's, because "it hasn't broken yet" is not the same thing as "it's fine."
And testing an agent isn't only about catching bugs before they ship, it's also about watching what the agent quietly costs you over time. That's exactly why I built that internal latency-tracking tool in the first place, numbers on slowdowns catch problems long before a user ever complains. If you don't want to build that yourself, tools are starting to do it for you: I recently found Bifrost from Maxim AI, a gateway that sits between you and your coding agents and gives you latency, cost, and token usage in one dashboard, plus fallback logic for when a model starts misbehaving. Worth a look if you're juggling as many agents and LLMs as most of us are these days.
Do use these agents. Really do, they're not going anywhere and they've earned their place in my own workflow. But treat testing them as the actual job, not the afterthought, because right now, for most teams, it still is one.
If you're building your own testing layer for an AI tool, or you've been burned by one that didn't have one, I'd genuinely like to hear about it, drop it in the comments. I write more about agent tooling and building with AI at swapnoneel.site, including how I built a self-improving writing agent, and you can find me on X (swapnoneel123).