Ask HN: What's Your Experience with Vibe Coding?

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".

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.

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.

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 :)