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.

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.