Ask HN: What's Your Experience with Vibe Coding?
3 techlust 5 7/9/2025, 8:37:14 PM
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.
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".
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'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 find that the context engineering, planning and documenting is crucial, but sometimes I like to let the vibes lead the way.