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 Cursor and Claude, 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 — no tests, no idea what the code did, "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.

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