Junior engineers have traditionally learned through a mixture of routine implementation, code review, observation, and gradually expanding responsibility. When agents perform more routine work, organizations must preserve the experiences that build judgment.
Do not remove the learning gradient
Routine tasks often teach repository structure, failure modes, testing discipline, and the cost of imprecise assumptions. If an agent performs the task, the learner still needs to inspect the plan, predict risks, review the output, and explain the evidence.
The task can be accelerated without removing its educational function.
There is evidence for the risk, with a narrow scope. In Anthropic’s randomized coding-skills study, 52 participants learned an unfamiliar Python library. The AI-assisted group scored 17 percentage points lower on the immediate quiz; its speed advantage was not statistically significant. Explanation-seeking usage was associated with better understanding, although those usage patterns were not separately randomized. This is evidence about one learning task, not a forecast of an engineer’s career.
Anthropic’s later Economic Index survey found that many users felt they were learning more, including frequent delegators. Self-reported learning and demonstrated retention measure different things. Design practice that uses AI’s teaching value and checks what the learner can transfer to a new problem.
Design progressive authority
A useful progression moves from observing, to proposing, to executing with review, to owning bounded decisions. The boundary should expand based on demonstrated judgment and risk, not merely tenure or volume of generated code.
Mentors should name the decisions the learner is expected to own at each stage.
Make expert reasoning observable
Pairing and review should reveal why an experienced engineer asks a question, distrusts a test, or stops an apparently successful change. Thinking Out Loud and annotated examples provide material that asynchronous teams can revisit.
Learners also need live dialogue for sensitive feedback and fast challenge.
Evaluate understanding directly
Completion is weak evidence of learning when an agent can produce the artifact. Ask the learner to explain constraints, compare alternatives, design verification, diagnose a failure, and adapt when assumptions change.
These exercises measure transferable judgment rather than tool fluency.
A progression with observable decisions
Use the fictional Northstar retry change as a learning task. The learner’s responsibility increases with demonstrated judgment, while production authority remains separately assigned.
| Stage | Learner owns | Mentor looks for |
|---|---|---|
| Observe | Explain the accepted contract in their own words | Correct scope, non-goals, and uncertainty. |
| Predict | Propose tests before seeing the patch | Cases that distinguish competing interpretations. |
| Prepare | Direct a sandbox implementation | Bounded scope and truthful evidence reporting. |
| Challenge | Review another implementation | Ability to find a race or unsupported assumption. |
| Own a bounded change | Assemble a complete review packet | Appropriate escalation and a defensible decision. |
These stages are not job levels or a promotion calendar. An experienced engineer entering an unfamiliar domain may need more observation than a junior with strong local knowledge.
Test understanding by changing the problem
After the learner explains account-scoped deduplication, ask what happens if the request spans two databases or calls an external payment provider. Do not grade them on inventing the perfect distributed protocol. Look for recognition that the original atomicity assumption no longer holds and that new authority and evidence are needed.
Ask them to identify a test they would not trust and explain why. A learner who can describe the limits of passing tests is showing judgment that generated output alone cannot demonstrate.
AI remains available as a tutor and exploration tool. For the assessment, make tool use explicit and ask the learner to defend the final reasoning, including what they accepted or rejected from the tool. Occasional unaided explanation can reveal gaps without turning the program into a ban on assistance.
A team can extend this into a shared experiment: a protected period, perhaps one afternoon, with AI set aside so people trace the code, sketch the design, or form a hypothesis before asking for one. Safeguards keep it from becoming a ban. Accessibility tools stay available, and nobody has to disclose a need to keep them. Incident and urgent customer work is exempt. Nobody monitors who used what. After a few weeks, hold a retrospective that asks where the restriction added nothing as well as where it helped. The test for each participant is “which parts of this effort are developing something I want to keep?” Effort that builds no lasting capability does not become valuable because it is slow.
Fund the teaching
Choose a manageable mentoring commitment with the team instead of adding unlimited review work to the same senior engineers. For a small pilot, reserve one focused session and one asynchronous review per learner each week, then adjust based on workload and usefulness. This is an example schedule, not an evidence-based universal dosage.
Rotate suitable mentors and retain a few consented, sanitized examples. Do not reuse a recording as a substitute for someone being available to answer questions.
At a review point, compare the learner’s decisions on a new task with their earlier work. Have they become better at noticing uncertainty, selecting evidence, and escalating? If output increased but these abilities did not, redesign the learning task and agree on the next responsibility they will practice.