Devs thinking they can replace QA with AI

Jul 30, 2026 · 3 min read

AI lowered the bar to produce something.
It didn't lower the bar to produce something good.

@williamtranqa

I’m seeing more devs treat AI like it replaces QA. That’s when things go sideways.

Code ships fast. Nobody outside the dev actually stress tested it. Bugs get through that would have been caught before release, easily, the kind of thing a second pair of eyes with adversarial intent finds in minutes.

Here’s the part that actually gets me though.

The reputation gets rewritten after the fact

Nobody says publicly, “we skipped QA on this one.” That would require admitting a decision got made. Instead, mentally, it gets filed differently. “QA missed this.” The reputation hit lands on QA, even on releases where QA was never in the room to begin with.

That’s not a small distinction. One version is a process decision someone made, ship without a second check, that they’d have to own. The other version is a performance failure, attached to a team that had nothing to do with the release. Nobody’s doing this maliciously. It’s just easier to blame a function for missing something than to remember it was never asked to look.

It runs the other way too

QA using AI to start writing code, thinking that makes them a dev now. Same mistake, mirrored. Producing code isn’t the same skill as owning what happens when that code meets production traffic, edge cases, and users who don’t behave the way the happy path assumed they would.

AI lowered the bar to produce something. It didn’t lower the bar to produce something good.

That line matters more than it sounds like it should. Anyone can generate code now. Anyone can generate test cases now. What AI hasn’t done is generate the judgment to know whether what got produced is actually ready, or just looks ready because it compiled, ran once, and nothing obvious broke.

What actually doesn’t get replaced

I use AI constantly. It’s genuinely useful, faster drafts, faster first passes, fewer blank pages. But it doesn’t replace someone whose whole job is trying to break the thing before your customer does. That instinct, adversarial by design, is a different discipline than writing the thing in the first place. You don’t get it by osmosis from using a tool that’s optimized to be helpful and agreeable. You get it from years of assuming everything is broken until proven otherwise.

Devs skipping QA and QA skipping the dev grind are the same mistake told twice. Both assume AI closed a gap that was never really about output. It was about who’s actually responsible for catching what the confident-looking output missed.

Comments

Loading comments…

Leave a comment