Vibe coding tips and tricks
github.com
github.com
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"One of the greatest quotes in the history of computer science:
“On two occasions I have been asked, – "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" ... I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question"
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.
This particular example isn't very useful, but anecdotally it feels very nice to not need perfect syntax. How many programmer hours have been wasted because of trivial coding errors?
Historically probably quite a lot, but with a decent editor and tools like gofmt that became popular in the past 10 years I'd say syntax is just not a problem any more. I can definitely recall the frustration of a missing closing bracket in HTML in the 90s, but nowadays people can turn out perfectly syntactically correct code on day 1 of a new language.
Easy way to say it is that source code requires perfection, whereas pseudo-code takes the pressure off of that last 10%, and IMO that could have significant benefits for cognitive load if not latency.
Still all hypothetical, and something I’m actively experimenting with. Not a hill I’m gonna die on, but it’s super fun to play and imagine what might be possible.
for ever my file in directory 'd' ending '.capture':
Read file
Split every line into A=B:C
Make a dictionary send A to [B,C]
Return a list of pairs [filename, dict from filename]
Yes. Well, it depends.
Most of the prompts specifying requirements and constraints can be reused, so you don't need to reinvent the wheel each time you prompt a LLM to do something. The same goes for test suites: you do not need to recreate a whole test suite whenever you touch a feature. You can even put together prompt files for specific types of task, such as extending test coverage (as in, don't touch project code and only append unit tests to the existing set) or refactoring work (as in, don't touch tests and only change project code)
Also, you do not need to go for miracle single-shot sessions, or purist all-or-nothing prompts. A single prompt can fill in most of the code you require to implement a feature,and nothing prevents you from tweaking the output.
It is seriously quicker because people like you and me use LLMs to speed up how the boring stuff is implemented. Guides like this are important to share some lessons on how to get LLMs to work and minimize drudge work.
the results are good because as another replier mentioned, LLMs are good at style transfer when given a rigid ruleset -- but this technique sometimes just means extra work at the operator level to needlessly define something the model is already very aware of.
"write a fizzbuzz fn" will create a function with the same output. "write a fizzbuzz function using modulo" will get you closer to verbatim -- but my point here is that in the grand scheme of "will this get me closer to alleviating typing-caused-RSI-pain" the pseudocode usually only needs to get whipped out when the LLM does something braindead at the function level.
Hence, LLMs can be helpful to produce boilerplate / glue code, the kind that has already been written in many variations, but cannot be directly reused. Anything novel you should rather outline at a more detailed level.
Rules it out for me; I haven’t felt I thoroughly understood any code after working with C++ and reading the entries in code obfuscation contests.
It’s a bit of a catch-22 to say “anyone can code with AI” and then make such statements.
Also makes it very much not "vibe" coding. The term keeps expanding into "any coding activity with AI assistance" but the whole idea of "vibe" coding is that you don't actually understand the generated code, and likely don't know how to program at all, you're just prompting AI to do everything.
Once you step into reviewing & understanding, you're no longer vibe coding you're just...coding.
He started to trust the code written by the models to a point where he didn't always read the code. This happens when you you have learned the exact limits of your models.
It's like a senior coder who knows the projects the interns can handle without close supervision, and those they can't.
Seems to me the result should be that if you aren't sure, your feedback when reviewing the code is that it needs to be more readable. Send it back to the LLM and demand they make it easier to understand.
I think this is good advice actually. We do allow LLM agents where I work, but you still need to understand every line of code that you write or generate. That’s probably why we still do physical interviews as well.
Basically all of the suggestions on that page were good practice, and not just for code. Documenting your changes, reviewing the output of an AI (or junior person), writing meaningful commits ... all of these apply equally to code, contracts, whatever. I read this post as "If you want vibe coding to be coding you still have to do a lot of hard work and not treat it as a magic app engine." Which is true but absolutely not what a lot of vibe code-embracing middle managers want to hear.
I don't think I could enjoy working at a place where people didn't know the content of the commits they made. I remember the early talks of vibe coding being that you're not even supposed to look at the code, and have been very happy that I haven't met anyone professionally that codes like that.
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.
A CGI film is still a CGI film even if artists at the studio hand-paint certain objects in certain frames.
A Python program is still a Python program even if it calls out to C code for a handful of key functions.
I suspect most people would consider an AI generated image to still constitute AI art even if the creator touched up a few things in Photoshop.
Sometimes I call it vibe coding ++.
> the human developer avoids micromanaging the code, accepts AI-suggested completions liberally, and focuses more on iterative experimentation than code correctness or structure.
> A key part of the definition of vibe coding is that the user accepts code without full understanding.
I think most people should try to really "vibe" in the original sense. Use SuperWhisper and don't even read the diff. It's a different experience. I am not saying ship critical code like this... but if your main use of LLM AI tools is to basically type code faster than you (which is totally fine and it's what I do at work), that's not really vibing.
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...
It's what you describe: Someone using LLMs to code stuff. I didnt really end up watching it so I can't really speak to the content but it should be the type of thing you're looking for.
this is what sold me. This guy builds a useful tool for himself and follows you through the process.
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.
It may have come to mean what you describe to some, but that's more commonly what we call managing a junior engineer. As before, no need for redundancy.
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.
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.
A good next step is to have the model provide a detailed step by step plan to implement the spec.
Both steps are best done with a strong planning model like Claude Opus or ChatGPT5, having it write "for my developer", before switching to something like Claude Code.
The chat apps are pretty good at internet searches without all the ads and SEO crap. So I use the chat app, it's okay at context (knows which language and framework I'm using) and can basically get me the same answers as the docs would provide in less time.
Still makes mistakes in code examples though, so I'd never trust it to actually change my code.
I like spec driven development, especially for someone as ADD as me. Keeps me from thinking about a new feature while working and dropping everything to implement it.
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.
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.
"Vibe Coding" is a goofy and unserious practice though. The headline reads like "Oracle Best Practices to Hit the Griddy"
Between selling more bedrock usage or cutting their own headcount.
I look forward to the day when AI really can do all coding and replace every single human programmer on the face of the Earth, for no other reason than that I will no longer have to see this insidious phrase ever again.
And this will be the achilles of our future generations.
God bless old times when programmers cared about quality rather than stuff like this... "vive coding"... My God...
1. Don't.
2. Don't do it.
3. Seriously, don't.