[moron4hire]

What does that have to do with LLMs? There's morev to delivering value to the customer than just shipping code. We used to understand that technical debt was an existential risk to a project. I can't see how "code nobody understands" is not technical debt.

[SeanAnderson]

I disagree. Shipping functionality that works and users consume is all that matters. Everything else is noise. Technical debt can be viewed through this lens - it reduces the rate in which functioning code is shipped. That's bad, but it's only one of many dials.

The author states they feel that using LLMs allowed them to ship years faster. That's years of time in which they can collect feedback and iterate. They might even choose to scrap the entire project and rewrite it based on their learnings. The practicality of this is directly enabled by agentic coding.

[wolletd]

Technical debt is aptly named. From time to time it demands it's interest in the form of delaying a new feature, but as long as your overall technical revenue is positive, it's fine.

[jiggawatts]

It sort of isn’t though, because it gives the wrong impression to people who look at things through a financial lens.

There’s no accrued compound interest: if you leave a piece of “indebted” software alone, you don’t pay any “interest”.

Conversely, a small amount of tech debt can actually cost huge amount… but only if you make many changes at a high rate.

That’s why I prefer the “worn tools” or “sand in the gears” analogies because they provide the right financial mental model.

An unlubricated, worn out piece of industrial machinery costs you nothing… unless you try to make things with it.

You can take this analogy quite far: sharp and lubricated but outdated machinery may work “just fine”, but you won’t be able to attract the top talent used to working with modern 5-axis CnC tools instead of having to manually turn cranks like a savage.