This is a great example of AI tech-debt and fragility.

An eight-join query is going to be nigh on unmaintainable should the requirements change, leading to a change-break-change-break spiral as your preferred coding agent tries to fix its previous fixes.

Maybe the wise way to use AI would be to sort out the schema.

This feels wrong. 8 joins is almost certainly reporting stuff, not transactional. Contrary to what some SQL-averse devs think, 300 lines of SQL is actually more maintainable than the equivalent ~1000 lines of application code. It's also much faster. And I do think that's the real conversion, because SQL is a much higher level language than currently available application languages. It's also declarative in nature, which helps maintainance.

A highly normalized DB can easily end up with 8 joins required for some function. That's really not out of the question. "Sorting out" the schema then would be... denormalization, which is a thing, but you need to know why you're doing it. And I think 8 joins isn't enough of a reason.

Yes but developers (or at least web backend developers, who are the ones I interact with the most) are extremely averse to SQL and normalization.

I think that's what was meant by "reporting stuff, not transactional".

That's exactly where I would expect it to fail somewhere, changing some part of the query every time it writes one.

In my experience, Claude (at least Opus and Sonnet) is pretty good about not misremembering itself.

I think you may be describing the experience of 6-12 months ago.