That's because the businesses got into the habit of new C level means new project, obviously the old code is bad.

I even had a PE buy the company I worked at, put in a new CEO, and his goal was to rewrite the entire code base in a year. I asked him what problems this would solve and never got a straight answer besides "its yucky" and "people told me they dont like it."

I have had multiple upper management teams decide that "dealing with this product is too hard, let's start from scratch" as if the new thing wouldn't have the same problems of the old thing, but with less effort put into it.

People love to work on new, all the possibilities and none of the bugs!(yet)

It's different because LLMs can generate code that immediately needs to be refactored at speeds that were unfeasible before. There was a practical limit on the amount of technical debt that could be created in a day before, now that limit is 10x or 100x higher. It can be generated far faster than it can be fixed.

In my experience, this is because a modern engineering organization is laser focused on delivering value. Value rarely aligns with refactoring an existing, working implementation. If need the data, you build an integration on the output data. If something isn’t working well enough, you fix that one thing, you don’t refactor half the application.

Getting product to prioritize refactoring a working product is like pulling teeth. Even if maintenance is a moderate drain on resources, work beyond maintenance on working solutions isn’t seen as a net win.

The problem in isolation isn't new as such, but I think there's a combination of new factors to differentiate it:

1) the speed at which AI-generated codebases grow is far in excess of what human developers can achieve. What took years to accumulate in the past can be produced in a few days/weeks.

2) past large codebases that end up in a similar state would often see a mixture of developer talent. So while you might have a few developers who produce dross, there will also be a few who can pull it back together. You start to see threads of sanity appear, and from that the potential to refactor further, rather than the uniform spaghetti monster that's near unassailable from every direction that we're now getting from the pure-AI projects.

3) external perception differs. AI has been pitched, sadly by sales, influencers and shills rather than experts in the field, to business leaders as the solution to all development problems. When you present this issue to stakeholders you're then immediately put on the defensive, e.g. it's initially viewed as negativity for the sake of negativity. With past technical debt discussions, outside of a few key parties (too often the person responsible for overseeing said debt developing), I've found that it's relatively straight forward to explain technical debt, the need to refactor and maintain systems as a going concern. For the technically disinclined it's easy to draw parallels with building maintenance: you don't expect to build an office and then never spend another cent, it takes continued investment and maintenance to keep it safe, clean, functional and compliant. The difficulty again with the AI projects here I think comes back to the accelerated timeline, as you're inevitably going to be saying months after it's created that it probably needs to be burnt to the ground in lieu of the far greater task of refactoring it. As opposed to a legacy project that has been going for years or decades, where it's a far more palatable concept to take drastic action.

You're just witnessing "Software Developers" cry out over LLMs.

"Software Engineers" are embracing LLMs and getting shit done same as before.

> how to clean up old projects

What’s “new” is indeed the “new” bit in cleaning up new projects.