Don't Call It Vibe Coding
A few weeks ago a developer looked at my codebase — properly looked, not a polite glance — and told me he'd be comfortable committing to it. Not "it works," not "good effort." He said the architecture was sensible and he'd have no problems working alongside it.
This is not the reaction you'd expect from someone who's never held an engineering title, never studied computer science, and learned most of what he knows about software by building things and breaking them at inconvenient times.
I am, by most reasonable definitions, not a developer. And yet I've shipped production apps, passed security reviews, and built systems that real engineers have looked at and said — without charity — are well put together.
So when someone calls me a vibe coder, I bristle a little. Not because I'm precious. Because it's not accurate.
Here's the thing about "vibe coder" as a label: it's become a catch-all for anyone who uses AI to write code. That's like calling anyone who uses a calculator a mathematician — and also calling anyone who uses a calculator an accountant who just got lucky. The label doesn't distinguish between someone who understands what they're building and someone who genuinely doesn't.
At one end of the spectrum, there are people throwing prompts at Cursor and shipping whatever comes back. No code review. No understanding of the architecture. No idea what happens when it breaks at 2am. At the other end, there are developers who've been writing software for twenty years and use AI to go faster — the same way they used Stack Overflow before it.
I'm somewhere in between. Closer to the second end than most people assume.
What I've learned — and this took time — is that building with AI rewards a very specific kind of intelligence that doesn't show up in a GitHub commit history. You need to understand a problem well enough to describe it precisely. You need to recognise when the output is technically correct and completely wrong. You need to know when to push back on what the model gives you, when to restructure the prompt, and when to walk away and think about the problem differently. That gap — between "it compiled" and "it's right" — is where all the actual skill is.
I've built a deployed cookbook app used by real people. I've built internal tools that run without babysitting. I've had my code pass security audits. I've refactored things that weren't working, debugged production issues late on weeknights, made architectural calls that turned out to be the right ones. None of that happened because I got lucky with prompts.
What I am, exactly, I'm still working out. "Accidental developer" is close but undersells the deliberateness. "AI-native builder" sounds like a LinkedIn headline. "Knows enough to be dangerous" is probably most honest, but there's a version of dangerous that's reckless and a version that's just unusually effective — and I'd like to think I'm the second one.
What I'm not is a vibe coder. Because vibe coding implies no understanding — just vibes. And the difference between building something that works and building something that works and holds up under scrutiny is not vibes. It's judgment, iteration, and knowing when to ask a better question.
The tools I use aren't the story. Whether the thing I shipped is any good — that's the story.
Which, apparently, it is.
I've got references.