Juniors After Autocomplete: Growing Engineers When the Model Writes the First Draft

Here is the leadership problem nobody warned me about when we made Claude Code and Cursor default workflows across the team: the tools are best, by a wide margin, at exactly the work that used to grow a junior engineer into a senior one. A junior used to become good by getting stuck — genuinely stuck, for an afternoon — on a bug that didn't make sense, and clawing their way to an understanding they'd keep for a decade. That specific struggle is the thing the model now dissolves in about nine seconds. I'm not nostalgic for the suffering. But I had to admit the suffering was doing something.

For a senior engineer, a model that writes a plausible first draft is a force multiplier — they have the judgment to know when it's wrong, and the drafts save them the boring part. For a junior, the same tool is something more dangerous: a very confident colleague who is right most of the time, wrong in ways they can't yet detect, and never makes them build the mental model that would let them tell the difference. Handed the same tool, the senior gets faster and the junior can quietly stop learning.

What the struggle was actually for

The old path had a hidden curriculum. When you had to write the retry logic by hand, you learned — in your body, not just your notes — why the network is a liar, why idempotency matters, what a race condition feels like from the inside. The typing was incidental. The comprehension was the point, and it came free with the typing because there was no way to get the working code without it.

AI tooling severs that link. You can now get working code without the comprehension, which means comprehension is no longer automatic — it's optional. And anything optional under deadline pressure quietly becomes rare. A junior can ship a full sprint of green PRs and come out the other side no more capable of debugging the system at 2 a.m. than when they started. That's not their failure. It's a gap in how we grow people, and closing it is a leadership job, not an individual-willpower one.

The tools didn't make juniors worse. They made it possible to look senior without becoming senior — and it's my job to make sure the two don't drift apart.

Make the understanding non-optional

So we stopped leaving comprehension to chance and built it back into the process. The mechanic is the one I use for all AI-assisted work: you can generate the code, but you own it, and ownership is checked out loud. On my team a junior's review isn't "does it pass?" — it's a conversation where they have to explain why the change is shaped the way it is and what breaks if a specific line changes. If the answer is "that's what the model gave me," we treat that exactly like a failing test: the work isn't done, the understanding is missing, and the fix is to go build the model they skipped.

This is the same ownership bar I hold for everyone — I've written about how review became a transfer of ownership rather than a correctness check. For juniors it just does double duty. The question that protects the codebase from unowned code is the same question that forces a junior to actually learn: do you understand this well enough to own it? You cannot answer yes to that without doing the growing.

Pick where the model is not allowed

The second thing we changed is deliberately keeping some work manual. Not because hand-coding is virtuous — it isn't — but because a junior needs a few problems a year where the whole point is the struggle, not the output. We pick those on purpose: a gnarly performance bug on a low-end Android device, a piece of core domain logic, a nasty concurrency issue. The model would happily do it. We ask the junior to do it first, get stuck, and come find a senior — and the senior's job is to be a rubber duck with taste, not to paste in the answer.

It costs time. That's the whole point; the time is the tuition. The alternative — a team where the tools are excellent and nobody under three years of experience can debug anything the tools didn't write — is a slow-motion capability collapse that doesn't show up until your seniors leave and there's no one who grew up underneath them.

What this looks like on a 12-engineer team

Concretely: juniors pair on review with a senior weekly, and the review is about the why, not the diff. Every junior owns at least one hard problem a quarter that they're asked to solve before reaching for the model. And we talk about this openly — that using the tools well is a senior skill, that leaning on them to skip understanding is the trap, and that nobody's judged for being slow on the problems we chose to make slow on purpose.

None of this is anti-AI, and my juniors ship more real work in their first year than any cohort I've led. But shipping was never the thing I was worried about. Growing the people who'll still be here, and still capable, in five years is the thing — and the tools that made shipping easy made that harder. Leadership is noticing the gap the tools opened and deciding, deliberately, to keep paying the tuition they let you skip.

If you're leading a team through the same shift and figuring out how to grow people inside it, I'd like to compare notes. Reach me at arun@arunjalota.com.