People: Roles, Skills and the Junior Pipeline

The work moves to supervising

This book defines a level by what a human reviews, and when (The AI-SDLC Maturity Model). The definition has a consequence for people that is easy to miss: every climb up the ladder changes someone's job. At L2 an engineer reads every diff an agent produces. At L3 the same engineer reads evidence bundles, the items routed to them, and a sample of the rest. The share of the day spent writing new code falls, and the share spent judging code someone else wrote rises.

The most detailed account of that shift comes from a vendor studying its own staff, so it sits in a box and carries no number this chapter relies on.

Two other sources fit the same picture. DORA's 2025 qualitative data suggest that "perceived capacity gains from AI-assisted development tools have invited higher expectations of work output in some organizations" (DORA 2025, p. 40). Danish administrative data, discussed in Economics, Risk and Measurement, found no measurable effect on earnings or hours, and found that "employers absorb AI through task reorganization—including new tasks in content generation, AI oversight, and AI integration" (Humlum & Vestergaard, T1). Pay and hours stay put; the tasks inside the jobs change, and one of the new tasks is oversight.

Oversight is a skill, and skills are learned. That is the hinge of this chapter: the people who will supervise agents at L3 have to come from somewhere, and the evidence says the default way of using AI does not train them.

Output up, skill down

Two bodies of evidence seem to disagree about juniors. They are measuring different things.

Short-term output: juniors gain most. In three field experiments covering 4,867 developers at Microsoft, Accenture and a Fortune 100 firm, AI code completion raised completed tasks by 26.08% (Cui et al., T1, mixed independence). Less-experienced developers were more likely to adopt the tool and gained more from it. At Microsoft, short-tenure developers adopted at 81.6% against 72.1%, and their output rose 27–39% against 8–13% for long-tenure staff. The authors call the split by seniority noisy and "not statistically significant at conventional levels", so read it as a direction. Economics, Risk and Measurement places this result in the full range, from 19% slower to 56% faster, and shows how task type, familiarity with the code, codebase maturity and tool generation move it. This result is for code completion, an L1 tool.

Long-term skill: juniors learn less. Anthropic randomised 52 mostly junior engineers to learn Trio, a Python library they were unfamiliar with, either with an AI assistant or by hand. Afterwards "the AI group averaged 50% on the quiz, compared to 67% in the hand-coding group", and "the largest gap in scores between the two groups was on debugging questions". The AI group finished about two minutes faster, "although the difference was not statistically significant" (Anthropic, January 2026; paper: Shen & Tamkin).

How people used the assistant mattered more than whether they had it. The three patterns whose users averaged under 40% on the quiz were AI delegation, progressive AI reliance and iterative AI debugging. The three that averaged 65% or more were generation-then-comprehension, hybrid code-explanation and conceptual inquiry. The groups are small (two to seven people per pattern) and the authors say their qualitative analysis "does not draw a causal link". The direction is still useful: asking the AI to explain kept the learning, and handing it the work did not. The authors also expect agentic tools, which do more of the work, to have effects on skill that are "likely to be more pronounced", and they tell managers to "think intentionally about how to deploy AI tools at scale".

A larger trial outside software points the same way and shows a fix. Nearly 1,000 Turkish high-school maths students practised with either an unrestricted GPT-4 interface or a tutor version built to guide students with hints rather than give them answers. During practice the unrestricted group did 48% better than the control group and the tutor group 127% better. On a later exam without AI, the unrestricted group did 17% worse than the control group, and in the tutor group those harms were largely mitigated (Bastani et al., PNAS 2025; summary from Wharton).

A survey of 319 knowledge workers points to a mechanism: "higher confidence in GenAI is associated with less critical thinking, while higher self-confidence is associated with more critical thinking" (Lee et al., CHI 2025, self-report survey; six of the seven authors are at Microsoft Research).

Put together, these findings do not contradict each other. Juniors produce more with AI in the short term and form less skill if the AI does the thinking. Practice scores rose in the classroom too, right up to the exam. A pull-request count is a practice score. It cannot tell you whether the engineer behind it could debug the code without help.

The hiring signal

The labour-market data show the junior problem as a hiring problem, not a layoff problem. Two independent datasets agree on the mechanism.

Stanford's Digital Economy Lab, using ADP payroll records, finds that "employment of young workers (ages 22–25) in AI-exposed occupations now stands 19% below where it would be had it kept pace with that of their less-exposed peers; experienced workers show no comparable gap". The effect "operates primarily through reduced hiring of young workers rather than increased separations", and the authors find "no evidence of widespread, economy-wide job displacement" (Brynjolfsson, Chandar & Chen, August 2026). The declines are concentrated where AI use substitutes for human tasks. Where it complements workers, employment is "flat or rising". The authors attach their own caveats: the patterns "attenuate when controlling for education, show some divergent trends predating generative AI, and are more pronounced in the ADP analysis sample than in national survey benchmarks". The paper gives no reliable figure for software developers alone, so this book quotes none.

