This is a good example of what LLMs save us from.

Everyone likes to pretend that LLMs are only capable of writing mudballs, but it's trivially debunked by using LLMs yourself to refactor code, pay back debt, and fan out agents to look for debt to repay.

We're already at the point with sota models where I'm not even sure you can get the sort of mudballs OP is talking about; the LLM's inherent "taste" forbids it, and it can just end-to-end refactor as requirements change.

The hypermudballs were distinctly a human creation due to how expensive it is to generalize and refactor brittle, incremental production code.

▲

tredre3 17 hours ago | parent | next [-]

I'm willing to keep an open mind but the only example you've shared of such a success story and debunk was a LLM clearing the technical debt of a codebase that was fully LLM-written from the very first commit?

If LLMs are so good at fixing tech debts, why did it write so much to begin with? And why do you assume that now there's no more debt?

	▲	gdulli 15 hours ago \| parent \| next [-]
		It's like trying to argue with someone saying they actually are going to build the whole plane out of the black box. At some point we should just cut our losses.
	▲	hombre_fatal 16 hours ago \| parent \| prev [-]
		Good questions. > why did it write so much to begin with? It's an incremental project covering a complex domain. At any time, the code has to stay balanced in a spot that addresses correctness and performance across things like pty parsing, a terminal grid, stateful pty behavior, rendering, scrollback history, font glyphs, and like all software there is a fractal of idiosyncrasies that sprout up. And that's just the terminal side. Unless you can see the future, like most software, so much of the project is trying things and seeing what happens at the periphery, like how to represent "row damage" and apply it in a way that works with macOS Core Graphics and 1000 other things. e.g. Can you tell me off the top of your head what the trade-offs are of representing the terminal contents/scrollback as a pre-wrapped grid vs. a list of logical lines that are soft-wrapped on the fly? Did you enumerate them all and correctly weigh them such that you can pick the ideal solution ahead of time? No. You just kinda make educated decisions and find out in practice what the exact weight of the trade-offs are. You should see the amount of iterations a human needs on these kinds of projects. https://github.com/ghostty-org/ghostty has almost 18,000 commits. So does https://github.com/gnachman/iterm2. So does https://github.com/kovidgoyal/kitty. > why do you assume that now there's no more debt? I don't. Like all software, you try to ratchet into better and better positions, and you try to come up with metrics that can tell you "You are here" with regard to rather fuzzy goals like "it should be correct and performant and nice to use". But I can look at individual findings and their solution to go "yes, this improves the code." And on principle I think that, e.g. correct/DRY/simple by-construction is superior to by-convention, and I assume it helps future agents reason about the system and make future edits, and it gives them singular places to make changes that impact multiple components just like it would a human. But how much did it actually matter?

▲

MartinodF 17 hours ago | parent | prev [-]

While I agree and I have done more than one rewrite / cleanup of messy codebases quite successfully with LLMs in the past few months, I can assure you plenty of people are still using the latest models to accrue technical debt faster than I thought was ever possible. The model "taste", assuming it has one, does not survive bad instructions

▲

hombre_fatal 17 hours ago | parent | next [-]

Like real life, you want to accrue debt strategically.

When you're experimenting, vetting ideas, mapping out the requirements, exploring solutions, then technical debt keeps churn cheap.

e.g. You don't want to overly commit to static types that keep "impossible state unrepresentable" too early on since you aren't even sure yet what impossible state looks like in the system.

So we regard debt repayment as some sort of transformation we'll do in the future that never comes because it's hard and expensive, but not to LLMs.

▲

gdulli 17 hours ago | parent | prev | next [-]

People refuse to accept that there's more bad code/behavior/people that AI will empower and amplify than good.

	▲	hombre_fatal 17 hours ago \| parent [-]
		Because we have evidence otherwise, and even the worst code can be refactored by LLMs. That a high velocity project might accumulate technical debt isn't interesting to me if LLMs can also pay it back or if you can decide to work at a different pace where you polish the architecture as you go instead of accumulating debt. I'd make the opposite claim to you: people really don't want my claims to be true, probably because it robs us of our value and expertise as software engineers. But it's getting a bit late in the game to still be dancing around that pill to swallow.

▲

efficax 17 hours ago | parent | prev [-]

the models have gotten very good at doing what you ask. if you ask for changes that will accrue tech debt, you'll get it. if you ask for changes that pay down that debt, you'll get it.