Exactly. People ask how we get seniors with juniors using llm. The answer is the same. Review the code. Analyse write down what is wrong. What you expect to have been better. Force every change to be documented and explained enough.

> Its different, in that when you teach that engineer, they either leave because now they hate you, or they grow.

Or they just have their own hubris and ignore your (provably better) suggestions because their way is "better/easier/how we've always done things".

And then you end up with someone sprinkling N+1 issues throughout the system and making systems with bad architectures throughout the years, not thinking about backpressure etc., as well as shoving ALL the dependencies into a single codebase cause they're not used to creating new ones, turning patches into eventual month long version upgrades because everything keeps breaking with anything newer than JDK 8 and some of the packages are deprecated and gahhhh I should pick up woodworking as a hobby.

Though, to address the original claim:

>> If it is a better engineer than you... You need practice.

This feels like a thought terminating cliche. Like, it will spit out bullshit every now and then, and make assumptions that I don't think that many engineers would (e.g. since a lot of each app is environment-specific), but at the same time when you guide it and give it examples, it can really be quite good! So not that unlike humans at all, even competent devs might not necessarily know about every pattern in any given codebase, especially when one has been around for 10 years and grown quite a bit.

It can be quite good if you have something like ArchUnit or your own tools for linting project architecture and patterns, alongside proper documentation that doesn't assume that you're a team member with X years of experience on system Y. AI just forces people to be less lazy and ignorant about knowledge transfer, which they should have also been for the sake of other humans!