Breaking up with vibe coding

I find reports on how others are using LLMs to code interesting to read.

I've personally found LLMs to have recently crossed the "uncanny valley" of programming for me, meaning that I'm much much more productive than without them.

I find that if you're really good at describing a problem and the constraints you want to solve, using a language it knows well (like Go) and following well known patterns in that language, you can describe thousands of lines of code and get accurate results.

Maybe this isn't vibe coding speicfically, but I actually review every line of code that the LLM puts out. It doesn't take long if you know what you're reading, and the LLM make a weird solution to the problem. Usually if I'm specific about how I want it solved, it does it well.

I also found it useful to say "Please tell me your plan to implement the solutions and ask me about any ambiguities that need clarification." In other words, don't make your own assumptions.

The results are incredible. Thousands of lines of code that maybe not stylistically like mine, but are structurally very accurate to what I'm looking for. Giving function/interface signatures and code examples works wonders.

I think there is inherent value in expressing your own thought, from the start, in a formal language.

This is why mathematics has stayed with us in spite of the fact that it's eminently possible to express mathematical ideas in natural language. The precision, clarity, and brevity we gain from formalization is useful.

I think code falls into a similar bucket. Reaching for LLMs makes some amount of sense for throwaway code, but not for serious systems. Code is not merely the raw material with which you happen to realize fuzzy ideas, it is also a means of making once fuzzy ideas precise—and for this benefit to be realized, the communicating human has to participate in the formalization. I don't want to have to deal with a world in which all our systems were authored through fuzzy imprecise language and half-baked, not completely formally analyzed ideas. That's a step backwards. Life isn't only about cost cutting and short term "efficiency".

Vibe coding isn't for building production code. It's for exploratory prototypes - figuring out if something is possible and trying different versions of how it might work as quickly as possible.

It's also OK for low stakes personal tools where you're willing to risk avoidable bugs since they'll only affect you.

For code you intend to actually to deploy to other people or maintain long term you need to move beyond vibe coding and actually look at, understand and iterate on the code that it produces.

The moment you start doing that it stops being vibe coding, which is defined by the act of not caring about the code that was produced for you.

https://simonwillison.net/2025/Mar/19/vibe-coding/

> "We’ve all been there: headphones on, music pumping, fingers flying across the keyboard, lost in the “flow” with your favorite AI agent. This, my friends, is vibe coding. It’s when you’re in the zone, seemingly effortlessly producing code."

Because everyone knows how much cooler the "hacker / coder" man scenes in movies would have looked like if they were just prompting ChatGPT.

More seriously, my main issue with vibe coding (outside of throwaway prototypes) is that using the "code runs" as a metric isn’t a good way to tell whether the code is actually correct. It just feels like a great way to introduce sublte edge case bugs later downstream. You do your application a disservice by not at least taking a minimal amount of time to review the LLM output.

Vibe coding is the worst thing that's happened to our profession in the last 20 years. Or perhaps the best, after all, someone has to debug those catastrophic messes masquerading as applications.

I now find Vibe coding an apt name (because I find it horrible) for something that usually has nothing to do with coding. Like prompt engineering usually has nothing to do with engineering. While non-coders or bad coders can create things that look and act passible if not too large, it turns out it doesn't actually go all the way, even with patience. People who change/build/release large production systems using AI, are actually programmers and use LLMs to whip up swats of boilerplate (which, for us, means only frontend; our backend system has been good enough to just type what you want in terse format code which is far faster than English and of course very precise as no LLMs there), but we read the code after and when LLMs get stuck, we fix it. The new 'vibe coders' cannot really do that as they don't understand what went wrong and the LLM, helpfully, tells them every iteration that YES now it knows and fixes it; change a massive part of your app, but nope, doesn't work. Loop around until sanity gives out or just delete and start over (I see people do that with good results; LLMs are just better at one shot than with changes).

Spending $30/mo means this person has definitely not dug in very hard on Claude Code. My partner and I are spending more like $30/day using it for vibe coding.

One of the things I find really helpful and grounding, both to me and the LLM, is working in a tree-like (or fractal) pattern.

First I create the trunk (a broad outline of what I wish to accomplish). Then I concentrate on filling out the branches (the individual bullet points of that broad outline). Then I drill down into the twigs and then the leaves.

It's a different workflow than what I used to follow before LLMs arrived, where I tended to build bottom-up, rather than top-down. But it seems to keep both me and the LLM on track.

Even though it's structured, is it still vibe coding? Well, I think of vibe coding mostly in terms of the psychology. If whatever I'm doing induces a feeling of flow, then that's the vibe I'm going for. https://en.wikipedia.org/wiki/Flow_(psychology)

Related note: Karpathy is really good at naming things. Seems whatever name he comes up with for new things sticks.

I use LLM in my workflow a lot, however it never occurred to me there's any vibe until this online running joke.

And no, the vibe is largely the same as before, there was google, then stackoverflow, and then now here's an AI that would most likely take care of the specific question and generate boilerplate if you frame the question correctly.

Framing the question correctly isn't a vibe, it requires logical thinking that feels almost like coding, and results need to be checked. Even then, I usually don't go a day without spotting some sort of hallucination (correcting obvious wrongs during prompting doesn't count). And testing is essential because sometimes that's how you can catch this kind of hallucination.

I do find learning in terms of project and even coding itself improves a lot faster with a capable LLM. It introduces a lot of idiomatic ways to code, and provides a lot of practice to fix whatever didn't work or add things that are just easier to type then asking it to fix.

I found my experience with AI Chat vs web search much different than OPs. For me AI chat almost always gives better results than web search. Most of the time I use it it's when I know that what I'm doing is possible but I'm not sure exactly how to do it. For example writing some SQL recently I wanted to know how to write a query in a slicker way and Gemini was able to output something that I'd never have been able to search for and that coming up with on my own would have required 30 minutes to an hour of reading docs.

My one-evening vibe coding experiment with building a personal rag system ended up lasting three weekends, costing $60, and working MUCH worse than ripgrep.

I find AI very helpful for some programming problems and GH Copilot can be very useful sometimes (especially, when it is not overeager), but this vibe coding business is beyond me.

(I only used OpenHands and Trea in Docker. I haven't tried more premium products due to budget constraints. In hindsight, maybe I should have.)