I use the term technical debt about code that keeps you back in some way - things that you should really attend to so that your solution can be easier to work with in the future. All the things that are not the way they should be, in the best of all possible worlds. The things that make adding new features and improvements harder than they really should be.
The more interesting distinction, to me, is whether the technical debt was incurred knowingly or not - and whether there is an intention to “pay it back”.
The nice thing about incurring technical debt (i.e. not making it perfect the first time) is that you can go faster. You can ignore certain things to reach goals that would be impossible if you did not give yourself the leeway to incur debt. It’ll cost you if you maintain the solution, but like monetary debt it is often well worth it to get to where you need to be.
The excellent thing about technical debt is that you can actually decide not to pay it back. Sometimes you just re-do the entire part (effectively declaring bankruptcy for that thing - you’re not paying it back), or even decide to do without it. This is why it’s totally fine to write non-perfect, messy stuff for your prototypes, proofs-of-concepts and spikes. As long as they are going to go away or be re-done you don’t really care about the future coder working with them - there is no such future coder. The debt is essentially free.
If you leave technical debt in something that you want to maintain, however, you’d better look into paying it down or be fine with the cost to future development.