“Vibe coding” is causing a pretty serious rift in the developer community, so I figured I’d do the responsible thing and actually try it, hands off, vibes only, and see if I could form a real opinion instead of just reacting.
For context: I’ve been programming since 2018. I’m comfortable in C/C++ and JavaScript, and I’ve built real systems, not just demos. One example is tessera - How I Built a Renderer for Node.js, which is the renderer this audio streaming system is meant to plug into.
I’ll say this upfront: I’m anti-vibe coding.
Not anti-LLM.
Anti vibe coding.
It’s one of the most misleading and outright harmful terms we’ve managed to invent. The marketing around it is especially egregious: turn off your brain, let the vibes take over. That’s a cute idea, for anything serious, it’s nonsense.
I use LLMs constantly. ChatGPT, Claude, DeepSeek. Boilerplate, ideation, sanity checks. But the hype framing this as “you no longer need to understand anything” is bad. Especially for beginners, who are about to discover the hard way that coding was never the hard part to begin with.
Everyone has ideas. If ideas plus vibes were enough, we’d be drowning in revolutionary new software by now. We’re not. But skepticism aside, I decided to let go and follow the vibes.
Letting the Vibes Drive
To be clear, I didn’t go in totally blind. I nudged the LLM in the right direction because I understand audio streaming, ring buffers, and how this needs to integrate into a renderer. Even so, the result was… exactly what I expected.
- It works.
- No crashes.
- No obvious errors.
But if you look closely, it doesn’t really work.
What I got was the probabilistic average of how someone might implement audio streaming. No novelty. No awareness that this stream lives inside a renderer. Just the most statistically likely solution.
And honestly, being average isn’t even the worst part.
The worst part is this:
2.1 thousand lines of something.
I wish I was exaggerating.
This has nothing to do with AMP, by the way, it’s a great tool. Their free-to-paid transition is actually impressive. These are just frontends to LLMs doing what LLMs do.
For reference: audio streaming with something like raylib (which is the case here) is sub-100 lines of clean C++ if you know what you’re doing.
So what are those 2k+ lines?
Look closely at the end. The TODOs.
At first glance, you might not see the problem. Here’s the problem:
- I now have an average solution that I must read and debug
- My repo is polluted with thousands of lines of autogenerated markdown “documentation”
- I waited a long time for this to generate, time in which I could’ve just written the thing
The Real Cost: Reading Code
If you’ve ever inherited a codebase, you already know this pain.
If you haven’t, here’s an exercise: fork any project you rely on and try reading it.
Reading code you didn’t write is hard.
It’s not connected to your mental model.
It doesn’t live in your head.
Now try reading code that mostly works, but not quite.
There’s an old saying in low-level circles: “I like segfaults because they tell me exactly what’s wrong.” And it’s true. There’s nothing more terrifying than code that looks reasonable, runs, and silently does the wrong thing.
That’s what vibe coding gave me.
In the end, I spent more time dealing with this than I would’ve spent just writing it myself, using my brain, plus LLMs where they actually help.
Now imagine someone with no programming background.
How many times do they re-prompt?
What do they even say is “wrong”?
Where I Actually Landed
As I write this, I’m honestly demotivated. I have zero desire to look at those changes.
So I’m going to use an LLM the way I actually recommend using one: as a tool.
“Claude, comb through this and give me a concise outline of how it works, plus links.”
That’s it.
Final Thought
Anti–vibe coders aren’t anti-LLM. We’re anti brainless, the marketing fantasy, and the very real damage it does to beginners. That’s all we’ve been saying from the start.
But hey. It’s your life.
Use it however you see fit.
Top comments (0)