This is the biggest lesson I got from LMMs. I have a 1 million LOC vibe coded project that I can only imagine would fit in a few hundred thousand lines. But it's still holding up, I expected some kind of development collapse long before this point.

▲

cassianoleal 3 hours ago | parent | next [-]

I don't think that's a good lesson.

OP is right that code duplication is far cheaper than the wrong abstraction, but the opposite is also true - the right abstraction is far cheaper than code duplication.

▲

gb2d_hn 3 hours ago | parent | prev | next [-]

It's made me wonder the same, but most LLM generated codebases haven't been around long enough to judge maintainability. I have noticed issues in some of my more LLM heavy code when I expect a change to be replicated in multiple areas, assuming common code / styling was reused, only to find it wasn't. It's for that reason I can't use LLMs for client codebases without heavy scrutiny of every line generated (for my own hobby projects I'm a lot more lenient)

▲

gavmor 3 hours ago | parent | prev [-]

Well sooner or later I would expect a developer who intimately understands their code base to feel compelled to start refactoring and extracting fitting, meaningful well-leveraged abstractions.

▲

imhoguy an hour ago | parent [-]

I don't think that will happen anytime soon. Prompts are the code now, and programming languages code is compilation product. Almost nobody optimizes compiled assembly code.

Perhaps "recompilation" - rewrite by replaying all prompts in strict code quality context (linters, complexity & dedup checks) would make better abstractions.

The only problem now is that LLMs are non-deterministic.

	▲	gavmor an hour ago \| parent [-]
		> Almost nobody optimizes compiled assembly code. Compiled assembly code is not an input to the next compilation; source code is an input to the LLM's next inference. Sure, maybe "prompts are the code," but you must realize that code is also the prompt.