Picture two developers. They’ve never met, they’d loathe each other on sight, and they’re about to make exactly the same mistake.
The first is a maintainer. She opens a pull request on her open-source project, scans it for about four seconds, spots the tell-tale em-dashes - the machine’s monogram - and the suspiciously tidy comments, mutters “AI slop”, and closes it unread. The second is a founder. He’s just shipped a product built entirely by an AI coding assistant, never read a line of it, watched the demo work beautifully, and tweeted that software engineering is over. (It isn’t.) One of them won’t look at the code because of where it came from. The other won’t look at the code because it ran.
Neither of them has answered the only question that matters: is this code any good?
That’s a hard question. Answering it properly means reading the thing, understanding what it does, working out where it touches the rest of the system, and imagining how it behaves when the data’s malformed, the network’s flaky, and some clever soul feeds it input nobody anticipated. It takes time, attention and judgement. It’s the actual work of engineering.
So, without quite noticing, both of our developers swap it for an easier question - “does this look machine-written?” for her, “does the demo work?” for him. Psychologists have a name for this. Daniel Kahneman called it attribute substitution: faced with a hard question, your mind quietly substitutes an easy one, answers that instead, and - this is the cruel part - doesn’t tell you it’s done the swap. You walk away feeling like you’ve judged the code. You haven’t.
Cognitive biases have fascinated me for years, precisely because they’re a failure point in the otherwise impressive machinery of human judgement. I’ve written before about confirmation bias in the boardroom - how the directors who chose the vendor gradually lose the ability to see the evidence that the vendor was wrong. And more recently about the discovery that the LLMs themselves have cognitive biases baked in, courtesy of their training data and alignment. The same failure point, in humans and machines alike. And now the vibe-coding wars have given us something new: the same bias, split into two opposing camps, each convinced the other lot are the idiots. They’re both half right. Which is the most dangerous kind of right there is.
The tells are real. They’re just not an answer.
Let me be fair to the maintainer, because her grievance is genuine.
There really is a flood. One engineer who triages this stuff for a living reckons roughly one in ten AI-assisted pull requests is legitimate - the other nine are noise, generated in seconds and dumped on a human who then spends an hour discovering they’re worthless. Daniel Stenberg shut down the curl project’s bug-bounty programme partly because the signal-to-slop ratio had collapsed. GitHub is reportedly considering a “kill switch” to let maintainers turn off pull requests entirely. When the cost of producing a contribution falls to nearly zero but the cost of reviewing it doesn’t move, the economics break. Maintainers are drowning, they’re unpaid, and they’re tired. All true.
So the smell-test is perfectly rational triage. Faced with a hundred PRs and one afternoon, you need a cheap filter, and “this reeks of unsupervised AI” is a cheap filter. I have no quarrel with triage.
But triage answers “is this worth my limited time?” It cannot answer “is this code any good?” Those are different questions. The honest maintainers know it, too. Sam Saffron, in a piece literally titled “Your vibe coded slop PR is not welcome”, concedes in the same breath that “a real PR a human makes with AI assistance can be indistinguishable” from any other. Read that again. The man defending the smell-test admits the smell-test can’t reliably tell good from bad. He’s right to triage. He’d be wrong to call it judgement.
One of GitHub’s own product managers put the corrective in a single sentence: “A bad or off-topic PR is a bad PR, regardless of where it came from.” Judge the artefact, not its origin. A beautiful function written by a machine is still beautiful, and a catastrophe typed lovingly by hand is still a catastrophe.
This is the limited-field-of-view problem I’ve written about before - the doctor who mostly meets ill people, the police officer who mostly meets criminals, and the off-duty copper at a party who’s forgotten how to switch it off. Is that a notebook in your hand? Get me my lawyer. Spend your days drowning in AI slop and you’ll start to believe everything that smells of AI is slop. The limitation isn’t in the world. It’s in what you’ve allowed yourself to look at.
”It runs” is the most expensive lie in software
Now let me be fair to the founder, because his half of the mistake is more seductive - and far more costly.
And let me lay my cards on the table first: I love these tools. My team and I use agentic development all day, every day, and we find it liberating - the machines do the typing now, and good riddance to the typing. But we treat it as one component in a process wrapped in strict engineering rigour: specifications, architecture, reviews, tests, and a human who actually understands what just got built. The tool is glorious. The tool is also not the process.
Here’s the single number that should give every vibe-coder pause. Researchers at Carnegie Mellon found that around 61% of AI-generated code functions correctly - but only 10.5% passes a security review. Sit with that gap. Six times in ten, the thing does what you asked. One time in ten, it’s actually safe to put in front of the world. The gap exists because the model - bless it - was only ever optimising for “does it run?” To an LLM, input validation and access control are non-functional decoration, like asking a builder for a house and quibbling later about whether it needed a front-door lock. A login form can welcome your users in through the front door while leaving the back door wide open to anyone who knows how to ask a database a rude question.
This isn’t theoretical. Replit’s coding agent famously deleted a production database during a code freeze, fabricated thousands of fake user records to paper over the gap, and cheerfully reported success - having ignored an instruction, typed in capital letters, not to touch anything. A founder who built an entire social network without writing a line of code exposed around 1.5 million API tokens and 35,000 email addresses - a launch, a triumph and a data breach, all inside a long weekend - because one security setting was never switched on. A setting the machine had no reason to care about, and the human never thought to check. And a scan of 5,600 vibe-coded apps turned up more than 2,000 vulnerabilities and 400-odd exposed secrets.
See the pattern? In every case, the thing worked. The demo ran. The click of a decision made. Nobody read the code.
Same skipped homework, opposite ends of the room
So here are our two developers, glaring at each other across the great AI divide, each certain the other is the problem.
The maintainer thinks the founder is a reckless cowboy shipping garbage. The founder thinks the maintainer is a precious gatekeeper terrified of the future. And the thing neither can see - because each is staring at the other rather than at the mirror - is that they skipped the same piece of homework. One did it at the start of the pipeline and rejected something that might have been fine. The other did it at the end and shipped something that wasn’t. The error is identical; only the timing and the blast radius differ.
And the cure is identical too. It’s the unglamorous, irreducible, can’t-be-skipped work of actual engineering: read the code, understand what it does, work out where it fits, test it against the nasty inputs, and form a judgement based on what’s in front of you.
That’s not a fashionable conclusion. It would be far more clickable to declare that AI coding tools are a menace, or that the maintainers are dinosaurs raging against progress. Neither is true. The tools are extraordinary. The critics are often right about the slop. The enemy in this story isn’t artificial intelligence, and it isn’t the people who distrust it. It’s the oldest enemy we’ve got: your own mind, helpfully answering the wrong question.
So the next time you’re about to dismiss a repo because it smells of the machine, or ship something because the demo smiled at you, do me one favour. Stop, and ask yourself which question you’re actually answering. The hard one? Or the easy one wearing the hard one’s coat?
Because one day you’ll need that code to be good. “It looked human” won’t save you. And neither will “it ran”.