How did junior engineers traditionally become senior?

By writing a large volume of code and having an experienced person examine it closely, repeatedly, for several years. The learning came from having to defend decisions they had made themselves and from discovering they were wrong about something they had been confident in, which is a specific experience that repetition alone does not produce.

Why do agents break the path from junior to senior?

Because the junior engineer's role shifts from producing a decision to accepting one, and accepting teaches very little. The moment that built judgment was never the typing, it was having to choose an approach, commit to it, and then be shown a consequence of that choice they had not anticipated.

How long before the problem becomes visible?

Usually more than a year, which is what makes it dangerous. Output rises immediately and tickets close faster, so the early signals all look positive, and the gap only appears when someone holding a senior title is handed an unfamiliar production failure and has no experience of similar problems to use.

What is the practical fix for teams using agents heavily?

Separate delivery work from learning work explicitly and label which is which. Delivery work runs with tools on and optimises for delivering, while a smaller set of learning tasks runs deliberately slower with tools off, and the ticket says so in advance rather than leaving the choice to the individual.

How should code review change for junior engineers using agents?

Shift the questions toward reasoning, because the diff alone no longer tells you who decided what. Ask why the code is shaped that way, what fails under ten times the load, and what happens when a dependency times out, since a candidate who cannot answer did not actually make the decision.

Why is debugging the best teaching material available?

Nobody learns a system faster than the person responsible for fixing it while it is broken. Debugging forces a mental model of how the parts connect, and unlike a tutorial it cannot be completed by pattern matching, because the failure is specific to your system on that day.

Should junior engineers be banned from using AI tools?

No, because that trains a working method the industry has already moved past and it will not help them get hired. The workable version is scheduled practice without tools on a small share of work, framed openly as skill building rather than as a restriction or a punishment.

What skill matters most for engineers entering the field now?

Specifying what correct means and building checks that prove it. That work cannot be delegated to the thing being checked, it survives every change in tooling, and it forces the precise thinking about unusual cases and failure modes that used to come from writing implementations by hand.

How do you tell whether a junior engineer is actually learning?

Ask them to explain a decision in code they submitted a week earlier, without looking at it first. Recall of the reasoning is a reliable signal, because a person who genuinely made the choice remembers the alternatives they rejected while a person who accepted a suggestion usually cannot reconstruct them.

Does this change how many junior engineers a team should hire?

It changes what the team must commit to rather than the headcount. A junior hire now requires a deliberate development plan and senior time set aside for it, so a team that cannot fund that attention should be honest that it is hiring for output rather than growing anyone.

What happens to senior engineers in this arrangement?

Their time moves further toward specification, review of reasoning, and teaching, which are all harder to schedule than writing code. The risk is that the teaching work stays invisible in every productivity measure, so it gets dropped first whenever a deadline gets closer.

What changes when your junior engineers use agents: Reveneau

A question we get asked more often than any other right now, usually in a quieter voice than the rest of the conversation: what happens to the junior engineers?

The honest answer is that something specific and well understood is being stopped, and most teams have not noticed because the metric it affects does not show up for about eighteen months.

Here is what is being stopped. For a long time, the way from junior to senior depended on one cycle: write a lot of code, have someone experienced criticise it in detail, feel the particular discomfort of being wrong about something you were sure of, do it again. Four years of that produces a person who can look at a design and say "this will cause problems in about six months" without being able to fully explain how they know.

The cycle stops when the agent writes the first draft. The junior engineer's job moves from producing a decision to accepting one, and accepting teaches almost nothing. The learning was never in the typing.

Why nobody catches this early

Every early signal looks good. A junior engineer with a good agent closes more tickets in their first month than one did in their first quarter a few years ago. The code is often better than what they would have written alone. Reviews go faster. On any dashboard you have, the picture improves.

What is missing does not appear on a dashboard. It is the accumulated set of times you were confident and wrong, which is what judgment is built from. If you skip that, you end up somewhere that looks similar from outside and behaves very differently under pressure.

There is a related finding worth thinking about. METR's July 2025 study of 16 experienced open-source developers working on their own repositories found them 19 percent slower with AI tools, while expecting to be 24 percent faster and believing afterwards that they had been 20 percent faster. Experienced people, on code they knew well, misread their own performance by roughly forty points. If that is the accuracy of expert self-assessment, a junior engineer has no realistic way to notice their own learning gap. They will feel productive, because they are producing. Somebody senior has to notice for them.

The 2025 DORA report, drawn from around 5,000 respondents, puts the general version of this well: "AI doesn't fix a team; it amplifies what's already there". A team with a real mentoring practice gets more benefit from its mentoring. A team where development happened by accident now gets no development at all, faster.

