I let AI write my code for a month. The junior devs caught what it broke — I didn't.

I'll say the unpopular part first: for one month I leaned on an AI coding agent for almost everything, and the bugs it introduced were caught by the two most junior people on the team. Not by me. Not by the tests. By the two people the internet keeps telling us AI is about to replace.

I want to talk about why, because the "AI made me 10x faster" posts are all true and all incomplete. The speed is real. The failure mode is also real, and it's more dangerous than the one everyone warns you about.

The bug you expect vs. the bug you get

Everyone braces for the obvious failure: the AI writes something that doesn't compile, or hallucinates a function that doesn't exist. That bug is fine. It's loud. The compiler screams, the test goes red, you fix it in ten seconds. Loud bugs are cheap.

The bugs that got me were the opposite. They compiled. They passed the tests I had. They looked exactly like code I would have written — because they were trained on code I would have written. They were plausible. And plausible is the single most expensive property a bug can have, because plausibility is what switches your review brain off.

Three examples from that month:

• A caching helper that was correct except it keyed the cache on a mutable object, so under concurrency it occasionally served one user another user's result. Passed every test. There was no concurrency in the tests.
• A retry wrapper that retried on all exceptions, including a validation error that would never succeed — turning a clean 400 into a 30-second hang and three log lines that looked like a network blip.
• A refactor that "simplified" a permission check by collapsing two conditions into one, which read beautifully and quietly widened access by one role.

Every one of those is the kind of thing I'd catch instantly in a stranger's PR. In AI output, I skimmed right past them. Three times.

Why I missed them and they didn't

Here's the honest mechanism, and it's not about skill.

When I write code, I've already argued with myself about the edge cases on the way there. My review of my own code is a re-run of an argument I remember having. When the AI writes it, that argument never happened. There's no memory of the reasoning to re-run — just fluent output that looks like the conclusion of reasoning. So I reviewed the look of it, matched it against "is this how I'd write it," got a yes, and moved on. Fast, confident, wrong.

The juniors did the opposite, for the exact reason they're junior: they don't trust code they don't understand yet. They read the caching helper line by line because they had to, to learn it. And reading line by line is precisely what catches a mutable cache key. Their inexperience forced the slow path. My experience let me take the fast one. The fast one is where plausible bugs live.

That inverts the whole "juniors are obsolete now" narrative. In an AI-heavy workflow, the person who reads every line because they can't yet skim is doing the most valuable job on the team. The senior who trusts their pattern-match is the liability.

What I actually changed

I didn't stop using AI. It genuinely is faster, and for the loud-bug category — boilerplate, glue, one-shot scripts — it's close to free. What I changed was the review contract:

1. AI code gets stricter review than human code, not looser. The instinct is the reverse ("it's probably fine, the model is good now"). Invert it. No argument happened in its head; the argument has to happen in yours.
2. Review it like a stranger wrote it. Because a stranger did. Strip the "this looks like me" reflex — that reflex is the exploit.
3. The tests it passes are the tests you already had. AI is very good at satisfying the existing suite and silent about the case the suite never covered. Ask, every time: what input is not in these tests? That's where the plausible bug is hiding.
4. Let the person reading slowly win the argument. When a junior says "wait, why does this retry on everything?" — that's not them being slow. That's the review working. Protect that.

The part I keep coming back to

We keep framing AI-and-juniors as a replacement question: does the model do the junior's job now? A month of my own screwups says the framing is wrong. The model does the typing. It does not do the doubting. And doubting — reading the line you'd normally skip, distrusting the code that looks right — turns out to be the job that actually protects production.

The junior who slows down to understand isn't behind the curve. In a world where the code writes itself fluently and confidently and sometimes wrongly, they're the curve.

AI didn't make my juniors obsolete this month. It made them essential, and it made me the weak link. I'd rather say that out loud than post another 10x-speed screenshot.

---

Be honest: has AI-written code ever slipped a bug past you that you'd have caught in a human's PR? What was it, and who found it? 👇

I write about building with AI and the honest ways it breaks. Follow me here if that's your lane. 👋