Vibe coding in my opinion is analogous to say borrowing on a credit card to gamble on a startup.

Occasionally, in IRL you hear the feel good story how Fred smith gambled the last $5,000 to save FedEx and so on, but most people with that mindset end up crashing out.

Vibe coding a product runs the risk of acquiring too much tech debt before project is successful.

Product Market Fit is very hard, you need to keep enough room for pivots. Changes in direction will always accumulate debt, even when tech is well written. It is far more difficult when you accumulate debt quickly.

The counterpoint being that procrastinating and over-engineering prematurely or building lot of unrelated tooling and loosing focus can also bring the product down quickly or never let it start .

Being able to vibe code POCs etc is a great tool if done in a controlled limited well defined way.

Just as borrowing cash on your credit card is not always bad, it just usually is.

▲

sharadov 3 hours ago | parent [-]

Maybe vibe coding gets so good that we completely trash what was written and build from zero. I've seen that with badly written code as well, easier to rewrite than fix the un-goldly mess.

	▲	manquer an hour ago \| parent [-]
		Yes, if you know what you want exactly it is not difficult to rewrite. Writing is the easiest part of coding. The challenge is knowing exactly what is needed. No matter how bad the code, it is never easy to justify a rewrite . In a large and old enough code base, documentation is always incomplete or incorrect, the code becomes is the spec. Tens or hundreds of thousands of hours would have been expended in making it "work". A refactor inevitably breaks things, because no single person can fully understand everything. There is a reason why it is a well know principle don't fix what is not broken. Same reasons why we still have banking or aviation systems still running mainframe and COBOL from 70s. A rewrite requires the same or likely more number of hours of testing and adoption in a typically much shorter span of time in ironing out the issues [1]. Few organizations either private or public have the appetite to go through the pain and if its money facing or public facing component it is even harder to get buy-in from leadership or the users of app even. --- [1] During the original deployment the issues(bugs or feature gaps) would have been incrementally solved over many years or decades even. During the rewrite you don't have 10-20 years, so you not only have to expend the same or more number of hours you will have to do it much quicker as well.