Don't Call It Vibe Coding
I don't have an engineering title. I never studied computer science. Most of what I know about software I learned by building things and breaking them at inconvenient times.
I also build real software with AI. A cookbook app that people use. Internal tools that run without me watching them. Code that has been through security reviews.
So I've thought a fair bit about the label "vibe coder", and why it doesn't sit right with me. Not because I'm precious about it. Because I think it hides the part that matters.
The label covers too much
"Vibe coder" has become a catch-all for anyone who uses AI to write code. That's like calling anyone with a calculator a mathematician. It doesn't tell you whether the person understands what they're building.
At one end, people throw prompts at a tool and ship whatever comes back. No review. No idea how the pieces fit. No plan for when it breaks at 2am.
At the other end, developers with twenty years behind them use AI to go faster, the same way they used Stack Overflow before it.
Most people who build with AI sit somewhere in between. I do too.
Where the work actually is
The thing I've learned, slowly, is that AI moves the hard part. It doesn't remove it.
You still need to understand the problem well enough to describe it precisely. You need to spot output that is technically correct and still wrong. You need to know when to push back on the model, when to rephrase the question, and when to step away and think about the problem differently.
That gap, between "it compiled" and "it's right", is where the skill is. It's also where I've made most of my mistakes.
What helps me stay on the right side of it
None of this is clever. It's habit.
- Ask someone who knows more to look. Having a working developer review the code taught me more than any tutorial.
- Read what the model wrote. If I can't explain a piece of code, it doesn't ship yet.
- Test the boring paths. The bugs that hurt me were never in the interesting part.
- Treat security as its own job. Run the scanners, read the findings, fix them.
So what do I call it?
I'm honestly still working that out. "Accidental developer" is close. "Knows enough to be dangerous" might be the most honest, as long as I keep working on the "knows enough" part.
What I'd like the label to describe is not the tool. It's whether the person cared if the thing they shipped was any good. That part isn't vibes. It's judgement, iteration, and asking better questions.