The Problem Was Never Vibecoding

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

She gets 5–15 a day. The FCC's actual advice is to report each one at donotcall.gov, a three-minute form, hundreds of times over. 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," he meant something specific: fully giving in to the vibes, accepting every suggestion, never reading the diff for throwaway weekend projects. 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 the reflex went too far.

The slur isn't vibecoding; it's *vibecoder*. Call someone a vibecoder and you're not critiquing how they work; you're dismissing them for using AI at all. Lazy engineer. No rigor. Can't really code. A tidy label you can throw at anyone who opens an agent instead of a blank file. That confuses the tool with the carelessness, and it lets the industry pretend the problem is the person, not whether they have judgment.

The skill was always "doing it well"

Here's what the sneer misses: there's an enormous gap between good vibecoding and bad vibecoding, and it's 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. Running it. Making sure the thing actually works.

That's not vibes. That's judgment, the same judgment that was always the job. The model changed; the discipline didn't. 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?

That's measurable. At AlgoArena, we built assessments around exactly that signal: not whether someone used AI, but whether they used it with care.

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. You can't really critique a tool you've never felt work; the warnings land as abstract anxiety and slide right off. 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.

Verification is the spine of all of it. A model will always generate faster than you can read, so the skill that separates people is deciding what to check and then actually checking it. Generating is cheap now. Knowing what has to be true, and confirming it is, is not.

We're building a free course around that sequence: competence before critique, verification before speed. It's early, still being written, and it hasn't run in a real classroom yet, so I'm describing a bet, not a proven result. 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. Bad writing exists. We didn't ban the pen.

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 & CEO @ AlgoArena