Composition over inheritance debate does not resonate with me as much especially in Python, as I see classes more like modules and modules more like classes - namespaces - and rarely "types". I can mainly agree with the mainstream understanding to prefer composition over inheritance though. (if the team knows about OOP at all :-)

As for AI code generation, this is more controversial. If the codebase is DRY enough there should not be enough possibilities to statistically guessing new code based on the old one.

Let me add more dimensions to the topic here. First of all, it can be interesting to know what specifically AI brings to the code? Is it mostly code style, boilerplate code or business domain knowledge?

As you can guess, boilerplate code should not be needed in a DRY enough codebase. As for domain knowledge - if it is really the case, then probably there is some library out there, which can be used. Using AI to guess core domain knowledge with copilot sounds weird - AI can be used to come up with some general ideas, but domain knowledge better be more explicitly handled (and this is the true problem behind the Figure mishap, I think).

And the best way to DRY codebase making it flexible at the same time is to divide it into declarative and Turing complete language code parts.

The declarative part ("configuration") is easy to store, transfer, make inferences in, etc, while the "true code" part can be quite generic (but require more experienced guy to write).

Then AI can be of great help with the declarative part, as it usually is the direct reach for LLM systems and advanced non-programmers alike.

And then we no longer need to dispute OOP approaches as the Turing complete language code will need to be changed less often.

This is what I would really call a new era.