upvote
If you make a working and functional bad code, and put it on maintenance mode, it can keep churning for decades with no major issues.

Everything depends on context. Most code written by humans is indeed, garbage.

reply
> Most code written by humans is indeed, garbage.

I think that this is the problem, actually.

It's similar to writing. Most people suck at writing so badly that the LLM/AI writing is almost always better when writing is "output".

Code is similar. Most programmers suck at programming so badly that LLM/AI production IS better than 90+% (possibly 99%+). Remember, a huge number of programmers couldn't pass FizzBuzz. So, if you demand "output", Claude is probably better than most of your (especially enterprise) programming team.

The problem is that the Claude usage flood is simply identifying the fact that things that work do so because there is a competent human somewhere in the review pipeline who has been rejecting the vast majority of "output" from your programming team. And he is now overwhelmed.

reply
I define maintenance mode as: given over to different team, so not my problem anymore.
reply
If you are a company founder, what scenario would you rather find yourself in?

a) a pristine, good codebase that follows the best coding practices, but it is built on top of bad specs, wrong data/domain model

b) a bad codebase but it correctly models and nails the domain model for your business case

Real life example, a fintech with:

a) a great codebase but stuck with a single-entry ledger

b) a bad codebase that perfectly implements a double-entry ledger

reply
"Perfectly implements" is doing a lot of work there. Enterprise software is very rarely perfect out of the box, and the issue with bad code is that it can make it extraordinarily hard to solve simple problems. I have personally seen tech-debt induced scenarios where "I want a new API to edit this field in an object" and "Let's do a dependency upgrade" respectively became multi-month projects.
reply
> Perfectly implements" is doing a lot of work there. Enterprise software is very rarely perfect out of the box

Fair, by “perfectly implements” I meant to say that it correctly implemented the core invariant of a double entry ledger (debits = credits), not that it was 100% bug free

reply
And it’s perfectly okay to fix and improve the code later.

Many super talented developers I know will say “Make it work, then make it good”. I think it’s okay to do this on a bigger scale than just the commit cycle.

reply
https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast

Make it work, make it work right, make it work fast. In that order.

reply
> Bad code works fine until it doesn't.

Who is to judge the "good" or "bad" anyway?

reply
But tech debt with vibe coding is fixed by just throwing more magic at it. The cost of tech debt has never been lower.
reply
The fix time horizon changes too, don't discard that.
reply