The Problem Was Never Vibecoding

A month ago, I vibecoded a tool to fight my mom's spam calls.

She gets 5 to 15 a day. The FCC's actual advice is to report each one at donotcall.gov, a three-minute form, hundreds of times over, which is hopeless by hand. So in one afternoon, with AI coding agents, I built the pipeline: scrape her voicemails, classify the spam, auto-fill the FTC form, file each complaint, retry when the government throttled me. Nearly 3,000 voicemails in, 222 complaints filed, about $2 of API cost. Two years ago I wouldn't have shipped that. I'm not a Playwright expert. I didn't have to be.

That's vibecoding. And somewhere along the way, *vibecoder* became the insult.

Where the sneer comes from

Give the term its due. When Andrej Karpathy coined "vibecoding" for throwaway weekend projects, he meant something specific: fully giving in to the vibes, accepting every suggestion, never reading the diff. By that definition, vibecoding is sloppy on purpose. And when people started shipping that straight to production with no tests, no idea what the code did, and a shrug of "it works, I think," the backlash was earned. We've all reviewed the PR that the human who opened it clearly never read.

So I get the reflex, but it went too far.

The slur isn't vibecoding; it's *vibecoder*. Call someone a vibecoder and you're dismissing them for using AI at all, without looking at how they work. It's a tidy label for a lazy, careless engineer who can't really code, and you can throw it at anyone who opens an agent instead of a blank file. That confuses the tool with the carelessness, and it lets the industry blame the person without asking whether they have judgment.

The skill was always "doing it well"

What the sneer misses is the enormous gap between good vibecoding and bad vibecoding, which is the same gap that always separated good engineers from bad ones.

Bad vibecoding is "make it work," accept, ship, look away. Good vibecoding is breaking the problem down before you prompt, reading what the model gave you, catching the edge case it missed, knowing when to trust the diff and when to interrogate it, steering a wrong answer back instead of rubber-stamping it, and running the thing to make sure it actually works.

That's judgment, the same judgment that was always the job. If anything, AI raises the ceiling on what one person with good judgment can ship, and it raises the price of having none.

Banning AI doesn't protect rigor. It hides who has it.

This is the part the industry keeps getting backwards.

Most technical interviews still treat AI the way a middle school treats a phone: confiscate it at the door. Lockdown browsers. Plagiarism flags. "Please don't use Copilot." But banning AI from a coding interview doesn't tell you who's rigorous. It just makes everyone solve a puzzle the way nobody works anymore and sends the careful engineer and the reckless one home with the exact same score.

If you actually want to know whether someone's a good engineer in 2026, you don't take the AI away. You hand it to them and watch how they use it. Do they plan? Do they verify? Do they catch what the model got wrong? Or do they type "make it work" and doomscroll until the tests go green?

At AlgoArena, we built assessments to measure how carefully someone uses AI.

Competence, then critique

Assessments catch that difference after the fact. The harder problem is teaching someone to have the judgment in the first place, and here I have a bet I'm willing to state plainly and be wrong about.

The usual move is to front-load the fear. Lecture people about hallucinations and overreliance before they've shipped a single thing with these tools. I think that's backwards. The warnings land as abstract anxiety and slide right off, because you can't really critique a tool you've never felt work. So the bet runs the other way. Let people build real things first and get genuinely fluent. Let them feel the model succeed, then feel it fail on them. Only after that does the critical half land: how to catch the confidently wrong answer, how to debug a system you didn't write by hand, how to check instead of trust.

We're building a free course around that sequence: competence before critique, verification before speed. Verification is the center of it, for the reasons in How to Assess Developers Who Code With AI. The course is still early, as A Good Idea Shouldn't Have to Be in English explains, but it's the same bet the assessments make, pointed at teaching instead of measuring.

Reclaiming both

I'm not asking anyone to pretend bad vibecoding doesn't exist. It does, and it ships bugs. But "the careless version of a skill is bad" has never been an argument against the skill. We never banned the pen over bad writing.

Vibecoding is just coding now for most of us, on most days. And if that makes me a vibecoder, fine. The only real question is whether you do it with judgment or without. So I'll keep vibecoding, and I'll keep filing my mom's spam complaints with it.

Eli Young, Co-Founder and CEO of AlgoArena