Technical Debt Vs. Architecture Debt: Don't Confuse Them

Are they right with the terminology? Do people consider mere bugs technical debt?

I haven't seen simple, visible problems being considered as technical debt so far. But rather only what the article calls architecture debt.

To me, it seems like the article indirectly proposes to use another term because the original one was used wrong too much. Do others see that, too?

"In the era of AI and data-driven enterprises, reducing architecture debt will no longer be a technical choice. It will be a strategic differentiator that separates the companies that can transform from those that will fall behind."

Yeah. Whatever.

How is AI even related to architecture debt in software? By vibe coders forgetting to specify "decent architecture" in their prompt?

Same for data driven. For most companies data driven just means focusing on one more or less relevant metric, but ignoring all rational arguments on topics cannot be measured in an easy way. Leading to short term thinking and optimizing for a metric instead of for business success. Not great, but still not a lot to do with software architecture.

And as much as I'd love software architecture to be a strategic differentiator: It really is not. Companies need software that is good enough. Good and consistent architecture just lessens the developers pain in dealing with it (and technical/architecture improvements are much more fun to do, since there is no customer with strange requirements). There are many companies out there with horrible software quality that still succeed.

Ward Cunningham: “If we failed to make our program align with what we then understood to be the proper way to think about our financial objects, then we were going to continue to stumble on that disagreement which is like paying interest on a loan.”

I am not sure what distinction that the article was trying to make, but this IS architecture problems coined as Technical Debt, not shoddy code.