Sometimes I read something on the internet and I think: finally someone has articulated something the way that I think about it. And it is very validating. And it cuts through a bunch of noise about how "oh you should be tuning and tweaking this prompt and that" and really speaks to the human experience. Thanks for this.
> After about 3-4k lines of code I completely lost track of what is going on... Overall I would say it was a horrible experience, even though it took 10 hours to write close to 10000 lines of code
It's hard to take very much away from somebody else's experiences in this area. Because if you've been doing a substantial amount of AI coding this year, you know that the experience is highly dependent on your approach.
How do you structure your prompts? How much planning do you do? How do you do that planning? How much review do you do, and how do you do it? Just how hands-on or hands-off are you? What's in your AGENTS.md or equivalent? What other context do you include, when, why, and how? What's your approach to testing, if any? Do you break down big projects into smaller chunks, and if so, how? How fast vs slow are you going, i.e. how many lines of code are you letting the AI write in any given time period? Etc.
The answers to these questions vary extremely wildly from person to person.
But I suspect a ton of developers who are having terrible experiences with AI coding are quite new to it, have minimal systems in place, and are trying "vibe coding" in the original sense of the phrase, which is to rapidly prompt the LLM with minimal guidance and blindly trust its code. In which case, yeah, that's not going to give you great results.
I think you're making a fair comment, but it still irks me that you're quite light on details on what the "correct" approach is supposed to be, and it irks me also because it seems to now be a pattern in the discussion.
Someone gives a detailed-ish account of what they did, and that it didn't work for them, and then there are always people in the comments saying that you were doing it wrong. Fair! But at this point, I haven't seen any good posts here on how to do it _right_.
Has the definition of "vibe coding" changed to represent all LLM-assisted coding? Because from how I understand it, what you're talking about is not "vibe coding."
Still waiting to see that large, impressive, complex, open-source project that was created through vibe coding / vibe engineering / whatever gimmicky phrase they come up with next!
I suspect you've gotten lucky. I do a lot of planning and prompt editing and have plenty of outrageous failures that don't make any sense given the context.
> How do you structure your prompts? How much planning do you do? How do you do that planning? How much review do you do, and how do you do it? Just how hands-on or hands-off are you? What's in your AGENTS.md or equivalent? What other context do you include, when, why, and how? What's your approach to testing, if any? Do you break down big projects into smaller chunks, and if so, how? How fast vs slow are you going, i.e. how many lines of code are you letting the AI write in any given time period? Etc.
It wouldn't be vibe coding if one did all that ;-)
The whole point of vibe coding is letting the LLM run loose, with minimal checks on quality.
Original definition (paraphrased):
"Vibe coding describes a chatbot-based approach to creating software where the developer describes a project or task to a large language model (LLM), which generates code based on the prompt. The developer does not review or edit the code, but solely uses tools and execution results to evaluate it and asks the LLM for improvements. Unlike traditional AI-assisted coding or pair programming, the human developer avoids examination of the code, accepts AI-suggested completions without human review, and focuses more on iterative experimentation than code correctness or structure."
OK. I guess strictly speaking, you could do most of what you're suggesting and still call it vibe coding.
I used agentic LLM dev tools to build the core of my webapp. It took months, I had a QA person at the beginning, and I looked at every line of committed code. It was a revelatory experience and resulted in a very reliable webapp.
Last month I thought: "OK, I have all kinds of rules, guardrails, and I am relatively excellent at managing context. Let's try to 'vibe code' some new features."
It has been a total disaster and worse than a waste of time. I keep finding entirely new weird bugs it created. This is just a React/Vite/Supabase app, nothing nuts. The worst part is that I showed these vibed features to stakeholders, and they loved it. Now I have to explain why recreating these features is going to take much longer.
I knew better, as the magic of vibe coding is to explore the MVP space, and I still fell for it.
> After about 3-4k lines of code I completely lost track of what is going on, and I woudn't consider this code that I have written, but adding more and more tests felt "nice", or at least reassuring.
> There was a some gaslighting, particularly when it misunderstood dap_read_mem32 thinking it is reading from ram and not MEM-AP TAR/DRW/RDBUFF protocol, which lead to incredible amount of nonsense.
> Overall I would say it was a horrible experience, even though it took 10 hours to write close to 10000 lines of code, I don't consider this my project, and I have no sense of acomplishment or growth.
Ah yes, we can now mass produce faulty code, we feel even more alienated from our work, the sense of achievement gets taken away, no ownership, barely any skill growth. Wonderful technology. What a time to bring value to the shareholders!
Vibe coding in the sense of handing all responsibility and accountability for the code in a change request over to AI and then claiming the bad code is the fault of AI is not a thing. It's still your change request regardless of how you created it. If you write every line it's yours. If you copy it from SO into your editor and committed it, that's your choices, and therefore your code. If you prompted an LLM to write something, you are responsible for that.
If there is AI slop in your codebase it is only because you put it there.
Pretty much my experience, LLMs have taken the fun out of programming for me. My coding sessions are:
1. write prompt
2. slack a few minutes
3. go to 1
4. send code for review
I know what the code is doing, how I want it to look eventually, and my commits are small and self-contained, but I don't understand my code as much because I didn't spend so much time manipulate it. Often I spend more time in my loops than if I was writing the code myself.
I'm sure that with the right discipline, it's possible to tame the LLM, but I've not been able to reach that stage yet.
I’ve stopped getting LLM to code and use it to spitball ideas, solutions etc to the issue.
This lets you get a solution plan done, with all the files and then you get to write the code.
Where I do let it code is in tests.
I write a first “good” passing test then ask it to create all the others bad input etc. saves a bunch of time and it can copy and paste faster then I can.
At a minimum I write my own automated tests for LLM code (including browser automation) and think them through carefully. That always exposes some limitations to Claude's solutions, discovers errors, and lets you revisit it so you fully understand what you're generating.
Mostly LLMs do the first pass and I rewrite a lot of it with a much better higher level systems approach and "will the other devs on the team understand / reuse this".
I'd still prefer deciphering a lot of default overly-verbose LLM code to some of the crazy stuff that past devs have created by trying to be clever.
Have you tried Composer 1 from Cursor? It enables a totally different way of AI coding - instead of giving the LLM a long prompt and waiting minutes for it to finish, you give it a shorter prompt to just write one small thing and it finishes in seconds. There’s no interruption, you stay in the flow, and in control of what you’re building.
Why are you doing it? Direction from management? You think it's better code even though it's as you say less fun, and you're not sure if faster or not? Other?
I have felt similiar thoughts. You start off with a mental model of how to develop an app based on experience. You can quickly get the pieces working and wire them up.
What get's lost is when you normally develop an app that takes days you create a mind model as you go along that you take with you throughout the day. In the shower you may connect some dots and reimagine the pieces in a more compelling way. When the project is done you have mental model of all of the different pieces; thoughts of where to expand and fears of where you know the project will bottleneck with a mental note to circle back when you can.
When you vibe code you don't get the same highs and lows. You don't mentally map each piece. It's not a surprise that opening up and reading the code is the most painful thing but reading my own code is always a joy.
This reflects my XP as well: use LLMs for semantic search. Do not trust it with your code.
> Overall I would say it was a horrible experience, even though it took 10 hours to write close to 10000 lines of code, I don't consider this my project, and I have no sense of acomplishment or growth.
> In contrast, using AI to read all the docs (which are thousands of pages) and write helpful scripts to decode the oscilloscope data, create packed C structs from docs and etc, was very nice, and I did feel good after.
Suppose it was 10,000 lines of solid code. That would still require of dozens of PRs to be digestible, and the attendant time to review. Our attention is the bottleneck now.
What Í'm doing a lot is vibe coding and stashing. Not even a public branch, just git stash the whole thing the LLM writes.
Also, I stack the stash. When I vibe code, I pop it, let it work on its own mess, then I stash it again.
One project has almost 13.000 lines of vibe mess, all stashed.
One good thing, is that the stash builds. It's just that I don't want to release more code than I can read. It's a long review queue that is pre-merged somehow.
Once in a while I pick something from there, then I review it and integrate into the codebase more seriously. I don't have the throughput to review it all, and not all projects can be yolo'd.
It's to be expected that HN would have a contrarian take but I find it ironic that the amount of criticism toward technological innovation in an industry that is rooted fundamentally in technological innovation is so common.
This is reassuring. I started vime coding a side project and quickly got repulsed by the feeling of disconnection and lack of ownership. I put it on the shelf for a bit then came back and started over, writing all the code myself (but with a bit of VS Code autocomplete and a lot of assistance from ChatGPT). Super satisfying.
I feel with people that say that "AI have take the fun out of programming" for them, but at the same time I think to myself: is it about doing, or is it about getting things done? Like I imagine someone in the past loved their job walking each night through their city, lighting up the gas-powered street lights. And then one day someone else implemented electric street lights, and the first person lost the job they loved. But in the end, its about providing light to the city streets, no?
For the great majority of work, it is not about fun, but about doing something other people need or want.
For me, AI allows me to realize my ideas, and get things done. Some of it might be good, some of it might be bad. I put at least as much time, attention and effort as the "real" programmers do, but my time goes into thinking and precisely defining what I want, cutting it up into smaller logical modules, testing, identifying and fixing bugs, iterating all the time.
AI Coding has the same problem as "self driving cars".
Until the car can be completely trusted to drive itself and never need human intervention, the human has to stay in a weird state of not driving the car, but being completely alert and attentive and ready to resume control in an instant. This can be more tiring and stressful than just driving yourself.
Vibe coding is very similar. The AI can generate code at an astounding rate. But all of it has to be examined carefully for strange errors that a human would be very unlikely to make.
In both cases, it's very questionable whether there is significant savings in the time or attention of the human still in the loop vs just performing the activity completely by herself.
Daniel Pink's book "Drive" explains that true motivation comes from intrinsic factors: autonomy, mastery, and purpose. It’s not about external rewards or doing every task yourself, but about having the freedom to direct your work, the drive to improve your skills, and a meaningful purpose behind what you do. In programming, AI can free us from routine tasks, letting us focus on creative problem-solving and realizing our ideas - this aligns perfectly with what Pink calls the deeper, more fulfilling motivation to get things done in a way that matters. So, it’s less about losing fun and more about shifting to meaningful engagement and impact.
While I agree with your point that it's sometimes about getting things done, but your example is flawed. Your example about gas-powered street lights is arguing for technology evolution. But the people who say "AI have take the fun out of programming" are fighting for craftsmanship and love.
Nobody ever found craftsmanship or pleasure out of lighting up gas-powered street lights. But there are a lot of programmers that value "doing" programming because it's their craft or art-form.
I have never had a programming job. But I program all day to serve my customers for the products I created. Because it's my art-form. I love "doing" it (my way!).
It will get done. I just want to be the person to do it.
Given the code has been completely vibe-coded, what does this mean in practice?:
> Copyright (c) 2025
Whose copyright? IIRC, it is consensus that AI cannot create copyrightable works. If the author does not own the copyright, can they add a legally binding license? If not, does this have any legal meaning?:
> IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
A key -- perhaps THE key -- remark here, IMO is the following:
> I do want to make things, and many times I dont want to know something, but I want to use it
This confesses the desire to make, to use, and to make use of, without ANY substantive understanding.
Of course this seems attractive for some reasons, but it is a wrong, degenerative way to be in the world. Thinking and being belong together. Knowing and using are two dimensions of the same activity.
The way of these tools is a making without understanding, a using without learning, a way of being that is thoughtless.
There's nothing preventing us from thoughtful, rigorous, enriching use of generative ML, except that the systems we live and work in don't want us to be thoughtful and enriched and rigorous. They want us pliant and reactive and automated and sloppy.
This is very well said. I thought I was just burned out over the past several months. Truth is, I'm just reviewing AI code slop all day and I fucking hate it. It's exhausting.
I don't get it. Any time I step into a human-dev project, I feel exactly the same. Whenever a program gets large enough to be useful, it's too complex for anyone to understand without putting some work into it.
I think that the important conclusion to make of this is that publicly available code is not created or even curated by humans anymore, and it will be fed back into data sets for training.
It's not clear what the consequences are. Maybe not much, but there's not that much actual emergent intelligence in LLMs, so without culling by running the code there's seems to be a risk that the end result is a world full of even more nonsense than today.
This already happened a couple of years ago for research on word frequency in published texts. I think the consensus is that there's no point in collecting anymore since all available material is tainted by machine generated content and doesn't reflect human communication.
I resonate with what the author said about losing track of the Mental Model. I think that's the key to enjoying the process or not. I.e. the building up or utilising of that mental model (my own understanding) is they key to finding software development joyful.
Specifically:
"Easy but boring project" case:
For projects where I am already familiar with a strong and sensible architecture then I find AI enjoyable to work with as a simple speed boost. I know exactly what I'm asking AI to do at every stage and can judge it's results well. It's not that interesting to me to code these components myself because I've done it before several times. My mental model of the problem space and a good solution is complete. I get some satisfaction from using my mental model.
"Challenging but interesting project" case:
For projects where I don't yet understand the best architecture then I will inevitably ask AI to connect Component A to Component B without yet understanding that there should be a Component C. Because I don't have the understanding of the problem space. The thing is before AI I may have made this mistake myself, I just would have had the satisfaction of learning at the same time.
Given the time with these type of projects I basically write them twice: First pass making it work but as a huge mess, but building a mental model of the real problem space along the way. Second pass refactoring and getting it right, creating now a mental model of a good solution. Only after two passes would it be a project I would feel is done correctly and be happy (joyful) to publish it.
I have found AI enables you to get the first pass working much quicker, but without the learning along the way of the mental model to inform how to make the second pass properly. So If I want the challenging project to be joyful I still need to invest the time to learn from the first pass.
And that specific learning task I enjoy more if I do it iteratively as the AI and I build together, it's less enjoyable if I sit down afterwards and only inspect the code.
SO if I want a challenging project to be joyful I have to continue investing the time in the first phase to do the learning. AI just gives the opportuntity to produce a messy working prototype without learning anything, which may or may not make sense for the business side of things.
79 comments
[ 978 ms ] story [ 2209 ms ] threadIt's hard to take very much away from somebody else's experiences in this area. Because if you've been doing a substantial amount of AI coding this year, you know that the experience is highly dependent on your approach.
How do you structure your prompts? How much planning do you do? How do you do that planning? How much review do you do, and how do you do it? Just how hands-on or hands-off are you? What's in your AGENTS.md or equivalent? What other context do you include, when, why, and how? What's your approach to testing, if any? Do you break down big projects into smaller chunks, and if so, how? How fast vs slow are you going, i.e. how many lines of code are you letting the AI write in any given time period? Etc.
The answers to these questions vary extremely wildly from person to person.
But I suspect a ton of developers who are having terrible experiences with AI coding are quite new to it, have minimal systems in place, and are trying "vibe coding" in the original sense of the phrase, which is to rapidly prompt the LLM with minimal guidance and blindly trust its code. In which case, yeah, that's not going to give you great results.
Since vibe coding is so chaotic, rigorous planning is required, which not every developer had to do before.
You could simply "vibe" code yourself, roam, explore, fix.
Is that a fair description of your comment?
Someone gives a detailed-ish account of what they did, and that it didn't work for them, and then there are always people in the comments saying that you were doing it wrong. Fair! But at this point, I haven't seen any good posts here on how to do it _right_.
I remember this post which got a lot of traction: https://steipete.me/posts/just-talk-to-it 8 agents in parallel and so on, but light on the details.
It wouldn't be vibe coding if one did all that ;-)
The whole point of vibe coding is letting the LLM run loose, with minimal checks on quality.
Original definition (paraphrased):
"Vibe coding describes a chatbot-based approach to creating software where the developer describes a project or task to a large language model (LLM), which generates code based on the prompt. The developer does not review or edit the code, but solely uses tools and execution results to evaluate it and asks the LLM for improvements. Unlike traditional AI-assisted coding or pair programming, the human developer avoids examination of the code, accepts AI-suggested completions without human review, and focuses more on iterative experimentation than code correctness or structure."
OK. I guess strictly speaking, you could do most of what you're suggesting and still call it vibe coding.
Last month I thought: "OK, I have all kinds of rules, guardrails, and I am relatively excellent at managing context. Let's try to 'vibe code' some new features."
It has been a total disaster and worse than a waste of time. I keep finding entirely new weird bugs it created. This is just a React/Vite/Supabase app, nothing nuts. The worst part is that I showed these vibed features to stakeholders, and they loved it. Now I have to explain why recreating these features is going to take much longer.
I knew better, as the magic of vibe coding is to explore the MVP space, and I still fell for it.
All the way from 1844.
> There was a some gaslighting, particularly when it misunderstood dap_read_mem32 thinking it is reading from ram and not MEM-AP TAR/DRW/RDBUFF protocol, which lead to incredible amount of nonsense.
> Overall I would say it was a horrible experience, even though it took 10 hours to write close to 10000 lines of code, I don't consider this my project, and I have no sense of acomplishment or growth.
Ah yes, we can now mass produce faulty code, we feel even more alienated from our work, the sense of achievement gets taken away, no ownership, barely any skill growth. Wonderful technology. What a time to bring value to the shareholders!
No.
Vibe coding in the sense of handing all responsibility and accountability for the code in a change request over to AI and then claiming the bad code is the fault of AI is not a thing. It's still your change request regardless of how you created it. If you write every line it's yours. If you copy it from SO into your editor and committed it, that's your choices, and therefore your code. If you prompted an LLM to write something, you are responsible for that.
If there is AI slop in your codebase it is only because you put it there.
Nailed it, came here to say this.
If anything, this entire post should just be titled "AI PEBKAC".
Don't blame the tool because you're using it wrong.
1. write prompt
2. slack a few minutes
3. go to 1
4. send code for review
I know what the code is doing, how I want it to look eventually, and my commits are small and self-contained, but I don't understand my code as much because I didn't spend so much time manipulate it. Often I spend more time in my loops than if I was writing the code myself.
I'm sure that with the right discipline, it's possible to tame the LLM, but I've not been able to reach that stage yet.
This lets you get a solution plan done, with all the files and then you get to write the code.
Where I do let it code is in tests.
I write a first “good” passing test then ask it to create all the others bad input etc. saves a bunch of time and it can copy and paste faster then I can.
Mostly LLMs do the first pass and I rewrite a lot of it with a much better higher level systems approach and "will the other devs on the team understand / reuse this".
I'd still prefer deciphering a lot of default overly-verbose LLM code to some of the crazy stuff that past devs have created by trying to be clever.
What get's lost is when you normally develop an app that takes days you create a mind model as you go along that you take with you throughout the day. In the shower you may connect some dots and reimagine the pieces in a more compelling way. When the project is done you have mental model of all of the different pieces; thoughts of where to expand and fears of where you know the project will bottleneck with a mental note to circle back when you can.
When you vibe code you don't get the same highs and lows. You don't mentally map each piece. It's not a surprise that opening up and reading the code is the most painful thing but reading my own code is always a joy.
> Overall I would say it was a horrible experience, even though it took 10 hours to write close to 10000 lines of code, I don't consider this my project, and I have no sense of acomplishment or growth.
> In contrast, using AI to read all the docs (which are thousands of pages) and write helpful scripts to decode the oscilloscope data, create packed C structs from docs and etc, was very nice, and I did feel good after.
Also, I stack the stash. When I vibe code, I pop it, let it work on its own mess, then I stash it again.
One project has almost 13.000 lines of vibe mess, all stashed.
One good thing, is that the stash builds. It's just that I don't want to release more code than I can read. It's a long review queue that is pre-merged somehow.
Once in a while I pick something from there, then I review it and integrate into the codebase more seriously. I don't have the throughput to review it all, and not all projects can be yolo'd.
Until the car can be completely trusted to drive itself and never need human intervention, the human has to stay in a weird state of not driving the car, but being completely alert and attentive and ready to resume control in an instant. This can be more tiring and stressful than just driving yourself.
Vibe coding is very similar. The AI can generate code at an astounding rate. But all of it has to be examined carefully for strange errors that a human would be very unlikely to make.
In both cases, it's very questionable whether there is significant savings in the time or attention of the human still in the loop vs just performing the activity completely by herself.
Nobody ever found craftsmanship or pleasure out of lighting up gas-powered street lights. But there are a lot of programmers that value "doing" programming because it's their craft or art-form.
I have never had a programming job. But I program all day to serve my customers for the products I created. Because it's my art-form. I love "doing" it (my way!).
It will get done. I just want to be the person to do it.
> Copyright (c) 2025
Whose copyright? IIRC, it is consensus that AI cannot create copyrightable works. If the author does not own the copyright, can they add a legally binding license? If not, does this have any legal meaning?:
> IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
full stop here, there is nothing you can write after this…
> I do want to make things, and many times I dont want to know something, but I want to use it
This confesses the desire to make, to use, and to make use of, without ANY substantive understanding.
Of course this seems attractive for some reasons, but it is a wrong, degenerative way to be in the world. Thinking and being belong together. Knowing and using are two dimensions of the same activity.
The way of these tools is a making without understanding, a using without learning, a way of being that is thoughtless.
There's nothing preventing us from thoughtful, rigorous, enriching use of generative ML, except that the systems we live and work in don't want us to be thoughtful and enriched and rigorous. They want us pliant and reactive and automated and sloppy.
We don't have to bend to their wants tho.
It's like spaghetti code only existed after 2022.
It's not clear what the consequences are. Maybe not much, but there's not that much actual emergent intelligence in LLMs, so without culling by running the code there's seems to be a risk that the end result is a world full of even more nonsense than today.
This already happened a couple of years ago for research on word frequency in published texts. I think the consensus is that there's no point in collecting anymore since all available material is tainted by machine generated content and doesn't reflect human communication.
you need to
plan, build guards, provide scope and desirables and test, retest, xref everything.
the machine codes, then stops and checks the rules, backtests and then continues.
as with all progression, structure matters most.
also, spaghetti code is the future. adapt or die tbh.
"huhuhu look at his spaghetti code, muppet " .... "but it works and is 3 months ahead of schedule ... ." ... "oh" ... "and there is documentation"
Specifically:
"Easy but boring project" case: For projects where I am already familiar with a strong and sensible architecture then I find AI enjoyable to work with as a simple speed boost. I know exactly what I'm asking AI to do at every stage and can judge it's results well. It's not that interesting to me to code these components myself because I've done it before several times. My mental model of the problem space and a good solution is complete. I get some satisfaction from using my mental model.
"Challenging but interesting project" case: For projects where I don't yet understand the best architecture then I will inevitably ask AI to connect Component A to Component B without yet understanding that there should be a Component C. Because I don't have the understanding of the problem space. The thing is before AI I may have made this mistake myself, I just would have had the satisfaction of learning at the same time.
Given the time with these type of projects I basically write them twice: First pass making it work but as a huge mess, but building a mental model of the real problem space along the way. Second pass refactoring and getting it right, creating now a mental model of a good solution. Only after two passes would it be a project I would feel is done correctly and be happy (joyful) to publish it.
I have found AI enables you to get the first pass working much quicker, but without the learning along the way of the mental model to inform how to make the second pass properly. So If I want the challenging project to be joyful I still need to invest the time to learn from the first pass.
And that specific learning task I enjoy more if I do it iteratively as the AI and I build together, it's less enjoyable if I sit down afterwards and only inspect the code.
SO if I want a challenging project to be joyful I have to continue investing the time in the first phase to do the learning. AI just gives the opportuntity to produce a messy working prototype without learning anything, which may or may not make sense for the business side of things.