Hosseini and Lichtinger, using résumé data on 65 million workers at more than 280,000 firms, find that "junior employment in adopting firms starts to decline steeply relative to controls, declining by about 9 percent after six quarters", while senior employment showed "no sign of a break in trend". The decline is "driven primarily by slower hiring", and "within occupations, GenAI-exposed tasks are increasingly removed from junior job postings" (Hosseini & Lichtinger, May 2026 version).

The last finding is the one that matters for an engineering organisation. Firms are not only hiring fewer juniors. They are removing from the junior role the very tasks juniors used to learn on.

The pipeline argument follows from the book's own model, not from a forecast. L3 is defined by humans who review evidence instead of every line, and who can tell when the evidence is wrong. Those people need exactly the debugging judgement the trial above found weakest in AI-assisted learners. Every senior engineer was once a junior. An organisation that stops hiring juniors, or hires them and lets the agent do their learning, is drawing down the supply of the people its higher levels depend on.

Designing the junior track

No company has published a measured evaluation of a junior programme built for AI-driven delivery. What follows is the book's proposal, assembled from the learning evidence above. Each practice names the harm it guards against and the evidence behind it.

The two strongest items are the cheapest. Tutor mode is a configuration choice, and the wiki's tutoring and learning agents playbook covers how hint-first assistants are built. Review-first apprenticeship reuses work the team already has to do. Code Review sets out the review queue, risk tiers and evidence bundles; a junior reviewing an evidence bundle under supervision learns both the code and the standard it was held to.

The trade-off is real and should be named. Every practice in the grid costs output in the short term. A junior in tutor mode ships less this quarter than one who lets the agent write the code, and a senior reviewing a junior's review is not reviewing something else. You are spending current throughput to keep a future supply of reviewers.

Measuring ramp-up honestly

The only company-level ramp-up data with numbers come from a vendor.

Time to tenth pull request is a practice score, in the sense of the classroom trial above. A faster ramp-up is welcome, but only if the engineer can explain and debug what they shipped. If you track ramp-up, pair the speed measure with a comprehension check: a debugging exercise without an assistant at 90 days, or a short walk-through of the engineer's own merged changes with a senior. The pairing follows the rule this book applies to every phase: no speed metric without the quality metric that would tell you it backfired.

Roles by level

Job titles are a poor guide here. The hard data on new formal roles is thin, and Microsoft's "agent boss", defined as "someone who builds, delegates to and manages agents to amplify their impact", comes from a vendor survey that does not state its sample (Microsoft Work Trend Index, April 2025, T4). A better guide is the ladder itself, because each level defines what a human must do. The grid below is the book's proposal, read off the level definitions in The AI-SDLC Maturity Model.

Three things follow for how you organise people. First, review and verification work has to be counted as delivery. If a team's targets count only merged changes, the reviewing that L2 and L3 depend on will be skipped, which is what the no-review merge telemetry in When Code Gets Cheap, the Bottleneck Moves shows happening. Second, accountability stays with a person. The Linux kernel's rule that only humans may add a Signed-off-by tag, while the tool is credited with Assisted-by:, is one working model (kernel.org, as of October 2026). Scaling Across Teams turns it into a provenance policy. Third, the person accountable for an L4 task class must have the skill to judge it. A level whose accountable human cannot debug the class it covers is a level that cannot be rolled back with confidence.

Keep AI metrics out of individual reviews

Once AI use is visible in telemetry, the temptation is to grade people on it. Some companies have done so. Shopify's CEO declared that "Reflexive AI usage is now a baseline expectation", and press summaries say AI use entered performance reviews (Digital Commerce 360, April 2025, secondary). Coinbase's CEO said engineers who had not onboarded to AI coding tools within a week, without a good reason, were let go (Entrepreneur, August 2025, secondary). Neither has published outcomes. Both are T4 policy statements.

The measurement vendor that sells AI-usage dashboards argues against using them this way: "we strongly caution against top-down mandates or using metrics for individual performance evaluation", and "metrics like code generation volume are particularly susceptible to gaming" (DX AI Measurement Framework, vendor guidance, as of October 2026). The learning evidence gives a second reason. A junior graded on AI usage or output volume is being paid to delegate, which is the pattern that produced the lowest skill scores. Grading people on AI use rewards the habit this chapter is trying to train out.

Engineers have noticed the risk themselves. In Stack Overflow's 2026 survey, 17.1% of 13,857 respondents named "Concern over losing job skills or training an AI to replace you" as a reason to avoid AI at work or school (Stack Overflow 2026, survey). There is a legal angle too. Germany's Works Constitution Act gives the works council co-determination over technical equipment "designed" to monitor employees' behaviour or performance (section 87(1)(6)), and the Federal Labour Court reads that test objectively: a system suitable for recording such data qualifies, whatever the employer intends. A per-user AI-usage dashboard fits that description. The wiki's page on worker consultation and co-determination sets out the test.

Measure the system, not the person. Flow and stability metrics belong to teams and phases, and Measuring Success and When to Roll Back sets them out. For individuals, judge what has always mattered: whether the work was right, whether they could explain it, and whether they made the people around them better.