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 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'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.
But, in my experience, technical debt does add up fast, especially as the project grows or when you want to refactor for reliability.
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.