An agent can now finish in minutes the work that used to take a junior engineer half a day.
The productivity ledger records the hours saved. It does not record what used to happen inside those hours.
The junior read unfamiliar code. They formed a wrong theory about how it worked. A test contradicted them. A senior rejected the first version and explained the boundary they had missed. The junior tried again. The feature shipped, but that was only one of the outputs. The other was an engineer who understood the system a little better than they had that morning.
When an agent does the work invisibly, the feature may still arrive. The second output does not.
I have been circling this problem for months. In April, after building a design system in two hours, I wrote that AI did not threaten the best designers. It threatened the work that helped beginners become good enough to join them. The line I used was blunt: The craft survives. The on-ramp does not.
At the time, I said I did not know how to solve it.
I know more now. The answer is to recognize that entry-level work had two jobs, production and development, then redesign the development job before automation removes the production one. Preserving junior work in amber does not get there, and neither does assigning repetitive tasks a machine can complete safely. Toil does not become noble because it used to be manual.
If execution is becoming abundant while judgment remains scarce, the system that produces judgment is critical infrastructure, not a side concern.
The work had two outputs
Most automation business cases count the artifact and ignore the apprentice.
A ticket closes. A test suite passes. A dashboard ships. A migration finishes. Those are visible outputs, easy to count and easy to price.
The invisible output was capability. Someone learned where the sharp edges were. They saw a clean abstraction fail against an ugly production constraint. They learned that a green test suite can still encode the wrong expectation. They sat through a review in which a staff engineer asked a question that looked pedantic until the incident six months later made it look prophetic.
Engineering organizations rarely designed that learning system deliberately. We got it almost by accident. Juniors received bounded work because they could safely do it. They made mistakes because they were new. Seniors reviewed those mistakes because the code had to ship. Repetition and correction slowly turned rules into pattern recognition.
The arrangement was imperfect. Some junior work was genuinely developmental. Much of it was just toil with a career ladder attached. Nobody needs to spend three years hand-writing boilerplate to develop character.
But the distinction matters:
We should automate toil aggressively. We should stop pretending that all low-level work is toil.
Some apparently routine work teaches the shape of a system. Debugging a failed integration teaches more than reading its architecture diagram. Writing a first implementation forces assumptions into the open. Responding to a production alert connects code to consequence. A first-pass code review teaches what experienced engineers notice and what they miss.
Remove the task and you may remove drudgery. Remove the feedback loop and you remove the apprenticeship.
A task becomes an apprenticeship when prediction, feedback, explanation, and increasing independence are designed into the work, not merely because a junior performs it. Without those conditions, leaders can relabel any unpleasant task as development and preserve toil under a better name.
The productivity calculation has to know which one it is doing.
The early evidence is uncomfortable
This concern is no longer purely theoretical.
In a 2026 randomized study, developers learned an unfamiliar asynchronous programming library with or without AI assistance. The AI-assisted group scored 17 percent lower on a test of concepts they had just used. The small speed improvement did not reach statistical significance. The worst learning outcomes came from people who delegated the task most completely. Participants who used AI to ask conceptual questions, request explanations, and test their own understanding retained more.
The study was narrow and short-term. It does not prove that AI makes engineers worse, and its authors do not claim that. It shows something more useful: the interaction pattern changes the learning outcome. AI can be a tutor, a collaborator, or an escape hatch from thinking. The workflow and incentives decide which one shows up.
Another 2026 analysis looked at roughly 400,000 Claude Code sessions. It found that people still made most planning decisions while the agent made most execution decisions. Greater domain expertise correlated with higher success and with getting more useful work from each instruction. The data shows that expertise still matters. It does not answer how the next generation will acquire it.
A separate longitudinal survey found the job itself moving in the same direction. Eighty-two percent of participants reported spending less time writing code, while more of the work shifted toward directing, evaluating, and correcting AI output. The researchers called the emerging category supervisory engineering work. That sounds like progress until you ask where a new engineer learns to supervise.
Put those findings together and the apprenticeship problem becomes visible.
The skills that make agentic work successful are still human skills: understanding the domain, framing the task, recognizing a bad turn, and knowing what evidence deserves trust. But the work through which people historically developed those skills is precisely the work agents are beginning to absorb.
We are automating the practice field while increasing demand for better players.
The old ladder broke before the new one existed
The old path was inefficient, but it was legible.
You wrote a lot of code badly, got corrected, and wrote less code badly. You debugged systems you did not understand while sitting beside someone who did. You took incident calls and discovered that the elegant diagram left out the part that wakes people at two in the morning. Eventually you accumulated enough scars that certain failure modes began to feel obvious.
That path produced uneven results, and it excluded plenty of capable people. I am not nostalgic for it.
The problem is that many organizations are replacing it with no path at all.
A junior can now produce a senior-looking artifact before developing a senior mental model. The pull request is tidy. The explanation is confident. The tests are green because the same system that misunderstood the requirement wrote the tests around its misunderstanding. Plausible output arrives before comprehension.
The senior still catches the problem because the senior has seen the movie before. Then the senior fixes the prompt, reruns the agent, and moves on because delivery pressure is real. The code gets better. The junior learns almost nothing about why.
Run that loop often enough and the organization gets faster in the quarter while becoming less capable over the decade.
The two common responses both miss the point.
One is to let juniors use agents for everything because AI fluency is the new baseline. That produces output, but without deliberate friction it can outsource the exact cognitive work the apprentice needs.
The other is to ban AI for junior engineers until they have learned the fundamentals. That protects an old curriculum for a world that no longer exists. It trains people to perform work manually while their future job is shifting toward directing, evaluating, and correcting machines.
The real choice is whether learning remains an accidental byproduct of production or becomes an explicit part of the operating model.
Production mode is not learning mode
The deeper mistake is asking one workflow to optimize two different things without saying which one matters.
Production mode should optimize for a verified outcome. Delegate aggressively when the work is bounded, the answer key is strong, and the task has little developmental value. If an agent can complete a routine dependency update safely, nobody needs to retype it for educational theater.
Learning mode should optimize for cognitive ownership. Make the apprentice predict, choose, diagnose, and explain before the agent reveals the answer. Slow the reveal. Require a testable prediction. Preserve the moment when the learner has to commit to what they think the system will do.
The tool can be the same. The contract cannot.
If the mode stays implicit, delivery pressure will choose production every time. The ticket will close, the dashboard will improve, and the organization will discover much later that speed consumed the practice it depended on.
This does not mean every ticket must carry a lesson plan. It means leaders should know whether a workflow is harvesting capability, building capability, or intentionally doing only one of the two.
Judgment is not a seniority badge
I define judgment as the ability to combine context, evidence, consequences, and accountability when the rules are incomplete.
That capacity is compressed experience, not intuition granted by title. It comes from making decisions, seeing what happened, receiving correction, and updating the model in your head.
This changes what apprenticeship should optimize.
The junior does not need to type every line the agent could produce. They need to own enough of the reasoning that a wrong line creates dissonance. They need to predict what should happen before the test tells them. They need to identify the invariant before asking the model to repair the symptom. They need to practice deciding what good looks like, then compare that decision with reality and with someone more experienced.
That still requires contact with the machinery. An engineer cannot learn to supervise a system entirely from summaries of what the system did. Before delegating a capability completely, they need enough direct practice to decompose a problem, trace behavior through unfamiliar code, design a meaningful test, debug a failed assumption, and explain a causal chain without borrowing the agent's explanation. The required amount will vary by domain and consequence. The requirement itself should not.
In The Spec Is the Product, I argued that spec review is becoming the new code review. The apprenticeship model has to move with it. Pairing on code still matters, but pairing on frames, specifications, evaluations, and release decisions is where more of the learning now belongs.
The unit of apprenticeship is shifting from the keystroke toward the decision, but decisions still need contact with the machinery they govern.
The thing worth protecting is understanding, not typing.
A new apprenticeship loop
If I were designing an agentic apprenticeship for an engineering organization today, I would build it around six moves.
1. Frame before generation
Before the agent writes anything, the apprentice writes the problem frame.
What behavior must change? What must remain true? Which assumptions are being made? What evidence will prove the work is complete? What is the most likely way this request is misleading?
The senior reviews that frame before reviewing any generated code. This moves mentorship to the point where misunderstanding is cheapest. It also keeps the apprentice from inheriting the agent's first interpretation as if it were a fact.
The deliverable is a visible reasoning surface a senior can correct, not a perfect specification.
2. Review before reveal
The apprentice should perform the first review without seeing the senior's assessment.
Ask them to mark the risky assumptions, identify missing tests, explain the change in their own words, and state whether they would approve it. Only then compare their review with the senior's.
That comparison is the lesson. Where did the two reviewers agree? What did the senior notice first? What did the junior notice that the senior missed? Which signal was real, and which was noise?
If the senior reviews first, the apprentice learns the answer. If the apprentice reviews first, they practice producing it.
3. Diagnose before regenerating
When agent-generated work fails, do not immediately ask the agent to try again.
First require a diagnosis. What assumption was wrong? Which invariant was violated? Was the failure in the implementation, the specification, the context, or the answer key? What new test would fail for the right reason?
Regeneration makes fixing cheap. Diagnosis turns the failure into knowledge.
The rule should be simple: no retry without a prediction. Name the suspected invariant, the evidence that would falsify the theory, and the test that should change if the diagnosis is right.
4. Manufacture practice, not answers
The machine removing the old practice field can help build a better one.
Give an agent a production incident and ask it to release the evidence in stages. Ask it to generate three plausible pull requests, each wrong in a different way. Let it hide one violated invariant inside an otherwise clean change. Give the apprentice an ambiguous specification and make them find the questions the agent should not answer yet.
AI can create counterexamples, incident replays, review exercises, and progressively harder failures at a cost no traditional training program could match. But the learning contract matters. The apprentice predicts before the reveal, reviews before the explanation, and diagnoses before the repair.
If AI can generate unlimited implementations, it can generate unlimited opportunities to compare, falsify, and explain. The same collapse in cost that made generation cheap can make practice cheap too.
5. Narrate the override
Experienced engineers make small override decisions constantly. They reject a technically valid abstraction because it creates operational coupling. They keep an ugly boundary because a migration is still in flight. They demand another gate because the rollback path is weaker than the implementation looks.
Those decisions often remain tacit. In an agentic workflow, they need narration.
When a senior rejects a plausible output, they should explain which signal changed the decision. Then the team should decide whether the lesson belongs in a specification, standard, test, runbook, or evaluation. The goal is to keep valuable judgment from disappearing inside one person's approval click, not to turn every judgment into a rule.
This is how mentorship and the Context Spine become the same system.
6. Increase consequence gradually
Apprenticeship requires real responsibility, but responsibility should expand with demonstrated judgment.
Start with sandboxed work and reversible changes. Move to pull requests, then bounded production ownership, then higher-consequence decisions with explicit rollback and escalation paths. Do not promote autonomy based only on how much an engineer or their agent can generate. Promote it based on the quality of the frames they write, the failures they anticipate, the defects they catch, and the decisions they can explain.
Consequence is not one ladder. It has at least four dimensions:
- Reversibility: Can the action be undone cleanly?
- Blast radius: How many systems, customers, or obligations can it affect?
- Observability: How quickly will the team know it is wrong?
- Recovery cost: How difficult will restoration be after failure?
An apprentice may safely own a high-volume change with strong isolation and instant rollback before owning a small irreversible change whose failure stays quiet for a month. Responsibility should expand along the evidence, not the calendar.
The progression runs from smaller consequences to larger ones, not from less AI to more AI.
| Stage | Apprentice owns | Agent contributes | Senior teaches | Evidence of growth |
|---|---|---|---|---|
| Frame | Intent, assumptions, acceptance criteria | Exploration and questions | Problem boundaries | Specs become clearer and more testable |
| Build | Decomposition and direction | Implementation and iteration | Tradeoffs and system shape | Fewer misunderstood changes |
| Review | First-pass evaluation | Explanations and alternatives | Pattern recognition | Predictions increasingly align with independent evidence and outcomes |
| Failure | Diagnosis and new hypothesis | Search and candidate fixes | Invariants and causal reasoning | Faster, more accurate recovery |
| Release | Risk, rollback, and recommendation | Checks and execution support | Consequence and accountability | Safe independent ownership expands |
That is an apprenticeship designed for the work that is arriving, not the work we remember.
A better ladder does not matter if the door closes
Everything so far assumes the apprentice is already inside the organization.
That is not guaranteed. If a senior engineer working with agents can produce more, the immediate economic response may be to hire fewer beginners. A company can build an excellent program for ten junior engineers while reducing its entry-level class from one hundred to ten. The ten may learn better. The profession still loses most of its on-ramp.
A better curriculum does not preserve an apprenticeship if companies stop opening the door.
I am not arguing for a fixed ratio of junior engineers or pretending AI will leave headcount unchanged. Some teams will become smaller. Some entry-level tasks will disappear completely, and some should. The honest claim is narrower: if the industry expects a future supply of people capable of evaluating consequential systems, some organizations have to provide paid access to consequential work before beginners are independently productive.
That investment has a structural problem. The skills it produces are portable. A company can fund years of development and watch the engineer leave, while another company hires experienced people without helping create them. Workforce economists have studied this as a training market failure: the employer paying the cost may not capture the full return, so the market provides less training than the work ultimately needs.
AI makes the temptation stronger. Buy the tool, hire fewer beginners, and recruit experienced evaluators from the companies still producing them. Every individual decision can look rational while the shared talent pipeline empties.
This is why apprenticeship cannot survive as the personal generosity of a few engineering managers. It needs an explicit enterprise commitment: real entry paths, rotations through meaningful work, protected learning time, and partnerships where a single company cannot carry the whole cost.
The new ladder also has to be more equitable than the accidental one it replaces. Informal mentorship tends to flow toward people who already look confident, share the right networks, or know which senior to ask. When senior attention becomes scarcer, that pattern gets worse unless access is designed.
Publish the competencies. Rotate the opportunities. Give every apprentice structured feedback and a path to contest a review. Credit their contributions. Build portable skill, not dependence on one company's tools or one senior's preferences.
Apprentices are people making a career bargain, not inventory in an evaluation-capacity pipeline. The bargain should give them increasing agency, visible progress, and skills worth carrying elsewhere, even when that portability makes the investment harder to defend on a spreadsheet.
Senior time is part of the capital plan
None of this is free.
If AI makes a senior engineer twice as productive, the easiest move is to fill the reclaimed capacity with twice as much delivery. That is rational at the team level and dangerous at the system level. The organization consumes senior judgment without reserving any capacity to reproduce it.
The review load can move in the opposite direction from the generation cost. One 2026 observational study examined 22,953 pull requests from lower- and higher-experience AI-assisted contributors. The lower-experience group submitted larger changes, received 4.52 times more review comments, had 31 percent lower acceptance, and remained open 5.16 times longer. The study does not prove that AI caused those differences, but the operating warning is hard to miss: cheap generation can turn senior attention into the shared bottleneck.
Mentorship cannot remain invisible volunteer labor performed after the sprint is already full. If evaluation capacity is a funded constraint, apprenticeship is how that capacity renews itself.
Funding it means changing more than the calendar. Team capability has to become an expected senior output. Teaching artifacts must count as durable engineering work. Managers need to own access and progression, not merely encourage mentoring. Delivery plans have to reserve development capacity before the backlog consumes it.
It also has to scale. Not every lesson requires an hour of one-to-one staff-engineer time. Teams can run cohort reviews, replay incidents, preserve narrated overrides, use peer review before senior review, and build reusable evaluation fixtures. Agents can provide explanations and adaptive practice without revealing the answer too early. The point is to concentrate scarce senior attention on the judgment only experience can currently teach.
This belongs on the AI Operating Ledger. The institutional-memory line should ask not only whether documentation improved, but whether people learned. Did the workflow create another person capable of evaluating its output, or did it concentrate more judgment in the few people already carrying it?
The measures should change accordingly. Lines of code and tickets closed were always weak proxies. In an agentic apprenticeship, I would watch:
- The quality and acceptance rate of apprentice-authored specifications
- Defects identified in first-pass review before senior intervention
- Calibration between apprentice predictions, independent evidence, and eventual outcomes, including cases where the apprentice correctly challenged a senior
- Failure diagnoses that become durable tests or standards
- Time to independent ownership of increasingly consequential systems
- Senior capacity explicitly spent narrating decisions and reviewing frames
The measures exist to make the investment visible enough that delivery pressure cannot erase it without anyone noticing, not to turn human development into another dashboard that pretends to be precise.
The honest objections
The strongest objection is that AI can help people learn faster. It can explain an unfamiliar codebase, generate examples on demand, create practice problems, and let a junior explore systems that would otherwise be inaccessible. I believe all of that. I use AI to learn every week.
The concern is different: production incentives reward delegation, not comprehension. If the only measured outcome is whether the task closed, the fastest path is to let the agent carry as much of the cognitive load as possible. Learning requires a different loop.
Another objection is that organizations do not have time for this. The delivery backlog is real, senior attention is scarce, and the whole reason to adopt AI was to increase capacity.
That is exactly why the investment matters. An organization that has no time to develop evaluators is choosing to make evaluation capacity scarcer. The bill will not arrive in the current sprint. It will arrive when the people who can distinguish plausible from correct are overwhelmed, leave, or become the bottleneck every agentic workflow shares.
A third objection is that agents will soon evaluate other agents, making the human pipeline less important. They will, and they already do. Automated review, adversarial agents, test generation, and machine-graded answer keys should absorb as much repeatable evaluation as they can.
But someone still has to decide what good means, test whether the evaluator is grading the right behavior, resolve contested cases, and own the consequence of being wrong. As more judgment becomes encodable, the remaining judgment moves to the seams where context is incomplete and tradeoffs are real. That argues for renewing the smaller pool of expertise the system still depends on, not for infinite headcount.
What would change my mind
I may be overestimating how much the old practice field mattered.
If agent-native engineers reach independent system ownership faster than prior cohorts, diagnose incidents as effectively, predict failures as accurately, and make equally sound decisions despite performing far less manual implementation, then the new path is already working better than I think. We should measure those outcomes rather than romanticize the route that produced us.
I would also revise this argument if machine evaluators begin reliably supervising consequential systems beyond the practical reach of human reviewers, including defining the right criteria and resolving novel edge cases without pushing hidden risk downstream. In that world, the evaluator pipeline matters less because evaluation itself has crossed the same threshold as generation.
I have not seen either result yet. The current evidence points in the other direction: expertise still improves agentic outcomes, while some forms of delegation weaken the learning needed to build that expertise. But this is an operating hypothesis, not a law of nature. The apprenticeship system should collect the evidence that tests it.
What changes on Monday
Do not start with a curriculum committee. Pick one recurring, agent-assisted workflow on one engineering team.
Name a manager accountable for the apprenticeship outcome and a senior engineer accountable for the technical boundary. Put the development capacity into the plan before the delivery work begins.
Map each step into three categories:
- Toil to automate: repetitive work with little learning value and a strong answer key.
- Practice to redesign: bounded work where prediction, feedback, and correction build judgment.
- Consequence to supervise: decisions where failure has material cost and an experienced person still owns the outcome.
Declare whether each run is in production mode or learning mode. For the next month, make an apprentice the first framer and first reviewer on the practice work. Require a prediction and a falsifying test before every regeneration. Ask the senior to narrate one consequential override each week and encode the lesson where the next person or agent can use it. Expand responsibility only when the evidence supports it.
At the end of the month, do not ask whether the apprentice agreed with the senior. Compare both of their predictions with independent evidence and with what happened after release. Preserve the cases where the apprentice was right. They are proof that the ladder is producing judgment rather than obedience.
Then review two outputs, not one.
Did the work ship?
Did another person become more capable of judging the next piece of work?
If the first answer is yes and the second is no, the workflow produced software while consuming the future capacity of the organization. That may occasionally be the right bargain. It should never be an invisible one.
AI is eliminating accidental apprenticeship, not apprenticeship itself. The replacement has to be designed. The craft can survive, and so can the on-ramp, but only if we stop treating it as incidental labor and start funding it as part of the production system.
The question is no longer who will write the code.
It is who will know when the code is wrong.
Related reading
- I Built a Design System in Two Hours. Figma, We Should Talk.
- The More AI We Have, the More Human Judgment Matters
- The AI Operating Ledger
- The Spec Is the Product
- Two Gates and a Night Shift
Research notes
- Shen and Tamkin, How AI Impacts Skill Formation, 2026.
- Anthropic, Agentic coding and persistent returns to expertise, 2026.
- Vella and Blincoe, The Impact of AI Coding Assistants on Software Engineering: A Longitudinal Study, 2026.
- Asdaque et al., Novice Developers Produce Larger Review Overhead for Project Maintainers while Vibe Coding, 2026.
- Dillon et al., Do Workforce Development Programs Bridge the Skills Gap?, revised 2026.
