Mentoring junior engineers in the age of coding agents

A decent amount of digital ink has been spilled about the future of software engineering in light of increasingly powerful coding agents. Will software engineers, especially junior ones, be able to find jobs in the future as coding agents become more powerful? I’m not a futurist, so I’ll make some observations informed by my own increasingly productive use of coding agents like Claude Code and Aider:

• Today’s best coding agents still very much require a human operator,
• To effectively use these coding agents in a professional context, you have to make some big changes to how you work, and
• There are many elements of professional software engineering that coding agents don’t meaningfully enhance.

If you agree with these observations, then you agree that humans will play a critical role in software engineering in a professional context for years to come. And, as Camille Fournier explains, in a world where there are software engineers, we’ll see the spectrum of junior, mid-level, and senior engineers at any healthy company. So rather than worry about the existential risk to our field, let’s focus on continuing to build a healthy career pathway for engineers of all levels of seniority. I’m particularly interested in bolstering the beginning of a software engineer’s career: how should junior engineering mentorship change in light of coding agents?

Since these tools turn portions of the role from coding-heavy experiences to prompting-and-reviewing-heavy ones, it’s important for the mentorship model for junior engineers to more quickly introduce them to writing up high-level task descriptions and performing code review. This is pretty different from the junior engineering mentorship models I’ve experienced, which tend to delay the introduction of more complex task definition and code review skills. To support junior engineers who are learning these new tools, we’ll have to change that.

In this post, I’ll do three things:

• Explain my (and B12’s) pre-AI mentorship model for junior engineers,
• Identify task definition and code review as two skills we need to emphasize sooner in the mentorship model, and
• Talk a little bit about how we might mentor for those skills sooner.

Junior engineering mentorship in the pre-AI era

To understand how we might improve mentorship for the era of coding agents, I’ll outline how we (still) think about the growth of engineers at B12. I make no claims that this is the best way to offer junior engineers mentorship, but the outline can help show where there are gaps for the coding agent era. We introduce junior engineers to the following list of skills/experiences in roughly chronological order, though we very much adapt it to the skills and experiences an engineer already has on joining the company:

1. When an engineer joins with close to no industry software engineering experience, we give them bite-sized tasks that are planned and specified by a more senior engineer. These can be bugs or mini-features, but importantly the engineer’s focus is on turning a high-level and reasonably detailed description into code while they learn the mechanics of our tools, codebase, and workflow.
2. As they become familiar with our engineering practices and more comfortable with our codebase, we increase the complexity of their tasks, and over the course of a few projects ramp them up to implementing multi-step technical specifications that a more senior engineer or product manager wrote. As we increase complexity, the engineer hits learning opportunities in either working on a task that’s not well-defined enough or in submitting work for review that’s not refined enough. We appropriately recommend that they write up some details and get feedback before they start an underspecified task, or suggest that they review their own code before submitting it for another person to review.
3. As an engineer becomes comfortable writing up small tasks for themselves, we increase the scope of the tasks they have to describe until they are writing full multi-page plans for complex features. This work naturally transitions from “write a plan for yourself” to “write a plan that 2+ engineers can work on,” which comes with its own complexities. We’ve also increasingly experimented with spending some time building/exploring a prototype and writing up a less involved plan for production-hardening the prototype afterward. Nonetheless, the goal here is to get an engineer comfortable coming up with a plan for themself and others with decreasing amounts of guidance.
4. As the scope of the engineer’s tasks grows, the scope of the code they understand grows as well, and we have the engineer review pull requests and technical specifications created by other engineers. This is most straightforward when another engineer is implementing a component of a project that the junior engineer planned, but as they get more experience reviewing, they can review another engineers’ work on projects and parts of the codebase with which they have less familiarity. To ease them into this, we start them off as “shadow reviewers,” where they review a pull request and then another engineer also reviews it. This gives the junior engineer comfort that they aren’t the only reviewer and allows the second more senior engineer to be able to give feedback on the review the junior engineer left.

The maturity model above is nonrigid, and serves more as a set of skills and levels of comfort we look for as an engineer’s projects increase in complexity and decrease in up-front specification.

Two skills we introduce too late for the AI-assisted era

The model above works well in helping engineers gain experience in thinking critically about their own work and the work of others. In the model, there are two skills that are purposefully introduced near the end of this stage of the junior engineer’s growth, often taking a few years to hone and strengthen: writing up tasks, and reviewing code.

Task definition

Depending on the complexity of the task, it takes years to feel comfortable taking a high-level description of a goal, decomposing it into several subtasks, and describing them in a way that someone other than yourself can complete them. Task decomposition, especially in the face of legacy code and migrations, is a practice that even senior engineers appreciate having some amount of thought partnership and coaching on. Figuring out how to provide enough context in a writeup to enable someone less familiar with the codebase than you to take on a task is yet another skill that takes some time to hone.

Generally, anything more than AI-powered tab completion requires you to pass a meaningful task description and context clues to an agent. The more detailed your description, the more likely it will meet more of your expectations in a few shots. This means that one of the last things we introduce junior engineers to in the traditional mentorship model is the very first thing the engineer needs to tackle when starting off with a coding agent.