So it has to be built on purpose. Four things we have seen work.

1. Say out loud which mode a task is in

Some work is delivery. Tools on, move fast, release it, and nobody should feel guilty about that.

Some work is practice. Tools off or heavily limited, slower on purpose, and the point is the engineer's learning rather than the ticket.

The mistake is leaving that choice to the individual, because in a delivery culture the individual will always pick delivery, and they are right to. Put it in the ticket. "This one is a learning task, expected to take three days instead of one, do not use the agent for the core logic." That sentence removes the ambiguity and the guilt at the same time.

A reasonable starting ratio is one task in five, on work that is real but not urgent for the schedule. It has to be real work; practice problems do not have the same effect, because nothing is at stake and nobody argues with you about the result.

2. Review the reasoning behind the diff

Code review used to serve two purposes at once: catching defects, and teaching. When the code arrives generated, the second purpose quietly disappears unless you rebuild it deliberately.

So change the questions. Why is it shaped this way? What breaks at ten times the load? What happens when that call times out? Which of these two approaches did you consider and reject, and why?

An engineer who made the decision can answer. An engineer who accepted a suggestion usually cannot reconstruct the alternatives, and that is exactly the diagnostic you need. It is not a trap, and it should not be run like one: say in advance that this is how reviews work here, so people prepare by actually understanding the code before they submit it. That preparation is most of the benefit.

Our general standards for this are in what good code review looks like and the AI-specific version is in how to review AI-generated code.

3. Give them the debugging

This is the highest-value teaching material any team owns, it is free, and most organisations hand it to the wrong person.

The instinct during an incident is to give it to whoever will resolve it fastest. That instinct is correct at three in the morning and wrong at eleven on a Tuesday. Nobody learns a system faster than the person who has to fix it while it is broken, because debugging forces you to build an accurate model of how the parts actually connect, rather than how the diagram says they do.

It also cannot be completed by pattern matching. Every real failure is specific to your system on that day, which is precisely why it teaches. Pair a junior engineer with someone experienced, let the junior lead, and have the senior ask questions instead of taking the keyboard. That last part is the hard bit and it is where the value is.

Stack Overflow's 2025 survey found 45.2 percent of developers saying that debugging AI-generated code takes more time than writing it themselves, which is a fair description of the coming decade of work. The team that trains this skill deliberately will be much better off than the team that hopes it appears.

4. Make them write the checks before the code

Specifying what correct means is the one skill that cannot be delegated to the thing being checked, and it is the skill that survives every future change in tooling.

It also happens to force exactly the thinking that writing implementations by hand used to force. To write a check you have to decide what the unusual cases are, what the failure modes look like, what the system must guarantee, and what "done" means precisely enough that a machine can judge it. That is engineering judgment, reached by a different method.

Start a junior engineer's task with the checks, reviewed by someone senior before any implementation exists. Then let them use whatever tools they like for the implementation, because at that point the tools are working against a definition the person actually understands. The method is in how to write your first eval suite, and the ways this goes wrong are in when evals give false confidence.

What this asks of the senior engineers

More than most teams have budgeted for, and in a form that is hard to schedule.

Senior time moves toward specification, reasoning review, and teaching. All three are slow, none of them produce a visible artefact, and every one of them is the first thing dropped when a deadline gets closer. If teaching is not written into someone's role and protected, it will not happen, and the shortage of experienced engineers three years from now will have been caused by one deadline after another.

That is also why we think a junior hire is now a commitment rather than a headcount decision. If a team cannot set aside real senior attention, it should say honestly that it is hiring for output rather than growing anyone. Both are legitimate. Confusing them is not. Related thinking is in onboarding engineers quickly and measure engineers by outcomes, not output.

Thanks to the engineering managers who raised this with us before it became a problem they could measure. Every one of them described the same uneasy feeling: the work is getting done, and something else is not.

The tools now do the typing. Nobody is responsible for the learning yet, and someone needs to be.

Related guide: Onboarding engineers quickly.

Sources

METR, early 2025 AI experienced open-source developer study, July 2025: 16 experienced developers were 19 percent slower with AI tools, having expected to be 24 percent faster and believing afterwards they were 20 percent faster.
2025 DORA report announcement, Google Cloud: around 5,000 respondents; AI amplifies a team's existing strengths and dysfunctions.
Stack Overflow 2025 Developer Survey, AI section: 45.2 percent say debugging AI-generated code is more time-consuming than writing it themselves.

What changes when your junior engineers use agents