The LLM might change the economy of this, but I doubt it.

I tend to believe that the engineering culture you describe will end up producing similar or, as Joel postulates, an even worse result, just dressed up in a modern stack.

If the technical leadership remains the very same one that enabled such a culture, I don't see them being able to suddenly produce a genuinely better software product only because an LLM is in a picture - especially considering how easy it is to convince an LLM that your idea is the best one.

Well, Joel is not saying not to refactor anything. In fact he is advocating improving the code quality in small steps. What is missing there is that in practice improving code quality in small steps requires automated tests . But I guess he can be forgiven given when he wrote the article.

I think the important lesson is to use clear eyes to evaluate what the rewrite buys you. I was on a team that rewrote a native code app in C#. We also had access to early cloud tech in the Azure stack, what is called queue now and then was called service bus.

These two technologies combined greatly simplified this specific product making it far easier to maintain. Performance on these services was not important so native code was carrying a lot of penalties without the benefits.

Having a well documented messenger like service bus with great SLAs removed several tools we had needed in the old implementation.

We were able to leverage the tests form the original product to define success and tmthus were able to solve a lot of the edge cases in the new code w before we even shipped.

However, the old code was perfectly fine code. If new technologies had not provided significant simplification of the service architecture, a rewrite would've been foolish. And without the very good previously existing tests, we would've run into a lot of issues as we released.