The AI Broke Your Software. Now It Wants to Test It.
The panic about AI wrecking code and the excitement about AI catching bugs are the same story. The tester who can't tell them apart is the one who gets burned.
There's a thread on r/ExperiencedDevs I can't stop thinking about. Someone asked, plainly: is anyone else noticing more bugs across the web and in software in general? Fourteen hundred upvotes. Three hundred and forty-eight comments. And the top reply, sitting there with more than a thousand upvotes of its own, doesn't hedge. Yes, software is more broken now than it has ever been.
Read the comments and the diagnosis lands in the same place over and over. It's the AI-generated PRs nobody is fully vetting. The code gets "yoloed into prod," which is the actual phrase people keep reaching for, and the bugs follow.
Now here's the part that should make you sit up. In the same thirty days this bug-panic thread was climbing, the most influential piece of writing in the testing world came from antirez, the creator of Redis, publishing something called "A new era for software testing." And his argument? Use the AI as the tester.
So which is it.
Is AI the thing breaking our software, or the thing that's finally going to test it properly?
Well. It's both. And that's not a contradiction you get to resolve by picking a side. It's the actual shape of the job now, and I want to talk about what it means for us.
The data isn't on the optimists' side. Not yet.
Let's get the uncomfortable numbers out of the way. They're real, and they're not from a vendor with an axe to grind. Or rather, they are from a vendor, but the methodology holds up.
Veracode ran more than a hundred large language models through eighty-odd coding tasks and then security-tested the output.
- Forty-five percent of the AI-generated samples introduced an OWASP Top 10 vulnerability.
- Java was the worst offender at a 72% failure rate.
- Cross-site scripting failed 86% of the time.
- Log injection, 88%.
These aren't exotic edge cases. They're the security bugs we've been writing training material about for twenty years.
And the detail that should bother you most: scaling didn't help. Bigger, newer models didn't write safer code. Veracode re-ran the whole thing in spring 2026 and the security pass rate was still stuck around 55%. Flat. Basically unchanged across two years of model releases. So this isn't a "wait for the next version" problem. It's structural. The machine is fast and confident and wrong about security roughly half the time, and it's getting faster without getting righter.
Put that next to the volume. When developers can generate three or four times the commits they used to, a constant defect rate isn't constant in absolute terms. It's a flood. The bugs were always going to be there at some rate. What changed is the pressure behind them.
That's the r/ExperiencedDevs thread, explained. People aren't imagining the regression. The math says the regression is real.
antirez isn't wrong either, though
Here's where it gets interesting, because the optimistic case isn't naive. antirez isn't saying "let the AI write the tests and go home." He's saying something sharper.
His point is that there's a whole category of testing we've always known we should do and mostly didn't. Integration testing that's structurally hard. Timing issues, multi-machine setups, the kind of thing where the only real check is a human looking at the output and going "hm, that doesn't look right." Quality work that lived on a checklist nobody had time to run. He gives the example of asking an agent to stand up a production-like Redis environment with replication and persistence, simulate days of real usage, and just watch for anything odd. Including the soft stuff. Features that look surprising, undocumented, sloppy from a user's point of view.
That's not unit-test automation. That's the manual QA pass that always got skipped when the release date got close. And he's right that an agent can now do it, tirelessly, on every release, in a way a stretched human team never could.
So his bet is that automatic QA might raise the quality bar for releases, and partly make up for the lower quality of code that fast AI programming produces. AI cleaning up after AI. There's something almost elegant about it.
The trap is treating one as a replacement for the other
But read the top comment on the Hacker News thread about antirez's piece, because it's the whole game in two sentences. You can skip automated tests even faster now, it says. You can and should work with AI to write tests, but you have to know the difference between a good test and a test that just looks good on paper.
That. That is the line between a tester and a person who has been automated.
Because here's what happens if you don't internalize it. The AI writes the code. The AI writes the tests for the code. The AI runs a QA pass against a spec the AI helped you write. Every one of those steps has the same blind spot baked in, because it's the same kind of system making the same kind of confident-but-wrong calls at each layer. A test suite written by the thing that produced 45% vulnerable code is not an independent check. It's the fox doing a security audit of the henhouse and filing a clean report.
The agent will happily generate a hundred passing tests. The question that doesn't go away, the question that is the job, is this. Passing what? Testing for what? Did anyone decide what "correct" means here, or did we just generate plausible-looking assertions and feel covered?
Coverage was always a lie we told ourselves. Hitting every line of code was never the same as hitting every state the system can get into. AI didn't invent that gap. It just made it incredibly cheap to paper over, to generate the green checkmarks without the thinking that's supposed to sit underneath them.
What's actually appreciating in value
So let me say the thing I actually believe, the thing this whole month of noise points at if you squint.
Generation got cheap. Verification did not.
And the gap between those two is exactly where a tester's value now lives.
Reviewing code you didn't write. Refactoring the mess. Designing the integration test that catches the timing bug. Knowing the difference between a test that proves something and a test that just turns green. Deciding what "correct" even means before a single assertion gets written. Looking at an agent's QA report and knowing which parts to trust and which parts are the henhouse audit. None of that got automated this year. All of it got more valuable, because there's now ten times more unreviewed output that needs exactly those skills pointed at it.
I find this clarifying, actually. For years the testing profession has carried a low-grade identity anxiety. Am I just clicking through screens, am I going to get automated away, is QA a real discipline or a cost center. And then AI shows up and does the thing everyone was afraid of. It makes producing software trivially fast.
And what falls out the other side isn't
"we don't need testers."
It's
"oh, that's what the testers were for the whole time."
The judgment. The skepticism. The refusal to confuse motion with correctness.
The bug-panic thread and the antirez piece aren't two different stories about AI. They're one story, and the moral runs the same in both directions. The more the machine writes, the more someone with judgment has to stand between it and production. AI is the arsonist and AI is the fire brigade, fine. But somebody still has to know whether the fire's actually out. That somebody is us. That was always us.
The optimists and the doomers are both half right.
The software really is more broken. And the tool that breaks it really can help test it. What neither camp says out loud is the part that matters most. It only works if there's a real tester in the loop who can tell a good test from a green checkmark. Take that person out, and you've just automated the henhouse audit.
So no. I'm not worried the job is going away. I'm worried about the teams that think it already did.