For about thirty years the path was the same. A junior engineer got the small stuff. The CRUD endpoint, the config parser, the test suite nobody wanted to write. They did it badly, someone reviewed it, they did the next one less badly. Two years of that and they could reason about a system.
That work is gone. It is the work these tools are best at, it is the work we now hand to them, and the ladder it used to form went with it.

I run engineering at a company managing over $100B in utility spend across 350,000 sites. We adopted these tools deliberately and I would make the same call again. But the effect on the people at the bottom of my org chart was not one I predicted, and when I ask other leaders about it privately most of them have noticed the same thing and none of us have a clean answer.

This talk is what I have tried. Some of it worked. Making review the teaching surface instead of the gate. Deliberately assigning work the tools are bad at, which turns out to be a useful lens on what engineering actually is. Reading generated code as a skill we now teach explicitly, because "does this look right" is a much harder question than writing it yourself was. And the uncomfortable one, which is that some of what we used to call training was really just billable practice, and we may not get to have both.

I do not have this solved. I have eighteen months of attempts and honest results, including the two that failed.