Three months ago, my team lead sent a Slack message at 9pm Who reviewed the auth service PR this afternoon?
I had. Sort of.
I had skimmed it. The AI had generated it. The tests passed. Everything looked clean. I approved it in under four minutes and moved on.
That PR went to production. And three days later, at 2am, our auth service started silently failing for a subset of users. No errors thrown. No alerts triggered. Just users quietly unable to log in.
It took us eleven hours to trace it back to that PR.
I had approved code I didn't understand, generated by a tool I didn't fully trust, because I was moving fast and everything looked right.
That night changed how I think about AI in development.
The Number That Should Scare Everyone
Here's a stat that sounds like a win until you actually sit with it:
95% of developers use AI coding tools in production.
I thought that was impressive. Then I read the rest of the data.
Only 29% of developers trust the output.
Let that land for a second. 95% adoption. 29% trust. We have collectively decided to ship code we don't believe in — not because we're confident, but because we're afraid of falling behind if we don't.
This isn't a small gap. This is the developer community in full cognitive dissonance, and almost nobody is calling it by its name.
How We Got Here
In 2023 and 2024, the vibe was excitement. AI tools were new, fast, and honestly kind of magical. Over 70% of developers had a positive view of them.
Then something shifted.
By 2025, that positive sentiment dropped to 60%. In 2026, 46% of developers actively distrust AI tool accuracy — up from 31% just one year ago. Trust isn't stagnating. It's moving in the wrong direction, fast.
And yet adoption keeps climbing. Daily usage went from 18% in 2024 to 73% of engineering teams in 2026. The tools are everywhere. The confidence in them is cratering.
The reason? We've been using them long enough to see them fail — not with loud errors, but with quiet, plausible-sounding mistakes that slip past review exactly because they look right.
The Most Dangerous Failure Mode in Software
This is what finally clicked for me after the auth incident:
AI doesn't fail like a broken function. It fails like a confident junior dev who doesn't know what they don't know.
A broken function throws an error. You see it immediately. You fix it.
AI generates code that compiles, passes tests, and looks syntactically correct — while being subtly, architecturally wrong in ways that only surface under specific conditions, at specific scale, at 2am when you least expect it.
The Stack Overflow CEO put it plainly: "AI is a powerful tool, but it has significant risks of misinformation or can lack complexity or relevance."
That's not an edge case. 96% of developers admit they don't fully trust AI-generated code. Not 20%. Not half. 96%. And yet only 48% say they always review it before committing.
That gap — between knowing you shouldn't trust something and reviewing it anyway — is where the next generation of production incidents is being quietly written.
The Productivity Paradox Nobody Wants to Admit
The pitch for AI tools is speed. And for specific tasks, it delivers. Tests, documentation, boilerplate — real time savings are there. Developers report saving around 3.6 hours per week on average.
But here's the number vendors aren't putting in their pitch decks:
A randomized controlled trial found developers using AI tools were 19% slower overall — while believing they were 20% faster.
A 39 percentage point gap between perception and reality.
The speed gain in generation gets eaten by the time cost of verification. Developers now spend up to 24% of their work week reviewing, fixing, and validating AI output. The bottleneck didn't disappear. It moved.
And at the organizational level? Independent research puts real productivity gains at around 10% — not the 55% GitHub and Microsoft cite. Enterprises that increase AI adoption by 25% see a 1.5% drop in delivery throughput and a 7.2% drop in stability.
More code doesn't mean more value. Sometimes it means more surface area for things to quietly go wrong.
The Three Things I Changed After the Auth Incident
I didn't stop using AI tools. That would be both impractical and, honestly, a different kind of mistake. But I changed how I work with them.
1. I stopped treating "tests pass" as "code reviewed."
These are not the same thing. Tests verify behavior. They don't verify intent or architecture. My auth PR passed every test. It was still wrong. I now read AI-generated code as if a stranger wrote it — because in a meaningful way, one did.
2. I added one question to every AI-assisted review:
"Can I explain why this code is structured this way — without looking at it again?"
If I can't, I don't approve it. Not because the code is necessarily wrong, but because if I can't explain it, I can't debug it. And somewhere, someday, I will need to debug it.
3. I started tracking my hit rate.
What percentage of AI output do I actually use versus throw away? My number was 28% when I first measured it. It's now around 55% because I've gotten better at prompting for what I actually need — not what sounds plausible.
The Honest Truth About Where We Are
Here's what I believe is actually happening in the industry right now:
Developers are using AI because not using it feels like professional suicide. Productivity pressure, management expectations, the FOMO of watching colleagues ship faster these forces are real. They're pushing adoption regardless of confidence.
But the confidence isn't building. It's eroding. Because we've been using these tools long enough to accumulate real-world failure stories. The auth incident isn't unique to me. 69% of developers have discovered AI-introduced vulnerabilities in their production systems. One in five reported incidents that caused material business impact.
We're at a strange inflection point. The tools are genuinely useful for specific things. The trust collapse is real and data-backed. And the path forward isn't to pick a side it's to be honest about both.
What I Think Changes Next
The industry is quietly figuring out that "AI writes code" and "humans verify it" is not a stable long-term workflow. Verification is becoming a full-time skill. Reviewing AI-generated code is increasingly harder and more time-consuming than reviewing human-written code, because the failure modes are different and less predictable.
The developers who figure this out early — who build genuine verification instincts rather than pattern-matching off plausible-looking output — will be the ones teams call when things break at 2am.
The ones who just learn to prompt better will keep shipping features faster. Until they don't.
One Question to Close With
Here's what I keep coming back to:
If you had to justify the last five AI-generated PRs you approved — explain the architecture decisions, defend the edge cases, describe what breaks under load how many of them could you actually walk through?
I asked my team that question in our last retrospective.
The silence was honest.
Heads up: I used AI to help structure and write this.The incident, the reflection, and the decisions are all mine — AI just helped me communicate them clearly. I believe in being transparent about my process.
If this article made you think twice before approving your next AI-generated PR — share it with someone who should read it. The conversation needs to happen at the team level, not just in individual heads.
Top comments (9)
I've said it before, in several comments, and it goes against the grain, but I'll say it again:
Maybe we should, in some cases, write the code ourselves!
Let AI write the less critical code, the boring/repetitive code, etc ...
The more critical code (security, core business logic) - write it yourself, maybe assisted by AI to set up an initial code skeleton, or to fill in the blanks, but steering the whole process yourself and writing a large part yourself.
Not only for reasons of trust and accuracy, for parts of the code that really matter, but also to keep the 'craft' alive (and because it can still be fun to write those interesting parts).
The net speed loss doing this might be zero, or there might even be a speed gain, as the author hints at.
Fully agree. This is exactly where we’re heading AI as an amplifier, not a replacement.
The craft part is underrated. Writing critical logic yourself also builds better intuition to review AI generated code elsewhere.
Well put.
Thank you, yes an amplifier, that's a good way to put it - it can even be a force multiplier when used right ...
But I also noticed a point that you mentioned a few times:
That developers will sometimes feel pressured or 'forced' to use AI to generate code because of pressure from peers/managers or because they do not want to feel like they're "falling behind" - I think it's important to sometimes push back a bit, and use your own judgement!
Exactly The 'falling behind' fear is real, but ironically, shipping broken or untrusted AI code will set you back further Push back is hard but necessary especially when managers just see AI = faster.
Judgement > speed, always.
that part where he approved the auth PR in 4 minutes because tests passed. thats exactly how this starts. not laziness, just speed plus partial trust in something you didnt really read
Very honest and important post.
95% adoption but only 29% trust is actually insane. We’re shipping code we don’t fully understand because it “looks right” and tests pass.
The silent failures are the dangerous ones. This cognitive dissonance is going to bite a lot of teams hard.
Thanks for writing this.
Well said. Looks right is the new 'works on my machine but way more dangerous.
That auth story is uncomfortably familiar.
What’s been bothering me lately isn’t just that AI can be wrong — it’s that it can be convincingly wrong. The kind of wrong that passes tests, reads clean, and slips through review because nothing feels obviously off.
I think that’s where the trust gap is really coming from. It’s not that developers don’t understand the risks — it’s that the cost of properly verifying everything is starting to outweigh the speed gains, so we cut corners without really meaning to.
The question you added — “can I explain why this is structured this way?” — hits hard. I’ve started noticing how often I rely on “this looks right” instead of actually understanding it, especially under time pressure.
Feels like we’re still using AI as if it’s just a faster version of ourselves, when in reality it introduces a completely different failure mode that our current review habits weren’t designed for.
This is such a sharp observation thank you.
Convincingly wrong that's the phrase I've been looking for. Wrong code used to look wrong. AI-generated wrong code looks clean. That's not just wrong it's dangerously wrong.
You're right about the cost of verification. Speed gains are immediate. Trust erosion is invisible. So we cut corners. Not because we're lazy because the system incentivizes speed.
And your point about failure modes is critical. Our review habits were designed for human mistakes. AI introduces a completely different failure mode that our current habits weren't designed for.
Using AI as if it's just a faster version of ourselves that's the hidden assumption we need to question.
Thank you for this. 🙌