This illusion that senior engineers are too good to fall in all the traps laid by vibe coding really needs to stop.
Just yesterday I was reading the comment of a Principal Engineer saying "of course vibe coding carries a huge risk for more junior engineers that don't understand when the LLM does something that looks right but is actually wrong", as if just because they have more experience THEY CAN.
No, you can't either. Not a single soul on this planet can review the thousands of lines of vibe coded bullshit that LLMs spit out.
Here's my guide to Gen AI / LLM Vibecoding for Expert Programmers: don't.
> Vibe coding is useful only if you have enough problems that you’re happy that some subset [is] being solved, not caring what in that subset is solved.
generic advice about how you should use the same tool and methodology (claude code, scrum) that everyone’s already using, lot of hand waving about being “senior,” This may be the most 2025 blog post ever written.
if anyone takes the art of software programming further using LLMs, it’s going to be young inexperienced people who grow up closely observing and learning the transcendental nature of LLMs and software, not hardened industry titans joyfully cracking their whip over an army of junior devs and LLMs.
I think the article could be more accurately titled "A Guide to Gen AI / LLM Vibecoding for Programmers who hate their job"
To me, someone who actually love programming, it makes vibe coding look like hell.
> The workflow of vibe coding is the same as managing scrums or helping a student through a research thesis
Which programmer wants that?! Just hearing the word "scrum" makes me want to run away and I know I am not alone here. Helping a student through a research thesis doesn't sound so bad, because as a human, helping people feels good. But here, there is no student, no human feelings, and you are not even helping the AI become better in the long term.
It's hardly original, but my take is that vibe coding works brilliantly for personal projects (or potentially for tiny startups that need to rapidly churn out CRUD boilerplate, API integrations, etc), but terribly for most large commercial systems.
I'm having fun with Claude Code and Vibe Kanban on personal projects, and before that I spent a lot of time with both the Windsurf and Cursor agents. It's making me literally 10x more productive on personal projects, maybe even 50x.
On personal projects:
- no-one but me needs to decide on requirements
- no-one but me needs to make decisions
- no-one but me needs to maintain the code going forward
- much of the time I'm intentionally using languages and frameworks that I am somewhat clueless about, and an LLM providing continuous ideas (even if sometimes entirely silly ones) stops me getting stuck
- I don't mind if there are large chunks of useless or half-working code
On commercial projects:
- every line of code is a massive liability. Every line needs to be reviewed by another engineer, and every developer who joins the project needs to be aware of it, take it into consideration when making changes elsewhere, and potentially debug it if something goes wrong
- senior engineers are almost always hired to work with languages and technologies they are already very familiar with, meaning for many tasks it's often quicker to write out the code by hand (or perhaps with Cursor's auto-complete) than guide an LLM to do it
- much of the time is spent in meetings trying to unearth the real product requirements or providing updates to stakeholders
- much of the time is spent reading old code and working out how to implement things in extremely large and complex systems in a minimally disruptive way
- a lot of time is spent reviewing other people's PRs, and getting infuriated when people (often either very junior or very senior) produce 1000 line PRs consisting of unnecessary changes, excessive boilerplate, half-finished experiments, and things that clearly haven't been tested properly. This was the case long before LLMs, AI just makes it ever more tempting for people to act this way.
- trying to avoid or gently negotiate political games over who is in control of the project, or who gets to makes technical decisions
> For the record, I now have about 32 Claude agents continuously running in tmux windows that I can ssh to, so all day long I can just check via laptop or phone and keep plugging along.
This piece is excellent - it's full of ideas and tips that I have not seen in other similar tutorials. Worth spending some time with, especially if you are still skeptical of the value that can be unlocked by AI-assisted programming.
(A minor disagreement: it's using a definition of "vibe coding" that applies to any form of ai-assisted programming. I prefer to define vibe coding with its original definition from all the way back in February where it only refers to code that is generated through prompting without any review.)
I use LLMs, just like i use Google and other things but I don't vibe code as defined like the original meaning and I feel that all these people who are trying to tell me how good they are with it are yet to explain how on earth code is the most complex thing.
Coding is the easy part. Knowing what to code, how to work with people, how to interact with the real world and with chaos, with bad data, with poor integrations, and entropy.
I'm all for making AI and coding better and helping people do that and think.
I'm not impressed by anyone who doesn't show me they can think about the problems we face better and faster, and keep doing it without slowing down to a halt or making it someone's else's problem.
Everyone else is just talking themselves up or selling something, neither of which are useful to me.
My recent vibe code experience made me realize it's almost exactly like being a tech lead managing offshore development. I learned early on that the key to leading successful offshore projects is precise, detailed specifications, and very rigorous code review and testing. Now I'm using the exact same discipline to "vibe" code. I really think there needs to be a different term for professional solution engineering using LLMs (like "prompt engineering" but for coding) to differentiate from casual prototyping or simple web UI hacking by non-devs that uses "vibe" coding.
> The moment you see it go off the rails, just throw it out. That problem is too hard for Claude, it’s for you now.
Or, any of:
- the problem was too big in scope and needed a stepped plan to refer to and execute step by step
- your instructions weren't clear enough
- the context you provided was missing something crucial it couldn't find agentically, or build knowledge of (in which case, document that part of the codebase first)
- your rules/AGENTS.md/CLAUDE.md needs some additions or tweaking
- you may need a more powerful model to plan implementation first
Just throwing away and moving on is often the wrong choice and you'll get better at using these tools slower. If you're still within the "time it would have taken me to do it myself" window, think about what caused it to go off the rails or fail spectacularly and try giving it another go (not following up, throw away current results and chat and try again with the above in mind)
I've just spent the better part of two weeks trying to convince a LLM to automate some programming for me.
We use feature flags. However, cleaning them up is something rarely done. It typically takes me ~3minutes to clean one up.
To clean up the flag:
1) delete the test where the flag is off
2) delete all the code setting the flag to on
3) anything getting the value of the flag is set to true
4) resolve all "true" expressions, cleaning up if's and now constant parameters.
5) prep a pull request and send it for review
This is all fully supported by the indexing and refactoring tooling in my IDE.
However, when I prompted the LLM with those steps (and examples), it failed. Over and over again. It would delete tests where the value was true, forget to resolve the expressions, and try to run grep/find across a ginormous codebase.
If this was an intern, I would only have to correct them once. I would correct the LLM, and then it would make a different mistake. It wouldn't follow the instructions, and it would use tools I told it to not use.
It took 5-10 minutes to make the change, and then would require me to spend a couple of minutes fixing things. It was at the point of not saving me any time.
I've got a TONNE of low-hanging fruit that I can't give to an intern, but could easily sick a tool as capable as an intern on. This was not that.
The author's 200 GitHub packages not withstanding, the startups he is involved in are both founded on machine learning, so I don't consider him unbiased.
It is always the founder type who is trying to peddle fantasies like this:
Vibe coding turns any individual into the CTO leading a team of 20, 30, 50, 60 interns.
How much does his new hobby cost?
On my $200/month Claude 20x Max subscription I used enough tokens for about $5,200 of compute in the first month. This is obviously not sustainable, but hey, it’s a startup world and VCs are paying for it right now.
Let’s just call it like it is, Vibe coding takes away the thinking of the execution of steps to solve the problem and offloads that part of our mind to a text generator with intelligent emergent properties. If you enjoy keeping the intelligence sharp for laying out the steps to solve the problem and executing the steps then don’t vibe code. If you don’t mind the engineering skills atrophy then go ahead and vibe code. But know this. You will lose the skills.
This appears to me to be a surprisingly low-effort article. Nothing about managing context length and starting tasks from a good context, managing .md files and structuring repos, very anthropomorphising which does not help, nothing about tools to use to build the right context, no comparison of different approaches, what kind of MCP and/or RAG to get agents to look at documentation.
I think the idea that it's important to know how to code is going to be seriously challenged. I know I feel like the learning process and insight I gain is important, but I wonder if it is, beyond the subjective.
Like I'm sure the grad students working for Euler learned a ton generating logarithmic tables by hand, but it proved to be useless in the end. Could having a solid grasp on memory management/access in C be the same?
I think this is why obsolescence can be hard to predict.
Like if in 30 years all code is run and managed by ai bots, then all this debate about "it's important to know how to code!" will seem really silly.
> Could having a solid grasp on memory management/access in C be the same?
Perhaps not when the code is getting written (by yourself or by an AI).
When you're dealing with a memory leak in production (yes, they can and do happen), or worse -- if you're dealing with a drop in performance -- good luck with the vibe debugging.
Maybe there will be a time not too far off in the future when the stochastic cockatoos become sentient enough to do all of this by themselves, it's sure as hell not happening tomorrow.
Oh, and logarithmic tables were still a useful thing as late as forty odd years ago :)
I like programming. It's fun, and sometimes it even requires creativity. There are plenty of times when it's not that fun, and doesn't require any creativity (because whatever it is has been done by someone else a thousand times over), and you just want a result. Vibecoding is great for _that_ stuff (think little throw-away scripts, shell one liners, tool plugins, etc)
I generally don't get great results from LLM code because most of my work is in C++ (which I'm guessing is underrepresented in the training data?), but when I point it towards some well-worn javascript thing I've had real successes! Most recent example is this little chrome plugin I had it whip up in one shot (https://chromewebstore.google.com/detail/favicon-tab-grouper...) because I couldn't find the exact functionality I needed in other plugins.
Works perfectly for my needs, took less than five minutes to spin up, and I use it all the time. If you're looking to get started with vibecoding stuff, try making plugins that provide niche functionality for your hyper-specific workflows.
After 25 years in embedded, embedded Linux, devops and cloud security I don’t care about coding anymore. I’ve done almost everything in so many programming languages and assembly that I can’t even count. Every programming task seems like a repetitive task.
But architecture and solving a real problem wow, this still kicks in me. So, LLMs are my pals that we spend so much time in planning and go to every single small detail and in such depth that it’s hard to explain the mental erection. Just give it a prompt to try to contradict every step and make it hard for you and try to convince it that it’s wrong. I can spend hours just building the plan and the idea. Then I have the solution and it’s just boring to write the code. I know I can write the code and I’ve already done it before. So, I just create a full plan with specs and a water flow to do list and let it do the job. I check if it does it right and keep it on track not to over engineer things (they tend to do that a lot) and just enjoy the outcome. I would say I do vibe-planning before vibe-coding.
23 comments
[ 3.9 ms ] story [ 42.5 ms ] threadJust yesterday I was reading the comment of a Principal Engineer saying "of course vibe coding carries a huge risk for more junior engineers that don't understand when the LLM does something that looks right but is actually wrong", as if just because they have more experience THEY CAN.
No, you can't either. Not a single soul on this planet can review the thousands of lines of vibe coded bullshit that LLMs spit out.
Here's my guide to Gen AI / LLM Vibecoding for Expert Programmers: don't.
if anyone takes the art of software programming further using LLMs, it’s going to be young inexperienced people who grow up closely observing and learning the transcendental nature of LLMs and software, not hardened industry titans joyfully cracking their whip over an army of junior devs and LLMs.
Play with it — that’s the only way anyone masters anything.
Separate yourself from the results, be prepared to waste time, but try and have some fun and keep your eyes open.
To me, someone who actually love programming, it makes vibe coding look like hell.
> The workflow of vibe coding is the same as managing scrums or helping a student through a research thesis
Which programmer wants that?! Just hearing the word "scrum" makes me want to run away and I know I am not alone here. Helping a student through a research thesis doesn't sound so bad, because as a human, helping people feels good. But here, there is no student, no human feelings, and you are not even helping the AI become better in the long term.
I'm having fun with Claude Code and Vibe Kanban on personal projects, and before that I spent a lot of time with both the Windsurf and Cursor agents. It's making me literally 10x more productive on personal projects, maybe even 50x.
On personal projects:
- no-one but me needs to decide on requirements
- no-one but me needs to make decisions
- no-one but me needs to maintain the code going forward
- much of the time I'm intentionally using languages and frameworks that I am somewhat clueless about, and an LLM providing continuous ideas (even if sometimes entirely silly ones) stops me getting stuck
- I don't mind if there are large chunks of useless or half-working code
On commercial projects:
- every line of code is a massive liability. Every line needs to be reviewed by another engineer, and every developer who joins the project needs to be aware of it, take it into consideration when making changes elsewhere, and potentially debug it if something goes wrong
- senior engineers are almost always hired to work with languages and technologies they are already very familiar with, meaning for many tasks it's often quicker to write out the code by hand (or perhaps with Cursor's auto-complete) than guide an LLM to do it
- much of the time is spent in meetings trying to unearth the real product requirements or providing updates to stakeholders
- much of the time is spent reading old code and working out how to implement things in extremely large and complex systems in a minimally disruptive way
- a lot of time is spent reviewing other people's PRs, and getting infuriated when people (often either very junior or very senior) produce 1000 line PRs consisting of unnecessary changes, excessive boilerplate, half-finished experiments, and things that clearly haven't been tested properly. This was the case long before LLMs, AI just makes it ever more tempting for people to act this way.
- trying to avoid or gently negotiate political games over who is in control of the project, or who gets to makes technical decisions
What's the cost of 32Cph?
(A minor disagreement: it's using a definition of "vibe coding" that applies to any form of ai-assisted programming. I prefer to define vibe coding with its original definition from all the way back in February where it only refers to code that is generated through prompting without any review.)
Coding is the easy part. Knowing what to code, how to work with people, how to interact with the real world and with chaos, with bad data, with poor integrations, and entropy.
I'm all for making AI and coding better and helping people do that and think.
I'm not impressed by anyone who doesn't show me they can think about the problems we face better and faster, and keep doing it without slowing down to a halt or making it someone's else's problem.
Everyone else is just talking themselves up or selling something, neither of which are useful to me.
Or, any of:
- the problem was too big in scope and needed a stepped plan to refer to and execute step by step
- your instructions weren't clear enough
- the context you provided was missing something crucial it couldn't find agentically, or build knowledge of (in which case, document that part of the codebase first)
- your rules/AGENTS.md/CLAUDE.md needs some additions or tweaking
- you may need a more powerful model to plan implementation first
Just throwing away and moving on is often the wrong choice and you'll get better at using these tools slower. If you're still within the "time it would have taken me to do it myself" window, think about what caused it to go off the rails or fail spectacularly and try giving it another go (not following up, throw away current results and chat and try again with the above in mind)
We use feature flags. However, cleaning them up is something rarely done. It typically takes me ~3minutes to clean one up.
To clean up the flag:
1) delete the test where the flag is off
2) delete all the code setting the flag to on
3) anything getting the value of the flag is set to true
4) resolve all "true" expressions, cleaning up if's and now constant parameters.
5) prep a pull request and send it for review
This is all fully supported by the indexing and refactoring tooling in my IDE.
However, when I prompted the LLM with those steps (and examples), it failed. Over and over again. It would delete tests where the value was true, forget to resolve the expressions, and try to run grep/find across a ginormous codebase.
If this was an intern, I would only have to correct them once. I would correct the LLM, and then it would make a different mistake. It wouldn't follow the instructions, and it would use tools I told it to not use.
It took 5-10 minutes to make the change, and then would require me to spend a couple of minutes fixing things. It was at the point of not saving me any time.
I've got a TONNE of low-hanging fruit that I can't give to an intern, but could easily sick a tool as capable as an intern on. This was not that.
It is always the founder type who is trying to peddle fantasies like this:
Vibe coding turns any individual into the CTO leading a team of 20, 30, 50, 60 interns.
How much does his new hobby cost?
On my $200/month Claude 20x Max subscription I used enough tokens for about $5,200 of compute in the first month. This is obviously not sustainable, but hey, it’s a startup world and VCs are paying for it right now.
Like I'm sure the grad students working for Euler learned a ton generating logarithmic tables by hand, but it proved to be useless in the end. Could having a solid grasp on memory management/access in C be the same?
I think this is why obsolescence can be hard to predict.
Like if in 30 years all code is run and managed by ai bots, then all this debate about "it's important to know how to code!" will seem really silly.
Perhaps not when the code is getting written (by yourself or by an AI).
When you're dealing with a memory leak in production (yes, they can and do happen), or worse -- if you're dealing with a drop in performance -- good luck with the vibe debugging.
Maybe there will be a time not too far off in the future when the stochastic cockatoos become sentient enough to do all of this by themselves, it's sure as hell not happening tomorrow.
Oh, and logarithmic tables were still a useful thing as late as forty odd years ago :)
I generally don't get great results from LLM code because most of my work is in C++ (which I'm guessing is underrepresented in the training data?), but when I point it towards some well-worn javascript thing I've had real successes! Most recent example is this little chrome plugin I had it whip up in one shot (https://chromewebstore.google.com/detail/favicon-tab-grouper...) because I couldn't find the exact functionality I needed in other plugins.
Works perfectly for my needs, took less than five minutes to spin up, and I use it all the time. If you're looking to get started with vibecoding stuff, try making plugins that provide niche functionality for your hyper-specific workflows.