When looking at any system as-it-is, my perspective remains: tech debt is the state of a system that captured the understanding of the problem when it was created and doesn’t fully reflect today’s understanding.

The (obsolete) understanding applies to both functional and non-functional requirements, so it might be about the business, technical, scaling, or another aspect of that system (also organizational).

This might NOT help with “business” understanding what is meant by “tech debt”, but put it in terms of business understanding embodied in code, you might stand a chance to affect the roadmap.

Don’t forget – we will still produce (some) technical debt for the future as soon as the business or operational requirements change.

And, yes, vibe-coding will produce a lot of technical debt. Slop is not long-term.

◆

Inspired by the exchange on LinkedIn.

Knowledge map

Additional references

Quote: Technical Debt

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.

— Ward Cunningham

https://en.wikipedia.org/wiki/Technical_debt

https://de.wikipedia.org/wiki/Technische_Schulden (German article is quite different and worth reading)

Quote: Vibe coding

… a chatbot-based approach to creating software where the developer describes a project or task to a large language model (LLM), which generates code based on the prompt. The developer does not review or edit the code, but solely uses tools and execution results to evaluate it and asks the LLM for improvements.

https://en.wikipedia.org/wiki/Vibe_coding