Juniors, Craft, and Not Deskilling the Team is the chapter about the input to everything else in this book. Chapter 5 established that senior reading capacity is the constraint, and senior engineers were produced by a process that ran through work agents now do in seconds.
Key takeaways
- Bainbridge described the mechanism in 1983: automate most of a task, leave the human monitoring, and the operator loses skill through lack of practice, precisely when a takeover implies something has already gone wrong and needs more skill.
- Lee and colleagues, at CHI 2025 from 319 knowledge workers and 936 first-hand examples, found higher confidence in generative AI associated with less critical thinking, and described a shift from information gathering to information verification and from task execution to task stewardship.
- Brynjolfsson, Chandar and Chen, using ADP payroll records, report a 16% relative employment decline for workers aged 22 to 25 in the most AI-exposed occupations after conditioning on firm-time effects, while experienced workers remained stable.
- The same paper reports employment for software developers aged 22 to 25 down nearly 20% by September 2025 from its late-2022 peak. It is evidence consistent with a mechanism, not proof of cause, and the authors do not claim otherwise.
- Judgement is teachable, and it now has to be taught deliberately rather than absorbed. Reading code critically, specifying precisely and handling incidents are the three skills to build a programme around.
Read this after Chapter 12, which priced the senior hours this chapter is about, and before Chapter 14, whose adoption sequence has to protect the pipeline described here. Chapter 5's capacity arithmetic is what makes this a business problem rather than a values problem.
The junior engineer has been on the team for seven months. Their output is good, their pull requests are clean, and they are trusted with real work.
Then a production incident starts and they are on the pairing rota. The service is behaving oddly and the answer is not in a log message.
They freeze, not from lack of intelligence but from lack of a particular kind of experience. They have never had to build a mental model of a system by reading it, because they have never had to write anything they did not already have a draft of.
The rung that disappeared from the ladder
The path to senior engineer used to be reliably shaped. You wrote a naive version, somebody told you why it was wrong, you understood the correction because you had made the mistake, and the understanding accumulated into judgement.
Each step in that sequence depended on the previous one being effortful. The wrongness of your first attempt is what made the correction stick.
Agents removed the naive version. A junior now starts from a competent draft. That is better output and a much worse teacher, because a correct answer you did not struggle towards conveys far less than a mistake you made yourself.
That is not an argument for making people work harder for its own sake. It is an observation that the learning was a byproduct of the work. The byproduct disappeared. Nobody decided to remove it, which is why nobody replaced it.
The mechanism, stated in 1983
The literature on this is 43 years old, and its age is the most persuasive thing about it. Lisanne Bainbridge published Ironies of Automation in Automatica in 1983, about industrial process control rather than software, and the argument transfers without modification.
Her argument runs in three steps. Automating most of a task leaves the human with monitoring rather than doing. A skill that is not practised decays, so the operator becomes progressively less able to perform the task the automation covers. And the moment a manual takeover is required is, by definition, a moment when something has already gone wrong, which is when the most skill is needed.
The conclusion she draws is the uncomfortable one. The operator supervising an automated process arguably needs to be more skilled than the operator who did the work by hand, not less.
I am paraphrasing rather than quoting, because I have not obtained the paper's text and will not present a verbatim line I cannot verify. The argument itself is well established and it is the whole of this chapter's theoretical basis.
What the current research measures
There is recent work that gets closer to knowledge work, and its findings are consistent with Bainbridge without proving her.
Lee, Sarkar, Tankelevitch, Drosos, Rintel, Banks and Wilson published a study at CHI 2025 drawing on 319 knowledge workers and 936 first-hand examples. They report that higher confidence in generative AI is associated with less critical thinking, while higher self-confidence in one's own ability is associated with more.
They also describe how the nature of critical thinking shifts rather than simply reducing: from information gathering to information verification, from problem-solving to response integration, and from task execution to task stewardship. That is a precise description of what a reviewer now does all day.
It is a self-reported survey and I would treat it as such. Two figures from elsewhere are worth holding beside it. Stack Overflow's 2025 Developer Survey, from 33,662 respondents, records 45.2% saying debugging AI-generated code is more time-consuming. DORA's 2025 report records a median of 16 months of AI experience among respondents, which means the whole population is early in its learning.
The employment data, and what it does and does not show
The labour-market evidence is the part that makes this urgent rather than philosophical, and it needs careful handling because it is easy to overclaim.
Brynjolfsson, Chandar and Chen published a November 2025 paper at the Stanford Digital Economy Lab using high-frequency ADP payroll records. They report that early-career workers aged 22 to 25 in AI-exposed occupations experienced 16% relative employment declines after conditioning on firm-time effects, while employment for experienced workers in the same occupations remained stable. They also report adjustments occurring primarily through employment rather than compensation, concentrated in occupations where AI automates rather than augments. The results hold when technology firms are excluded.
For this book's audience the specific figure is the one to sit with. By September 2025, the paper reports, employment for software developers aged 22 to 25 had declined nearly 20% compared with its late-2022 peak, while employment for other age groups continued to grow.
The authors' own framing of the mechanism is that AI may automate the codifiable, checkable tasks that historically justified entry-level headcount. That is a hypothesis consistent with their data rather than a demonstrated cause, and they present it that way.
So the honest reading is this. Something is happening to entry-level hiring in exposed occupations, and the timing is consistent with the mechanism. The paper does not claim causation. Neither will I. It is enough to act on.
Judgement is a different skill, and it is teachable
The pessimistic conclusion is that seniority now takes longer and there is nothing to do about it. I do not accept that, because the skills that are now scarce are ordinary skills that can be taught deliberately.
Three of them carry most of the weight. Reading unfamiliar code critically, meaning building a model of what it does and finding where it is wrong, which is a practised skill and not a talent. Specifying precisely, which Chapter 2 turned into a written discipline with six sentence patterns and a scope rule. And operating under uncertainty, meaning incidents, where the answer is not written down anywhere.
Notice that all three are exactly the work the operating model in this book now needs more of. The apprenticeship and the business requirement point the same way for once, which is a rare and useful alignment.
The thing that changes is that none of the three arrives as a byproduct any more. Each has to be scheduled, taught and assessed like a skill. Nobody absorbs judgement by watching a queue. It has to be practised on something real, with somebody senior watching, and that costs a specific number of hours you can put in a plan.
What used to teach what, and what teaches it now
The table below is the replacement mapping, and it is the artifact worth taking to a team lead.
| Skill | How it used to be acquired | What has to replace it |
|---|---|---|
| Reading unfamiliar code | Debugging your own bad code | Scheduled review of merged changes, with a senior reading alongside |
| Knowing why a pattern exists | Being corrected in review | Writing the architectural-intent entries from Chapter 3 |
| Specifying a problem | Being asked three questions before starting | Owning the specification for a change somebody else implements |
| Operating under uncertainty | Being on call for code you wrote | Pairing on incidents, and writing the runbook answers from Chapter 9 |
The fourth row is the one organisations skip and it is the least substitutable. Nothing else teaches what it teaches, and the cost of including a junior on an incident is one senior's attention for an hour.
A worked example, composited and labelled
The details here are composited from ordinary production shapes rather than one system, and the shape is exact.
A team redesigns its first six months for new engineers, and the redesign changes what they do rather than how much they produce.
Week one to four is unchanged: ship small things, learn the tooling. From week five, two hours a week are booked for review alongside a senior, on changes that already merged, with the junior reading first and the senior asking what they missed. From week eight the junior owns the specification for one change per sprint that somebody else implements, and reviews the result against the acceptance conditions they wrote. From week twelve they shadow every incident their team gets, with no responsibility and a required written summary afterwards.
None of that reduces their output. It reallocates about three hours a week, and one senior's attention for two of them.
The observable difference is not in their pull requests. It shows up in the questions they ask in design discussions at around month five, which is roughly a year earlier than the same team used to see it.
The objection: juniors are slower, so why hire them
The objection is now put more sharply than it used to be, because an agent produces competent code immediately and a junior does not. It deserves a direct answer rather than an appeal to fairness.
Three parts. Senior reading capacity is the constraint in this whole operating model, per Chapter 5, and it is the one input you cannot buy at short notice. The only supply is people you develop. A team of only senior engineers has no succession and a rising average cost, and it loses its most expensive people to organisations that offer growth. And the skills that make a good reviewer are learned on the way up. They are not granted on arrival.
The version of the objection I take seriously is about the shape of the job rather than its existence. If a junior's first two years are spent supervising output and correcting it, that is the deskilling condition Bainbridge described, and it will produce weak seniors rather than fast ones. Which is why the four rows in that table are about doing rather than watching.
The commercial argument is the one to take to a budget meeting. Faros AI recommends repurposing engineering capacity rather than reducing it, warning that the engineers being considered for cuts are often the ones absorbing the quality gap. Entry-level hiring is the cheapest way to build the capacity Chapter 5 says you are short of, and it takes two years, which means the decision is already late.
Chapter summary
The apprenticeship that produced senior engineers ran through work agents now do instantly, so the learning that used to be a byproduct of effortful authorship has disappeared without anybody deciding to remove it. Bainbridge set out the mechanism in Automatica in 1983, and the age of the argument is its strength. Automating most of a task leaves the human monitoring, unpractised skill decays, and a manual takeover happens exactly when something has gone wrong and more skill is needed rather than less. The supervisor of an automated process arguably needs to be more skilled than the person who did the work by hand. Lee and colleagues at CHI 2025, from 319 knowledge workers and 936 first-hand examples, report higher confidence in generative AI associated with less critical thinking. They also describe a shift from information gathering to verification and from task execution to task stewardship, which is a description of a reviewer's day. Brynjolfsson, Chandar and Chen, using ADP payroll records in November 2025, report a 16% relative employment decline for workers aged 22 to 25 in the most exposed occupations after conditioning on firm-time effects, with experienced workers stable. The same paper reports employment for software developers aged 22 to 25 down nearly 20% by September 2025 from its late-2022 peak. Its stated mechanism is a hypothesis rather than a proven cause: that AI automates the codifiable, checkable tasks that justified entry-level headcount. The three scarce skills, critical reading, precise specification and operating under uncertainty, are teachable and now have to be scheduled rather than absorbed, with incident exposure the least substitutable and most often skipped. And the commercial case is that senior review capacity is the constraint you cannot buy quickly.
Everything in this book so far is a change to how an engineering organisation works, and a team that resists it will win. Chapter 14 is Adopting This Without Breaking the Team, which is the order to do it in.
Sources
- Ironies of AutomationBainbridge, Automatica · 1983 · Research paper · reported
- The Impact of Generative AI on Critical ThinkingLee, Sarkar, Tankelevitch, Drosos, Rintel, Banks, Wilson, CHI 2025 · 2025-04 · Research paper · verified
- Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial IntelligenceBrynjolfsson, Chandar, Chen, Stanford Digital Economy Lab · 2025-11 · Research paper · verified
- 2025 Developer Survey, AI sectionStack Overflow · 2025 · Industry report · verified
- State of AI-assisted Software Development 2025DORA, Google Cloud · 2025-09-24 · Industry report · verified