Shaping Engineers in the Age of AI

This is the story of how AI coding agents changed the informal way we teach engineering on the job, and what we can do to keep turning juniors into seniors.

For years I’ve worked together in mixed teams of developers with different levels of experience with the technologies at hand. It was part of the job of seniors to oversee the projects more holistically and pick suitable tasks for juniors that are just challenging enough to let them learn and grow. Design discussions and reviews were routine tasks that could be done in acceptable time. That loop of small tasks and quick feedback was how juniors slowly turned into seniors.

With coding agents, a single pull request with 1,000+ lines and a detailed, AI-written description is no longer unusual. My first reflex was to reject reviewing something that size. But that isn’t feasible: we still want to ship the feature. So I found myself writing agent skills to automate the review and “fight back” with the same weapons. Quickly the review discussion turned into a battlefield between bots rather than communication between colleagues.

A giant, AI-generated pull request: a validation summary claiming issues fixed with dozens of new unit tests, a large diff across many files, and an even larger companion PR with hundreds of changed lines

Of course, I adapted my review style, focusing more on a higher level, about the feature engineering and the architecture decision aspects. But it doesn’t feel efficient. Reviewers appear too late in the (short) process and spend too much time, and contributors are constrained by the reviews. And the learning purpose of reviews is weakened.

The “Just Hire Seniors” Trend

That’s what triggers the temptation to work more with seniors who don’t need this much guidance in the first place, but bring a team of agents. If we do that, where will the future seniors come from?

This trend is often discussed in the industry, and it has actually been substantiated by studies:

Percentage change in tech new hires by seniority, 2023–2024: entry-level hiring fell ~25% at Big Tech while mid- and senior-level hiring rebounded Source: SignalFire, State of Tech Talent Report 2025

That’s a serious trend for the economy, but also for individual companies: if they think strategically, they need a new mechanism for building up experience and growing their next generation of engineers.

The Channels That Used to Work for Training on the Job

What surfaces as a change in review culture and hiring trends has deeper implications. Much of the education in the software engineering industry has been part of the day-to-day business in companies. After university, developers should have a strong theoretical fundament and some practice in writing code. But to become a senior they need more, such as a feeling for the hardships of debugging and maintaining a badly designed system or practice in the collaborative culture of a development team.

A couple of channels have typically been used to transfer this knowledge:

  • Costaffing with seniors on a project. The senior would do normal development and architecture work and, as a side task, supervise juniors working on small subtasks. This option is broken, because a task of suitable size to fill a day has become too complex when an AI agent is at hand. It’s no longer a side task to supervise this work.
  • 1:1 coaching. This is still very useful, but requires a lot of time and effort from the mentor. Or it stays superficial.
  • Pull requests and review sessions, the unique process we have in software engineering. These are no longer effective as a learning method, because the reviewer is too late in the process and it became much harder to analyze changesets which always “look good” with their AI generated code and documentation. And the author may not even use comments in the same way, because it is just possible to feed a programming agent with the comments to get a fix.
  • Participation in architecture discussions in the development team. This would still be useful. But my personal observation is, that they happen much less, now that developing a whole service or app has become the job of a few days.

Aside from this, there are dedicated learning programs, such as Facebook’s Bootcamp mentors. But I would count those rather as an onboarding process than as a way to grow engineers throughout the career.

A common instinct today is to assume that calling everyone back to the office restores this kind of learning automatically. It doesn’t work quite like that. In the past, the proximity mattered because the work itself was shared. If people work on larger and more complex codebases, the first one to ask is your AI agent, not the colleague next door. There’s still a social component to being there, but a much smaller learning effect than before, because the thing that actually taught people (working the same problem, in the same code, at the same time) is missing.

What Companies Are Trying

Companies are already reacting to agents in their training methods. Some examples:

  • IBM deliberately gives new grads harder assignments sooner. An agent implements and tests the code; if it fails, the junior’s job is to diagnose what went wrong and fix it before a senior signs off. IBM estimates agents now handle 70–80% of some tasks that used to require a senior, so the junior’s role shifts from typing to diagnosis.
  • Anthropic kept its onboarding buddy system but reframed it as purely social (how the team works together, who to ask what), because technical onboarding now largely happens by working with Claude directly. Shipping code in week two is treated as a red flag, not a win, since it suggests too little time was spent acquiring context first.
  • Meta kept its unchanged six-week Bootcamp, and layered a new six-month “Elevate Eng Talent” program specifically to teach early-career engineers the company’s internal AI tooling: the same container, running new content.
  • From Microsoft’s orbit comes a different kind of proposal: dedicated “preceptors”, senior engineers entrusted with training as their actual job, described by Mark Russinovich and Scott Hanselman in “Redefining the Software Engineering Profession for AI”. I’ll build on this idea below.

My Proposal: Every Junior Gets a Preceptor

I would like to build on the idea by Russinovich and Hanselman to describe my vision of how it could work in practice. The idea is, to have a formally assigned preceptor, a trained mentor whose main job it is to grow new practitioners, not to produce software artifacts. Hanselman expanded on the idea further in an InfoQ podcast conversation, which is what got me thinking about this topic in the first place. Here’s how I envision this model could work.

The Working Relationship

Every junior is assigned a preceptor. Not “ask around if you’re stuck”: a named senior with an ongoing, explicit responsibility for that junior’s growth.

The preceptor’s job is to teach reasoning with an agent, not to review output after the fact. The focus is judgment: how to scope a task before an agent touches it, how to challenge an agent’s plan before it writes any code, how to recognize a masked bug, e.g., an agent “fixing” a race condition with a sleep() call instead of the underlying synchronization.

Peer architecting and coding happens with agents, not “junior codes alone, senior reviews later.” Preceptor and junior sit together and jointly direct the agent: deciding what to prompt for, pushing back on its plan, debugging together when it gets something wrong. This is where the actual transfer of judgment happens: at the moment a decision gets made, not a week later staring at a 1,000-line diff.

Concept sessions are things built together, not code reviews. Instead of relying on review comments to teach a standard or a pattern, preceptor and junior deliberately build something together specifically to teach it. The teaching is the exercise, not a side effect of reviewing someone else’s finished work.

The Organizational Layer

Preceptors are not regular seniors: they have a dedicated role with main responsibility for teaching and mentoring.

A preceptor takes on at most 4 or 5 mentees, not more. It’s an investment, not overhead: get this ratio right and the juniors become productive quickly, paying the time back many times over.

Preceptors build the curriculum for their organization. They need to decide which architectural concepts, which standards, and which failure modes a junior needs to learn. This is much more than a checklist inherited once from onboarding docs.

All of this needs dedicated time and a real mandate. A preceptor’s success should be measured by whether their junior is gaining independent judgment, not by the preceptor’s own shipped output. If it isn’t staffed and budgeted, it will always lose to the sprint.

Back to the Reviewer’s Dilemma

With a model like this in place, that giant, opaque, agent-generated PR from the beginning of this post wouldn’t arrive as a surprise at review time. The junior and their preceptor would have scoped the feature and directed the agent together from the start, so the “review” is really the conclusion of a conversation that began before any code existed, not the first time a senior sees the work.

This is a process I imagine would be enjoyable for both sides. It would strengthen the bond between juniors and seniors again, and repair the delivery pipeline for companies that want to think strategically and keep hiring and growing young engineers.

References

devops   teams