AI is cool and all, but the biggest thing that makes me think that we’re in a bit of a bubble is seeing otherwise conservative organizations take “vibe coding” seriously
Even though they are using the wrong term here, the advice throughout the file is solid. I find it funny that it doesn't even mention kiro, which is amazon's take on a vscode clone, that focuses on processes instead of vibes.
> "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.
>Provide detailed specifications for the work to be done
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.
Everytime I see these tips and tricks, it reinforces my viewpoint thag it would be more productive to actually learn the abstractions of your framework and your tooling. Instead of wrestling with a capricious agent.
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.
That's how I've been doing it as well. There's no guarantee that the LLM will follow your minute, detailed, description, and dumping it all at once at the start of a session has made it perform worse in my case.
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.
This approach also breaks down for the same reasons the Waterfall model doesn't work. A lot of information is discovered during development, which causes specs to be outdated or wrong. At that point the LLM context is deeply poisoned, whether from the specs themselves, or from the rest of the codebase. You can try to update the specs or ask for major refactors, but that often introduces new issues. And as the context grows, the chances of producing working code diminish significantly. The only way forward at that point is to dive in yourself, reviewing, fixing, and refactoring the traditional way, and wondering whether this workflow has really made you any more productive.
I have found putting the spec together with a model, having it to try find blindspots and write done the final take in clear and concise language, useful.
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 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
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.
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.
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.
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.
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.
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"
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'm probably not explaining this well, but I feel like writing code from scratch has the effect of making us slow down and think more deeply and more globally about what we're writing. Reading vibe code "localizes" our attention to the correctness of the code produced and clogging the processes that otherwise think about connection of this code to other parts of the system.
The day people stop inventing stuff like that and they put the same effort in do really good, quality code... That day, we might start having decent software and not Electron or React apps everywhere...
God bless old times when programmers cared about quality rather than stuff like this... "vive coding"... My God...
38 comments
[ 6.2 ms ] story [ 75.5 ms ] threadBetween selling more bedrock usage or cutting their own headcount.
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
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.
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.
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.
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.
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.
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.
1. Don't.
2. Don't do it.
3. Seriously, don't.
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.
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.
God bless old times when programmers cared about quality rather than stuff like this... "vive coding"... My God...