That isn't vibe coding though.
Vibe coding means you don't look at the code, you look at the front / back end and accept what you see if it meets your expectations visually, and the code doesn't matter in this case, you "see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works." [1]
If the changes are good enough, i.e. the front/backend works well, then it's good and keep prompting.
You rely on and give in into the ~vibes~. [1]
It can be tempting, but there's so much impact that even small changes to the code can have, and often in subtle ways, that it should at least be scanned and read carefully in certain critical parts. Especially as you near the point where hosting it on AWS is practical.
Even in Karpathy's original quote that you referenced he says "It's not too bad for throwaway weekend projects, but still quite amusing. I'm building a project or webapp, but it's not really coding." Maybe it should have been called vibe prompting.
I've been playing around with vibe coding for a few months and my experience doesn't really match this advice.
I used to think this was the correct way and based on that was creating some huge prompts for every feature. It took the form of markdown files with hundred of lines, specifying every single detail about the implementation. It seems to be an effective technique at the start, but when things get more complex it starts to break down.
After some time I started cutting down on prompt size and things seem to have improved. But I don't really have any hard data on this.
If you want to explore this topic one thing you can do is to ask you LLM to "create a ticket" for some feature you already have, and try to play around with the format it gives you.
A little different than "spec", but one-shotting things works great if that's going to get you as far as you want to go. If you're adding neat-o features after that, it can get a little messy because the initial design doesn't bend to the new idea.
Even something like adding anti-DDOS libraries towards the end, and then having to scope those down from admin features. Much better to spec that stuff at the outset.
One, admittedly silly, example is Claude trying to put a light/dark theme switcher when you are trying to refactor the style of your small webapp.
I'm not against a theme switcher, but it is certainly not a trivial feature to implement. But Claude doesn't seem to understand that. And by having simpler prompts I feel it gets easier to steer the LLM in the right direction.
Thinking is always the bottleneck, so what you need most are:
- A reduction of complexity in your system.
- Offloading trivial and repetitive work to automated systems (testing, formatting, and code analysis)
- A good information system (documentation, clear tickets, good commits,…)
Then you can focus on thinking, instead of typing or generating copious amount of code. Code is the realisation of a solution that can be executed by machines. If the solution is clear, the code is trivial.
And, you know, LLMs are mostly dumb typists, but sometimes they do dump something better than what I had in mind, and I feel that I lose that if I try to constrain them.
I think it might have something to do with context rot that all LLMs experience now. Like each token used degrades the token after it, regardless of input/output.
Never blindly trust code generated by AI assistants. Always:
Thoroughly review and understand the generated code Verify all dependencies
Perform necessary security checks"
This of course makes sense, but is not vibe coding.
I suppose we'll see an effort to steer people away from vibe coding nonsense by redefining the term, which makes sense.
The driver is the AI who is highly capable but has a 5% chance of doing something psychotic lol. Me, the peer, can either review carefully and catch errors or just relax and "vibe" through it all. Results will of course vary based on that relationship.
I'm not even a youtuber and make these to keep myself accountable, so it's not that fun to watch, but it might be in the direction of your query:
https://www.youtube.com/watch?v=d9YCkWjD7WQ&list=PLEWSTtjNAw...
Here's a prompt I'd make for fizz buzz, for instance. Notice the mixing of english, python, and rust. I just write what makes sense to me, and I have a very high degree of confidence that the LLM will produce what I want.
fn fizz_buzz(count):
loop count and match i:
% 3 => "fizz"
% 5 => "buzz"
both => "fizz buzz"However this is far less vibe coding and more actual work with an LLM imo.
Overall i'm not finding much value in vibe coding. The LLM will "create value" that quickly starts to become an albatross of edge cases and unreviewed code. The bugs will work their way in and prevent the LLM from making progress, and then i have to dig in to find the sanity - which is especially difficult when the LLM dug that far.
I now spend time gathering as much documentation as possible and inserting it within the prompt as a <documentation> tag, or as a cursor rule.
moolcool•1h ago
NitpickLawyer•1h ago
Eh, it might be just someone wanting to jump on a trendy term, without understanding it properly. The file actually makes good points about moving from vibes to structure, which is fine.
Amazon also has their own clone of vscode (who doesn't these days) that focuses on some things mentioned here as well. They take your prompt and get it through a process of documenting - clarifying - planning, leading to solid results in the end. The problem with their approach is that it's nothing particularly "proprietary" and you can pretty much have the same experience with some slash commands and dedicated prompts in any other code assistant.
moolcool•1h ago
"Vibe Coding" is a goofy and unserious practice though. The headline reads like "Oracle Best Practices to Hit the Griddy"
taormina•59m ago
esafak•54m ago