A few weeks ago, a new hire at Aviator, fresh out of college, asked me a question I didn’t have a clean answer to. How do I become a senior engineer, or even a staff engineer? What should I learn, and how?
It’s a fair question and a harder one to answer than it was just a year ago.
The path used to be well-known. As a newly hired junior software engineer, you were given an experienced mentor who would assign you simple tasks to learn the ropes. You’d write some code, ask plenty of questions, open a pull request, get feedback in code review, think about it and fix your code. Rinse and repeat that a few hundred times. The tasks became more complex; the feedback got shorter and along the way you’ve been building judgment, the thing that separates a senior engineer from a junior one.
Now AI writes most of the code. The loop looks different and the easy assumption is that it’s broken: fewer tasks for juniors to cut their teeth on, an agent fixing the code that another agent wrote, thinner path to judgment.
I knew just the person to ask: how do we grow senior and staff engineers in the AI era? Adam Berry is a staff engineer at Netflix, a member of The Hangar, our community of engineering leaders, and someone I have been discussing the evolving role of code review and knowledge sharing for a while now. He spends his time on getting AI adoption right, rather than just fast, in their engineering organization and has been working out the question of growing new engineers in practice. Mentoring juniors in an agentic world, Adam says, isn’t harder; it’s embarrassingly easy.
“You grow juniors and help them become better engineers the same way you always did. AI isn’t changing the methodology. It’s changing the details,” he told me. His point is that the agentic world gives a lot more options for giving juniors bounded tasks to work on and more feedback. The scattered remarks and comments seniors used to give in person now can be put into instructions and guardrails.
Adam breaks working with agents into three foundational skills:
“Most juniors can pick up the first two on their own. On the third one, they need guidance, he says.
His process for building it is staged. “The stages are about growing scope. First, you give a junior engineer a well-specified task—and these are now bigger than what you’d have given a junior before. You can give them task definitions that are like a prompt and instructions to drive that prompt, make sure they got to a good plan, make sure they understood the plan, and that they thought through the test cases, etc.
Then gradually you peel off some of that specificity so they have to build the muscle themselves. Once they’ve gotten good at that level of scope, they’re ready to work on larger scoped problems.”
Starting from more specific problems and going towards ambiguous problems is the definition of growing as an engineer.
Seniors can still do pairing sessions with juniors, now with the agent in the room.
“In the pairing session, the earlier-career engineer should be the one driving. The agent can be set up to interrogate the junior rather than just answer them. None of you is manually writing code, but you’re still doing pair programming and mentoring. Even if it’s just a trivial bug fix, if you guide a junior through it, it forces them to do just that little bit of thinking.”
Adam says mentoring juniors today does not have to mean forcing them to write code manually. Seniors should teach them the process of agentic engineering, and that’s exactly what they should focus on during the pairing sessions. The habit he wants to be installed early is asking for options instead of answers.
“I aim to teach juniors to ask for options and think through them, even on small tasks. I ask them to explain what their input to the AI tool was that led to the code they got. But I’d also show them how I would have done the same thing.”
The pairing produces artifacts as it goes. “That’s where you get into conversations of, ‘This is why that wasn’t quite it for me,’ and if I see that that’s not baked into the repo, I’m going to add this into the ADR, into the design, into the instruction set. I’ll codify that so the junior gets it too, and they know why it exists, because they watched me go through it with the tool myself.”
That reshapes the code review instead of removing it. Making that work puts more on senior engineers, not less. “Senior engineers need to ensure that things like ADRs, or whatever system you use, are properly encapsulated in the repo for both the agents and the humans to consume.” His team also attaches the prompts to the pull request and has the agent summarize what it did against what the prompt asked.
Adam also teaches junior engineers how to bring in expert sources from outside into AI tools. He’ll point an agent at a book like Michael Feathers’ Working with Legacy Code as an example of what quality code looks like and have it work from the concepts directly.
His arguments make sense, but I also recently came across research examining the influence of AI tools on how and why members of software engineering teams interact. Their finding was not surprising: of the 131 surveyed developers, 51% said they now ask GenAI for technical help they once would have asked a person, and 62% said it was easier to ask GenAI without fear of embarrassment.
When a junior gets stuck now, their first move usually isn’t to message a senior on Slack. It’s to ask the agent. This is also the case in code reviews. The purpose of code reviews was always knowledge sharing as much as it was a quality gate. What I see junior engineers do now is take the feedback and, without reading it closely, hand it straight to the agent to resolve. The part where they would have to understand how their work differed from what the senior expected disappears. It got passed from the reviewer to the agent, and the junior skipped the understanding.
This isn’t really the junior’s fault. They need the motivation and the space to do it differently, and the default pattern under delivery pressure is to push the thing out and worry about it later.
The same research showed that developers turned to colleagues with questions about context (65% to clarify business logic or requirements, 50% for how something had been done before).
Respondents were also aware of the trap that Berry’s approach was created to avoid: AI tends to hand back a single answer, compared to multiple perspectives a colleague surfaces and they kept seeking teammates for context-specific expertise, mentorship and plain social connection.
The fix is almost mechanical: if you have to make a choice, you have to think about it. I do this in my own product thinking. Most of it happens by bouncing ideas off Claude, but whenever something is complex, I make myself lay out a few options, trade them against each other and decide which direction to take. That’s the same move Berry wants juniors making, and it’s what builds judgment, whether you’re twenty-two or forty.
There’s also a hiring question underneath all of this. We recently hosted Kent Beck, an industry legend, at the Hangar in a session we called “Juniors FTW,” and his reasoning was that the industry is being remade fast enough that being new is an advantage. Juniors are too new to have absorbed what everyone “knows” is impossible, which leaves them less biased, more creative and carrying fewer preconceived mental barriers.
Beck also wrote about how important it is to hire juniors without the calculation of how many tasks they can perform. “If all we cared about was today’s productivity, we wouldn’t have hired you at all. Instead, we (the seniors) are focused on the future: we know there’s going to be far more work here than we could possibly accomplish. We are paying your salary now as the option premium on the engineer you will become. If we play this game right, we’ll have a kick-ass next generation of engineers. If not, we’ll have to be doing the same engineering jobs ten years from now, and we really don’t want to be doing that.”
The trend is running the other way. Entry-level hiring at the 15 biggest tech firms fell 25 percent from 2023 to 2024, according to a report from SignalFire. In a recent survey of engineering leaders, a majority said they plan to hire fewer juniors, on the logic that AI lets seniors cover more ground.
That logic is short-sighted in a specific way. Senior engineers don’t appear from nowhere. They’re the juniors someone hired five or ten years ago and invested in mentoring them. Stop hiring and growing juniors now, and the gap doesn’t show up this year. It shows up later, when the industry needs people with the judgment that only comes from years of making mistakes and recovering from them and finds it stopped producing them.
So, here’s the answer to the question that the new hire asked: the path to senior and to staff is the same path it always was. You grow the range of ambiguity you can handle, and you stay honest about the part you can’t handle yet. What changed is the interface. The agent writes the code. Your job is to keep asking questions to your colleagues and the agents and keep doing the thinking until the thinking is good.
**This article is published as part of the Foundry Expert Contributor Network.**Want to join?