One saving grace is that, assuming you have tests and version control, there’s a pretty quick feedback loop on bad task definitions. After a delay, the agent will produce a diff or PR, and if it’s not to your liking, you can either request modifications or start from scratch. So if writing up better and better task descriptions is something that takes practice, bad coding agent outputs are at least self-reinforcing and self-correcting. However, the definition of “not to your liking” leads directly to the next issue: good code/architecture/… review skills are neither self-correcting nor self-reinforcing.

Code review

While we encourage early career engineers to review their own code before submitting a pull request, we take our time on having them review the work of others. This is in part because we want them to have a lot of uninterrupted time in picking up the codebase and the mechanics of professional engineering practices, but also in part because reading someone else’s code (especially in codebases you aren’t as familiar with) is a skill of its own. When we eventually ask junior engineers to code review other engineers’ work, we find that the review initially tends to be shallower and focused on nitpicks, or that they ask questions about design decisions but don’t evaluate answers as critically as they should. Since another engineer is also reviewing the same PR initially, these make for excellent learning opportunities.

Whether or not you code review the output of an LLM feels definitionally the difference between “vibe coding” and “coding with a desire for a lasting and maintainable code base.” A bad task description will lead to a feature that doesn’t work, and you’ll try again. A bad or nonexistent code review will lead to bugs, architectural issues, untested code, and too many abstractions of the wrong kind/too few abstractions of the right kind. A lack of introspection and care with code review is a compounding problem: the more you vibe your way through the work of an AI, the more downstream debt and maintainability issues you’ll be taking on down the line.

Since today’s coding agents take a task definition and produce entire PRs or large portions of them, the junior-senior code review skillset gap is made clear the first time you use these tools. On day 0 of using a coding agent, the subsequent code review spans multiple files, test cases, architectural decisions, and refactors. Junior engineers therefore need experience and advice on performing these reviews way closer to day 0 than year 1 or 2.

What mentors might do about it

Junior engineers that use coding agents now need to be good at defining tasks they won’t be implementing and reviewing code they didn’t write against architectural decisions they at best hinted at. As senior engineers or managers, what can we do to help them pick up those skills more quickly? Here are a few ideas, with the caveat I’m still working through these tools’ sharp edges for myself, and have had few opportunities to introduce them to junior engineers. This last section is the most speculative and least developed of the post, despite covering the most important topic for helping mentees ramp up while maintaining the health of your codebase. I’d love to hear from and amplify people who have mentored junior engineers in the era of coding agents.

• Share some prompt/agent session transcripts with the team. Just like we can learn from reading someone else’s code, we can learn quite a bit by reading someone else’s prompts. Reading tips and tricks on how someone interacts with coding agents is helpful, and given how new the field and tools are, it’s likely broadly useful to the whole team. Having some lunch-and-learn sessions or wiki pages where people can share examples of prompts and commits that came from those prompts could help everyone, including junior engineers, improve their task definition experience.
• Discuss common gotchas. It might be ephemeral, but I’ve seen the coding agents I use fail repeatedly in very specific ways. They repeat the same exact block of code throughout codebases they generate. They correctly cover the control flow in a test, but don’t create every assertion you asked for (or don’t write tests even though you prompted them to). They reference older versions of libraries/APIs given their training cutoff. They change the goal in the face of multiple test failures and declare success prematurely. Knowing these patterns of mistakes makes us all better reviewers, so introduce some way to share these patterns across the team, especially with less experienced reviewers. Perhaps it’s more lunch-and-learns or wiki articles, or perhaps you can name these issues when you spot them so your mentee learns to look out for them over time.
• Double down on your own code reviews. Code review is controversial both as a quality assurance tool and as a mentorship tool. Since I find it helpful for both, I’m biased toward thinking it continues to be helpful in reviewing the work of an engineer and agent they paired with. You only interviewed the engineer, so your extra set of eyeballs is even more useful in preventing the an agent from introducing unideal code and architecture. Since any feedback on the code is also feedback on the engineer’s own review of the agent’s work, you’re inherently also helping reinforce what they should have caught earlier in their process.
• Shadow code review sooner. Shadow review is the only tool in our traditional mentorship toolkit that allows a senior engineer to give feedback on how a junior engineer gave feedback. To the extent that you specifically want to strengthen the “giving feedback on code you didn’t write” muscle sooner, performing shadow reviews sooner allows you to observe and give metafeedback earlier in the junior engineer’s tenure. I’m not sure how necessary or beneficial this is if you’re already code reviewing the work of the engineer, but it’s certainly a more direct way to observe and discuss the skill.

Despite the speed at which the world of coding agents is moving, I’m pretty confident that the task definition/code review skills gap will remain relevant. The skills we previously delegated to senior team members are now required on day 0 of using a coding agent. If you’ve thought hard about mentoring junior team members through this change, I’d love to hear from you!

All mistakes are my own. A coding agent was working in the background on my side project, but an LLM hasn’t touched this blog post as of its publication :). Thank you to Hunter Knight for reading an early version of this post.