Right. One thing I learned over the years is that you can support arbitrarily high level of tech debt and still be able to effectively maintain and enrich a successful software system, as long as you throw enough warm bodies at it.

The overhead will get absurd, you'll end up with 10x or more increase in engineers working on the system, all of them making slow progress while spending 90% time debugging, researching, or writing docs and holding meetings to work out this week's shared understanding of underlying domain semantics - but progress they will make, system will be kept running, and new features will be added.

If the system is valuable enough for the company, the economic math actually adds up. I've seen at least one such case personally - a system that survived decades and multiple attempts at redoing it from scratch, and keeps going strong, fueled by massive amount of people-hours spent on meetings.

Adding AI to the mix today mostly just shifts individual time balance towards more meetings (Amdahl's Law meets Parkinson's law). But ironically, the existence of such systems, and the points made in the article, actually reinforce the point of AI being key to, if not improving it, then at least keeping this going: it'll help shorten the time to re-establish consensus on current global semantics, and update code at scale to stay consistent.

This is the realization that pretty much all engineers go through as they become more senior. The areas where the business really can’t afford issues is very small. Usually only accounting / billing and then that’s solved not by great code / design but just audit it once and never touch it again.

In the end most challenges for a business holding them back to better code quality are organizational, not technical.

Well yeah, I'm not sure why that's sad. One can't find all edge cases at the beginning but only through usage of the app, and fix them over time. Be glad at least someone is using the app as that means the role of software is being fulfilled, as a tool to help people accomplish some goal, because much software written isn't even used by a single person.

That comment seems off-topic, but just to exemplify:

In your example even as the interface for those products is unstable (UI that changes all the time, slightly broken API), those products are coded in a language like C++ or Java, which benefit from compiler error checking. The seams where it connects with other systems is where they're unstable. That's the point of this blog post.

Yeah that's true, a product can be successful with truly bad code, but it also makes developers lives miserable each time they need to add a new feature, solve a bug, or simply understand how that entangled mess works.

Management and sales may not appreciate good software design and good code, the next developer that has to work on system will.

A decision can be right even if the outcome doesn’t work out and a decision can be wrong even if the outcome works out.

Example: Gambling is wrong but you can win big money.