An engineering manager I'd worked with called me. His team had adopted AI coding tools eight months earlier. At first, things went well: velocity was up and people liked the tools.
Then the cracks appeared. Junior developers were shipping faster, but reviews took longer. Senior engineers spent more time checking their work. Bugs reached staging. A few juniors struggled to explain choices that looked fine in the code.
The manager's read: "They're shipping more, but I'm not sure they're learning."
That gets to the management problem for many engineering teams right now.
The asymmetry
AI coding tools amplify the judgment you bring. Experienced engineers can evaluate the output, spot subtle errors, and ask better questions. They get faster at work they already understand.
For engineers still building that judgment, it is more complicated. The tools help them ship, but can skip some of the process that builds understanding: debugging, refactoring, and reading code that failed.
On teams that haven't adjusted, the result looks like success while a debt builds underneath. Juniors ship more but need more senior oversight. Seniors get faster too, then give the time back in review. The team produces more, but learning shifts in ways that matter later.
What the role of a junior engineer is actually for
I'm not pessimistic about junior engineers or the tools.
Junior engineers in a well-functioning team serve two purposes: they contribute to the work, and they develop into the senior engineers the team will need in two or three years. Both matter. The tools affect both, but differently.
Their contribution improves. A junior developer with good AI tooling can deliver value sooner and work on a wider range of problems.
Their development needs more care. If the default is to generate code and send it for review, some of the learning that happened while writing from scratch disappears. The tools don't prevent learning. They just make it easier to skip.
What I've seen work
The teams handling this well haven't restricted the tools. They've changed what juniors do with the output.
One useful change is asking juniors to explain their choices in a short conversation. Not "why did you use a loop?" but "what happens if the input changes?" or "how does this fail when the upstream service is slow?" Answering requires understanding the code, not just reading it.
Another is separating generation work from understanding work. Use the tools freely for the former. For the latter, read unfamiliar code, debug without assistance, or pair on a problem before reaching for the tool.
It is tempting to treat the productivity gain as uniform. But junior developers moving at senior speed often rely on senior judgment later in the review. The time hasn't vanished. It moved.
The manager's job has changed
The management challenge here is that output has become a less reliable signal of development. A junior developer who ships a lot of code may or may not be developing the engineering judgment that makes them a reliable contributor at the next level. The traditional proxy — watch the output, track what they build, see how it holds up — is noisier than it used to be.
Good managers ask more questions about understanding: Can this person explain the system? Can they reason about what will break? Can they debug without the tool? It takes more direct conversation than checking output metrics, but it shows what they're learning.
Code review also needs a learning function. The question isn't only "is this correct?" but "does the author understand why?"
That review takes longer. Teams should budget for it as an investment in future capability, not expect it to shrink as the tools improve.
If you're managing this shift, I'm happy to compare notes on what is working and what isn't.