A senior engineer I know approved a 400-line PR last week in under two minutes. Tests green, CI happy, description looked reasonable. He told me later he didn't read most of it, an agent wrote it, another agent reviewed it, and he clicked merge because "it's not like I'd have caught anything a model wouldn't."
That's not a junior developer cutting corners. That's someone with a decade of experience deciding review isn't worth his time anymore.
A Fastly survey out this month found the same thing I've been seeing anecdotally: vibe coding, letting an agent write and ship code with minimal human intervention, is growing fastest among senior developers, not juniors. That flips the story most people tell themselves. The assumption was always "junior devs will get lazy, seniors will keep them honest." Turns out seniors are the ones with enough trust in the tooling, and enough other things to do, to stop looking closely.
The Tests Passing Isn't the Bar You Think It Is
Here's the thing nobody says out loud: a green CI run was never proof that code is correct. It's proof the code does what the tests expect. If an agent wrote both the implementation and the tests, in the same session, off the same misunderstanding of the requirement, you get 100% passing tests for the wrong behavior. I've seen this exact failure mode three times this year, once with an auth check that verified a token's signature but not its expiry, because the agent's test suite never generated an expired token to check against.
Nobody caught it in review. Why would they? The diff looked clean, the tests were green, and the PR description said "adds expiry validation."
What Actually Breaks
The failures I'm seeing aren't dramatic. They're small, boring, and exactly the kind of thing a careful human catches and a distracted one doesn't:
- Silent behavior changes. An agent asked to "add caching" changes a function's error handling along the way, because caching and error paths touched the same function and it optimized for a shorter diff.
- Dependency sprawl. An agent solving a narrow problem pulls in a new package rather than using something already in the codebase, because it didn't search the codebase, it pattern-matched to what it's seen elsewhere.
- Confidently wrong edge cases. Ask an agent to handle pagination and it will handle the happy path beautifully and completely miss the empty-result case, because that's the case that doesn't show up in a quick manual test.
- Copy-pasted anti-patterns. Security mistakes like reading
X-Forwarded-Fordirectly or treating CORS as an access control layer, that show up constantly in training data because they show up constantly in real code, get reproduced with total confidence.
None of these fail CI. All of them fail in production, later, for someone else to debug.
If your pipeline auto-merges on green CI with no required human approval, you've quietly turned "the tests pass" into your entire correctness bar. That was a bad idea before agents wrote most of your diffs. It's a worse one now that the volume of diffs went up 5x.
Review Theatre Isn't New, It Just Got Faster
None of this is really about AI. Rubber-stamp review existed long before any of us had an agent to blame it on. What changed is throughput. When a human wrote every line, the sheer effort of writing code acted as a natural rate limiter on how much unreviewed garbage could land in a day. Agents removed that limiter. Now the bottleneck is entirely human attention, and human attention hasn't gotten any cheaper.
So the real question isn't "should we let AI write code." That ship sailed. The question is what review is actually for when the volume triples and the failure modes shift from "typo" to "confidently wrong logic that reads as correct."
What Reviewing an Agent's Diff Should Look Like
A few things I've started doing differently, for what it's worth:
- Read the tests before the implementation. If the tests are also agent-generated, they'll test what the agent thinks it built, not what you actually need. Check the test cases against the requirement first, independently.
- Ask "what's not here" before "what's here." Missing error handling, missing edge cases, and missing validation don't show up in a diff. You have to go looking for the absence.
- Treat large diffs as a smell, not a convenience. A single-session agent output that touches twelve files is exactly the shape of change that's easiest to wave through and hardest to actually review. Break it up before merging, not after something breaks.
- Don't let the PR description do your thinking for you. Agents write persuasive PR descriptions. Persuasive isn't the same as accurate.
None of that is exotic. It's the same discipline good review always required. The difference is that skipping it used to cost you one bad line at a time. Now it costs you a whole feature's worth of quietly wrong assumptions, shipped in the time it takes to read a Slack message.
