true, but what if you just don't
use skills & multipasses to keep code clean and compact (which does work if you do it right, but drives up the cost)
use a different AI to review the first AI
give it a short not in depth human review, _except_ for anything security critical
rely on lintable language specific limitations (e.g. rust no unsafe, typing, white/banned lists of imports, no eval, language sandbox etc.) to reduce what can go wrong outside of the small part of properly reviewed code (and yes, this makes languages like C & C++ close to a no-go as many of the previous points are just too brittle)
I can not say I like this idea, I really really don't.
But I have seen a small startup having rather large success with it (at least during initial bootstrap time, rest will have to be seen), so as much as this idea repels me I fear this will become somewhat of an standard. But as mentioned they also did a _lot_ more then "just dropping in" AI. (Also maybe worth a shoot out is them doing decent requirements engineering, sure using AI, but I have seen way to many places skipping it fully at a hidden but extremely high long term cost)
I also have seen the opposites, large blobs of not well written AI generated code which produces a slew of subtle easy to overlook bugs & inconsistencies (partially due to giving the AI wrong requirements due to not having done requirements enginering) which passes tests but will come back to bite you later. This did drain teams hard. Not only did it eat a lot of time for reviewing, but also those kind of "not how humans would have messed it up" bugs drained even more time. Maybe worst all the new time drains where not the kind of work devs like to do, so that drained motivation to a point where it can affect productivity.