Ask HN: What's Your Experience with Vibe Coding?
I’m doing this myself to a pretty far extent while building two agents for my workflow automation. It’s been fun and surprisingly productive, but I’m also worried I might be stacking up technical debt.
9 comments
I don't vibe code, but I maintain open source projects where vibe-coded contributions are coming.
Before, I had some amount of code reviews where I would ask "why are you doing this, instead of that cleaner/easier way?" and people would usually make the change. I would assume that they probably didn't know better.
Now, I still have some amount of reviews where I ask the exact same question, and people say "that's because [your favourite agent here] did it like this". So now I consider they don't really care.
Not sure how much it changes: as a maintainer, one couldn't trust contributions before and one cannot trust them now. People were opening PRs with code that they had never tested and that did not compile before vibe coding, so that doesn't feel very different. I guess it just feels a bit more frustrating to think that you are putting more effort into reviewing than they spent... well not "coding it" but "asking their agent to make it".
Before, I had some amount of code reviews where I would ask "why are you doing this, instead of that cleaner/easier way?" and people would usually make the change. I would assume that they probably didn't know better.
Now, I still have some amount of reviews where I ask the exact same question, and people say "that's because [your favourite agent here] did it like this". So now I consider they don't really care.
Not sure how much it changes: as a maintainer, one couldn't trust contributions before and one cannot trust them now. People were opening PRs with code that they had never tested and that did not compile before vibe coding, so that doesn't feel very different. I guess it just feels a bit more frustrating to think that you are putting more effort into reviewing than they spent... well not "coding it" but "asking their agent to make it".
There's two types of code, based off The Pragmatic Programmer. One is the prototype, you build it and discard it. You absolutely have to discard it, burn it. It's a search algorithm - you're searching for a business problem and surveying different spots.
Second is tracer-bullet - ready, fire, aim. This is just faster than writing up and iterating on specs; the process of coding it determines the spec. Tracer bullets work because they operate in the same environment and under the same constraints as the real bullets. They get to the target fast, so the gunner gets immediate feedback. This forms the skeleton of your code.
Vibe coding is great for both, but people get into arguments because they're talking about different things. Inexperienced people usually use tracer code when they should be making prototypes.
If you're doing prototypes, then technical debt is absolutely not a problem. You should go in there with the mindset of burning it all. A popular myth is prototypes should never be in production - this is simply untrue; most major startups have pushed their prototypes to production then rebuilt it later on. If a prototype isn't in production, then how do you know that customers would pay for it? Just make sure people get what they paid for.
If you're doing tracer code, then you want to be laying down tracks like tests etc. You should probably be doing TDD. TDD plays well with non-deterministic stuff. The big argument against TDD then was that you'd have to code everything twice or you'd have to put in the architectural effort to handle tests. Well, AI gives us the capacity for this.
Second is tracer-bullet - ready, fire, aim. This is just faster than writing up and iterating on specs; the process of coding it determines the spec. Tracer bullets work because they operate in the same environment and under the same constraints as the real bullets. They get to the target fast, so the gunner gets immediate feedback. This forms the skeleton of your code.
Vibe coding is great for both, but people get into arguments because they're talking about different things. Inexperienced people usually use tracer code when they should be making prototypes.
If you're doing prototypes, then technical debt is absolutely not a problem. You should go in there with the mindset of burning it all. A popular myth is prototypes should never be in production - this is simply untrue; most major startups have pushed their prototypes to production then rebuilt it later on. If a prototype isn't in production, then how do you know that customers would pay for it? Just make sure people get what they paid for.
If you're doing tracer code, then you want to be laying down tracks like tests etc. You should probably be doing TDD. TDD plays well with non-deterministic stuff. The big argument against TDD then was that you'd have to code everything twice or you'd have to put in the architectural effort to handle tests. Well, AI gives us the capacity for this.
I gave it a serious try for a side project. Entirely vibed from system design to backend, db, frontend and all sort of ci/cd hacks.
I ended up binning the fully vibed version and started again with a design of my own. This mostly because the final product wasn’t really usable.
Then I heavily modified the backend.
In the last days I finished a major refactoring of the frontend.
I’m now in the situation where the project is 20% vibe coded.
If I were to start again it would possibly be less than that. Just because in the process I learnt as much react I need to do things myself.
This was using a mix of gpt4, claude, gemini, lovable…basically anything with a free tier to squeeze free tokens from
I ended up binning the fully vibed version and started again with a design of my own. This mostly because the final product wasn’t really usable.
Then I heavily modified the backend.
In the last days I finished a major refactoring of the frontend.
I’m now in the situation where the project is 20% vibe coded.
If I were to start again it would possibly be less than that. Just because in the process I learnt as much react I need to do things myself.
This was using a mix of gpt4, claude, gemini, lovable…basically anything with a free tier to squeeze free tokens from
you probably are stacking up technical debt. However every project has some, it comes down to, weather or not you understand what you are doing. If something goes wrong, would you know where and how to fix it? if the answer is yes, then you are fine IMO, if you don't feel confident with what you have built technically, then it might be worth investing more time into some code harding. but my 5 cents is, vibe coding is meant to be fun, so have fun and learn :)
I'm using Cursor agents + Claude to build a new Android app.
I'm building an app that uses WebRTC, which is not something I am deeply familiar with. I have found Claude to be useful at working through boilerplate (android apps are full of boilerplate) and building a working prototype.
Technical debt can be a problem. You have to be aggressive about either refactoring the code yourself, or getting Claude to refactor it to your style.
I'm building an app that uses WebRTC, which is not something I am deeply familiar with. I have found Claude to be useful at working through boilerplate (android apps are full of boilerplate) and building a working prototype.
Technical debt can be a problem. You have to be aggressive about either refactoring the code yourself, or getting Claude to refactor it to your style.
Agreed that refactoring is often needed - my go-to refactoring LLM is Gemini 2.5 Pro, but Claude and o3 also do well for me.
I find that the context engineering, planning and documenting is crucial, but sometimes I like to let the vibes lead the way.
I find that the context engineering, planning and documenting is crucial, but sometimes I like to let the vibes lead the way.
I have tried “vibe coding” (just building as you go, following momentum) for a few AI agent side projects. It’s great for fast prototyping and exploring new ideas—often gets you to working demos much quicker than over-planning.
But, in my experience, technical debt does add up fast, especially as the project grows or when you want to refactor for reliability.
But, in my experience, technical debt does add up fast, especially as the project grows or when you want to refactor for reliability.
I've been writing code professionally for 10+ years and I love vibe coding. It's brought back the joy for me in creating things. All the tedious tasks can get farmed out and I can just think about the hard problems and direct the minions to build it.
I built an app for iOS and android recently with a combination of Claude, and cursor. I started off by drawing Claude a picture of what I wanted the app to look like, and telling it to give me the skeleton of an iOS app. (It did a surprisingly good job)
Then I switched to cursor and iterated with it on making it work. Once I had the iOS app running, I got cursor to create an android app that looked and functioned the same.
Super interesting experience - took a couple of days of iterating here and there, helped to have them in git repos for when cursor went too far off piste.
Both apps work, they look pretty much like my original picture.. and the code is absolute trash. I don’t know swift, or particularly kotlin, but the code is horrendous. If you wanted to take them any further, you’d rewrite it from scratch.
This was. Rating combinations of Claude 3.7, 4.0 thinking, Gemini 2.5, and chatgpt 4. (Switching between agents when one was getting stuck.)
Observationally, they all had a much harder time with android and rarely produced anything that didn’t need fixing to build.
Great for rapid prototyping in a stack I don’t know, but 100% tech debt.
Then I switched to cursor and iterated with it on making it work. Once I had the iOS app running, I got cursor to create an android app that looked and functioned the same.
Super interesting experience - took a couple of days of iterating here and there, helped to have them in git repos for when cursor went too far off piste.
Both apps work, they look pretty much like my original picture.. and the code is absolute trash. I don’t know swift, or particularly kotlin, but the code is horrendous. If you wanted to take them any further, you’d rewrite it from scratch.
This was. Rating combinations of Claude 3.7, 4.0 thinking, Gemini 2.5, and chatgpt 4. (Switching between agents when one was getting stuck.)
Observationally, they all had a much harder time with android and rarely produced anything that didn’t need fixing to build.
Great for rapid prototyping in a stack I don’t know, but 100% tech debt.