AI Coding Tools May Remove the Rungs Engineers Need to Climb

A team could ship more work with AI coding tools and still face a thinner pipeline of engineers able to review that work over time. In a presentation published on 2026-10-30, InfoQ’s Alasdair Allan draws on empirical research from METR and Anthropic to discuss what he calls the “supervision paradox”: reliance on AI tools may disrupt junior skill development, risk institutional context loss, and threaten the long-term engineering pipeline needed to oversee autonomous systems. ¹

For an engineering leader, the decision is not only whether AI assistance changes coding work. It is also whether the way the team adopts these tools preserves learning, mentoring, and system context that can help junior engineers develop into capable reviewers. That is a management question raised by Allan’s argument, not a measured finding about any particular company. ¹

What the presentation says about AI coding tools and junior engineers

Allan’s talk, “The Ladder Is Missing Rungs: Engineering Progression When AI Ate the Middle,” argues that reliance on AI coding tools can disrupt junior skill development, erode institutional context, and threaten the pipeline of engineers needed to supervise autonomous systems. ¹

The available source summary identifies research from METR and Anthropic, but does not provide the underlying studies’ methods, sample sizes, or results. It supports describing the risk Allan raises; it does not support treating that risk as a proven outcome for a particular company’s teams. ¹

That distinction matters in a board presentation. A company can investigate whether its own adoption of AI tools is changing work and learning patterns. It should not present Allan’s warning as a result measured in its own data.

Why AI coding adoption is a management problem, not just a tooling choice

One possible mechanism is that if AI tools take on tasks junior engineers might otherwise perform, those engineers could get fewer opportunities to build the judgment involved. Allan raises a risk to junior skill development but the available summary does not specify which tasks were studied or how skill development was measured. ¹

Allan also flags the risk of losing institutional context. He argues that reliance on AI tools can erode context that helps engineers understand systems and their history. ¹

If fewer engineers develop that understanding, a company could have less internal capacity to explain, maintain, and govern its systems. That is a plausible implication of Allan’s argument, not a measured finding. It suggests a potential mismatch between AI-assisted output and the people available to supervise it.

Output alone does not show whether engineers are gaining experience for future responsibilities. That is a question for a company to investigate with its own evidence.

AI software engineering skills that are hardest to replace

Writing code and developing engineering judgment are different activities. Managers could examine whether work such as framing a problem, weighing implementation trade-offs, debugging, reviewing changes, or tracing decisions through system history functions as a learning opportunity on their teams. These are examples to investigate, not tasks the source says it measured. ¹

The practical question for any team is which current tasks function as learning steps, and whether AI assistance changes who performs them or how much of the work junior engineers see.

AI assistance might change the learning value of a task without eliminating it. For example, a junior engineer could formally own a change while receiving a tool-drafted implementation. That hypothetical illustrates why “AI-assisted” is a workflow to inspect, not a single uniform category. For a look at how one vendor describes review of machine-written code, see what the Claude Code review account does and doesn’t show.

Allan’s concern is that junior skill development, institutional context, and future supervisory capacity could erode together. ¹

Weighing productivity against pipeline risk

A company can evaluate AI coding adoption on two time horizons: near-term delivery and the longer-term development of engineers’ judgment for reviewing and operating increasingly autonomous systems. The latter is the concern at the center of Allan’s supervision paradox. ¹

Allan’s warning is a risk to investigate, not a claim that AI coding tools always reduce productivity or that junior engineers invariably lose skills. ¹

A business case could track workforce indicators alongside delivery metrics: the variety of tasks assigned to junior engineers, their access to code review and debugging, mentoring time, progression evidence, and whether they can explain the reasoning behind significant system decisions. These are proposed internal measures, not benchmarks from the source.

If junior engineers receive different assignments after adoption, that is a signal to investigate, not proof on its own that the tools caused a change in capability.

Protecting engineering career progression in team design

One proposed response is to preserve supervised ownership of real work. Give junior engineers bounded changes to lead, ask them to explain the design and its failure modes, and require them to inspect and defend AI-generated code rather than submit it unread. These are management suggestions prompted by the risk Allan describes, not steps he prescribes. ¹

Another proposed response is to make mentoring part of the delivery process. Pair junior engineers with experienced reviewers, include explanation in review, and record the reasoning behind significant changes. These practices may help retain context that might otherwise remain with individuals; they are not interventions evaluated in the source. ¹ Teams experimenting with coding-agent skills drawn from pull requests face a related question about whose reasoning gets captured and who learns from it.

Teams could also consider what progression rewards. If judgment, system understanding, and review quality do not count alongside delivery, the organization may be placing too little weight on capabilities relevant to oversight. This is a management implication of the risk Allan describes, not a finding reported by the presentation. ¹

Senior engineers could periodically review the AI workflow: where tools are used, which decisions remain human, and whether junior staff still have meaningful opportunities to learn from the work. This is one way to look for process changes that may also affect career development.

The evidence to collect before changing the engineering model

Start with a local baseline: what tasks junior engineers perform, how they receive feedback, who reviews their work, and how they learn system history. Allan’s source does not provide a measurement framework for an individual company, so the company would need to develop one. ¹

Then track whether AI-assisted work changes access to those tasks over time. Do not treat a shift in assignments as causal proof without an internal evaluation; the source summary does not provide a method for isolating that effect. ¹

A company could assess understanding through explanations, review discussions, debugging exercises, incident walkthroughs, and questions about system history. These are suggested ways to investigate understanding, not tests specified in the source.

Engineering, platform, and talent-development leaders could review the evidence together. That is a governance suggestion based on the risk spanning productivity, technical oversight, and career progression—not a process specified by the presentation. ¹

What a board-level policy on AI coding adoption should require

An investment case for AI coding tools could state both the delivery outcome it expects and the safeguards it proposes for workforce development. The second part responds to Allan’s warning about risks to the engineering pipeline. ¹

A company could require teams to show that junior engineers continue to receive supervised ownership, feedback, and exposure to system context. This would be an operating requirement set by the company, not a control specified by the presentation.

Set review checkpoints before expanding adoption. If a team cannot explain how junior engineers are developing the ability to review AI-assisted work, that is an open question to address—not an outcome to assume. The response will depend on the team, but its evidence should cover how people gain responsibility and how the organization assesses readiness.

A company could assign an executive to own the pipeline question separately from the adoption and productivity case. Allan describes a long-term risk to engineering capacity; assigning an owner is a proposed governance response. ¹

Visibility into tool use is a separate, narrower layer. An enterprise AI gateway with usage analytics and audit logs can show which models are being called, but it cannot show whether junior engineers are learning. That still requires the internal evidence described above.

What to do next

Map the current engineering ladder: identify tasks that may build judgment, system context, review ability, and operational responsibility.

For each task, note whether AI tools reduce it, remove it, or change its shape. Separate conclusions based on internal evidence from management judgments.

Run a limited adoption pilot and evaluate learning and oversight alongside delivery: mentoring time, task variety, explanation quality, review depth, and progression outcomes. These are proposed measures, not source benchmarks. Keep Allan’s warning and the company’s own data distinct. ¹

Report both sides to leadership: what changed in output, and whether the organization is developing engineers able to review, explain, and take responsibility for work that gets shipped.