Put yourself in their shoes; either the quality of Claude's coding continues to improve or else their business is probably doomed if it stagnates, so for them it makes sense to punt technical debt to the future when more capable versions of their models will be able to better fix it.

This is why I personally don't take technical debt arguments about how LLM maintained code bases deteriorate with size/age seriously; it presumes that at some point I'll give up with the LLM and be left with a mess to clean up by hand, but that's not going to happen, future maintenance is to be left to LLMs and if that isn't possible for some reason then the project is as good as dead anyway. When you start a project with a LLM the plan should be to see it through with LLMs, planning to have unaided humans take over maintenance at some point is a mistake.

Doesn't this contradict the popular wisdom that "what's good for a human engineer is good for an LLM"? e.g. documentation, separation of concerns, organized files, DRY.

I find LLMs very useful and capable, but in my experience they definitely perform worse when things are unorganized. Maintenance isn't just aesthetics, it's a direct input to correctness.

I am more worried that we are moving toward creating black boxes and this might turn software "development" into a field as confused as philosophy and dialectics.