The approach I've taken to "vibe coding" is to just write pseudo-code and then ask the LLM to translate. It's a very nice experience because I remain the driver, instead of sitting back and acting like the director of a movie. And I also don't have to worry about trivial language details.
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"
That's a really powerful approach because LLMs are very very strong at what is basically "style transfer". Much better than they are at writing code from scratch. One of my most recent big AI wins was going the other way; I had to read some Mulesoft code in its native storage format, which is some fairly nasty XML encoding scheme, mixed with code, mixed with other weird things, but asking the AI to just "turn this into psuedocode" was quite successful. Also very good at language-to-language transfer. Not perfect but much better than doing it by hand. It's still important to validate the transfer, it does get a thing or two wrong per every few dozen lines, but it's still way faster than doing it from scratch and good enough to work with if you've got testing.
My mental model for LLMs is that they’re a fuzzy compiler of sorts. Any kind of specification whether that’s BNF or a carefully written prompt will get “translated”. But if you don’t have anything to translate it won’t output anything good.
I agree with that assessment but that makes me wonder if a T5 style LLM would work better than a decoder only style LLM like GPT or Claude. Has anyone tried that?
Is this seriously quicker than just writing in a language that you know? I mean, you're not benefitting from syntax highlighting, autocompletion, indentation, snippets etc. This looks like more work than I do at a higher cost and insane latency.
I find it particularly useful when I would need to look up lots of library functions I don't remember. For example, in python I recently did something (just looked it up:
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]
I don't python enough to remember reading all files in a directory, or splitting strings. I didn't even bother proof reading the English (as you can see)
Those are just features waiting to be developed. I'm currently experimenting with building LLM-powered editor services (all the stuff you mentioned). It's not there yet, but as local models become faster and more powerful, it'll unlock.
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?
> Is this seriously quicker than just writing in a language that you know?
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.
I do something similar, merely writing out the function signatures i want in code. The more concrete of the idea i have in my head the more i outline, outline tests, etc.
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.
Yeah I'm nowhere near ready to loosen the leash. Show me a long-running agent that can get within 90% of its goal, then I'll be convinced. But right now we barely even have the tools to properly evaluate such agents.
I initially used natural language as prompts, but the code output wasn’t ideal. When I listed the steps it should follow, I found that it executed them very well.
I do something like that when I get down to the function level and there is an algorithm that is either struggling for the role or poorly optimized, but the models that excel in codebase architecture have their hands held behind their back with that level of micromanaging.
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.
But "write a fizzbuzz fn" has one important assumption / limitation: the LLM should have seen a ton of fizbuzz implementations already to be able to respond.
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.
> 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.
I've expressed this to others as much as is reasonable - but the phrase "vibe coding" shouldn't be used in any serious discourse about agentic tools. We can't control the lens under which a given person first heard the term, but that moment (combined with the mountains of memes they've consumed since) is going to color a lot of folk's personal definition of vibe coding. It's not realistic to expect everyone to have a shared definition of it, despite the inventor of the phrase immediately giving it definition.
You are, I think reviewing and understanding the code and the app are very important, but the moment you go in and code yourself you're not vibe coding anymore. I think you break vibe coding when you touch the code yourself and have to manually make edits not when understanding and making sure the llm did what you asked it.
The first self-announced vibe coder was a founder of OpenAI. So he had the knowledge.
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.
> I haven’t felt I thoroughly understood any code after working with C++ and reading the entries in code obfuscation contests.
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.
> Always: > > Thoroughly review and understand the generated code
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.
It's great advice for anything AI-generated in a professional production environment. I think the question is whether it's vibe coding with that requirement in place. Or, rather, if the requirement is appropriate for how vibe coding is often used and promoted today (by non-coders).
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.
> "Thoroughly review and understand the generated code"
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.
Maybe the zeroth tip is "never go full vibe coder."
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.
It's a lot of (good) actual engineering or solid programming tips, and yeah it's not "vibing". There's no embrace the exponential or just pasting errors.
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.
Unless you touch the code, you're still vibe coding if you just review and ask the LLM to change. You're coding when you touch the code yourself and make edits to what LLM made.
> 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.
It's too bad the "vibe coding" definition is so strict. You could have an app that was completely AI generated, but the moment you even peak at the generated code or make a small revision, it is no longer a vibe coded app.
Nobody’s coined a fun catchy phrase for half vibe coding / half real engineering, so I will continue to refer to my AI assisted adventures as vibe coding :)
the page is an interesting display of a very large bureaucratic institution that is extremely worried about being sued, but is still utterly desperate to get in on the AI bubble before it pops
On a slightly related note... I'm kind of out of the loop wrt coding with AI. I was trying to find some youtuber working on some interesting project using AI to get a feel for how useful it could be but didn't have much luck (I didn't get past the "top 10 AI tools to use for coding" style videos). I was thinking something in the style of tsoding if you're familiar with his projects.
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.
I'm starting to think of "vibe coding" as "peer/pair programming". How effective it will be depends on how effective I am as the peer reviewer.
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.
"Vibe coding" was intended to mean where you don't pay attention to the work your partner creates at all. Where you just lean into their "vibe" and run with it, no matter how bad it actually is. What you describe already has a name. You even mentioned it yourself. Also calling it "vibe coding" would be a bit redundant.
No Vibe Coding is when you dont touch the code yourself and only ask the LLM to make edits for you. You still understand and make sure llm does what you asked, but you dont touch the code yourself.
Readit News
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.
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?
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.
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.
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.
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]
[1] https://x.com/karpathy/status/1886192184808149383
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 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.
> 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.
https://en.m.wikipedia.org/wiki/Vibe_coding
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 ++.
Dead Comment
https://steipete.me/posts/2025/essential-reading-july-2025
https://steipete.me/posts/2025/the-future-of-vibe-coding
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.
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.