The AI Skills Paradox: Who Will Know Enough to Check the Machine?

An impressive answer is not the same as an educated team

Imagine a team meeting six months after an enthusiastic AI rollout. More tickets have been closed, more reports have been produced and the demonstration looks excellent. Then somebody asks why a particular calculation is valid, what happens when a dependency fails, or which assumption makes a recommendation unsafe. The room becomes quieter. This is a hypothetical scene, not a measured description of every AI-using company. It captures a risk worth taking seriously: organisations can accumulate finished work without accumulating the understanding needed to maintain it.

The usual argument asks whether AI will replace a worker. A more uncomfortable question is whether it will replace the experiences through which that worker becomes competent. A junior developer does not become a senior developer merely by waiting for a birthday. An analyst does not acquire judgment by changing a job title. Expertise is built through decisions, correction, comparison and feedback. If some of those experiences disappear, the output may still arrive while the learning pathway changes.

Our argument is not that useful tools make people less intelligent. It is that immediate delivery and durable capability are separate outcomes. A sensible adoption strategy should measure both. Otherwise, “human oversight” risks becoming a reassuring label attached to a person who has neither the knowledge nor the time to disagree.

What a small coding experiment actually found

In January 2026, Anthropic researchers Judy Hanwen Shen and Alex Tamkin reported a randomised experiment with 52 developers, mostly junior, learning the unfamiliar Python library Trio. The AI-assisted group averaged 50% on an immediate comprehension quiz, compared with 67% without AI: a 17-percentage-point difference. Their roughly two-minute time advantage was not statistically significant. Debugging showed the largest quiz gap.

This was a small provider-led study, not a census of engineering or a test of long-term career outcomes. It does not establish permanent deskilling or describe every modern coding agent. The authors also observed different interaction styles, but those patterns were not randomly assigned. Asking conceptual questions looked promising; it was not proven to cause better learning.

The important organisational question survives those limitations: what would your own team be able to explain or repair after the tool is unavailable? A demonstration of completed code answers one question. An independent debugging exercise answers another. Neither should be silently substituted for the other.

Shen and Tamkin, Anthropic: coding skill formation, January 2026 →

Confidence can change where thinking happens

A CHI 2025 study by Lee and colleagues surveyed 319 knowledge workers about 936 examples of generative-AI use. Greater confidence in the tool was associated with less reported critical thinking; greater confidence in one’s own task ability was associated with more. Participants described work shifting towards verification, integration and stewardship. These are self-reports and associations, not evidence that AI caused a decline in intelligence.

For a manager, the distinction matters. Training somebody to operate a tool is not the same as preparing them to challenge its recommendation. A colleague may know exactly which button to press and still lack a benchmark for judging the answer. Conversely, an experienced specialist may use automation heavily while remaining highly critical. The interface can look similar; the underlying competence can be very different.

Consider a financial model as an illustration. A clean spreadsheet may reconcile mechanically while relying on an implausible business assumption. Checking the arithmetic will not reveal that problem. The reviewer needs a reasoned view of the business, a comparison point and permission to reject the result. That is why an approval tick alone is a weak definition of oversight.

Lee et al., CHI 2025: self-reported critical thinking with generative AI →

The counterargument is important: assistance can genuinely help

The answer cannot be a nostalgic demand to do every task the hard way. In the experiment with 758 BCG consultants reported by Dell’Acqua and colleagues, AI improved performance on tasks inside the system’s capability frontier, while reducing correctness on a different task outside it. The boundary depended on the task; it was not a permanent map of what every later model can do.

A tool can remove unhelpful friction. Searching for syntax, reformatting a document or generating alternative explanations may be a poor use of a learner’s attention. Insisting on avoidable inconvenience is not automatically good teaching. The stronger distinction is between friction that merely consumes time and effort that builds an ability the person will later need.

Our proposed test is practical: if the tool removes a step, identify what that step used to teach. If nothing important is lost, automate it confidently. If it taught diagnosis, interpretation or responsibility, create another route to practising that ability. The purpose is not to preserve suffering. It is to preserve competence.

Dell’Acqua et al., Organization Science, 2026: the jagged technological frontier →

Learning debt: a useful analogy, not a measured economic statistic

We call this risk learning debt. The phrase is an editorial analogy, not a validated index or a result calculated by the studies above. Like technical debt, it describes a trade-off: a choice may be efficient now while leaving a future obligation. A team can accept that trade-off deliberately, but it should not confuse postponing the obligation with eliminating it.

A hypothetical developer delegates an unfamiliar module and ships it after a superficial review. Later, they must change an assumption the generated solution quietly relied on. The saved effort may return as investigation, dependence on somebody else or a decision the team cannot confidently make. This is not inevitable. It is precisely the kind of failure a learning-aware workflow should try to prevent.

The opposite case is equally possible. A developer uses AI to compare approaches, predicts the likely failure, writes an independent test and explains why one solution fits the system. That workflow may produce both delivery and understanding. The relevant unit of analysis is therefore not “AI use: yes or no.” It is the relationship between delegation, feedback and retained ability.

Who pays for the next expert?

Emanuel, Harrington and Pallais study software engineers at a large firm using changes in coworker proximity. The June 2026 revision reports 18.3% more coding feedback when teammates sit nearby, with improved code quality. Less-experienced workers benefit, while experienced colleagues devote effort to helping others. This is evidence from a particular workplace, not proof that every team needs an office mandate.

The wider question is an incentive problem. If a senior engineer is evaluated only on their own completed tickets, helping a junior can look like underperformance. If a junior is evaluated only on immediate output, taking time to understand can look inefficient. Those two incentives can undermine apprenticeship even before AI enters the picture. AI makes it easier to hide the missing learning behind polished delivery.

Remote teams can respond without treating distance as destiny. Schedule real review time. Pair a newcomer with someone accountable for their development. Keep a record of decisions, not just instructions. Make it normal to ask why a solution works. These are our workflow recommendations, not effects quantified by the proximity paper. Good mentorship needs a budget, whether the conversation happens at a desk or on a call.

Emanuel, Harrington and Pallais: The Power of Proximity to Coworkers, revised June 2026 →

A more useful contract between the learner, manager and tool

Start by naming the learning objective before choosing the amount of assistance. On a familiar task, delegation may be appropriate. On a new concept that the worker will later be expected to judge, ask them to predict the approach first. Then use AI to challenge, clarify or compare that prediction. After the task, ask for an explanation without reading the generated answer. This is a proposed practice, not a guarantee supported by an experiment in this article.

Separate a delivery review from a learning check. The first asks whether the work meets its requirements. The second asks whether the person can diagnose a variation, identify a bad assumption or explain a trade-off independently. A team can collect both signals without turning every task into an exam. A short discussion around a real failure can be more revealing than another long status update.

Keep some practice deliberately independent and low risk. Use a synthetic dataset, a toy repository or an authorised historical example. Do not train judgment by exposing live customers to avoidable mistakes. Equally, do not confuse confidently repeating the model’s explanation with having tested it. Ask what observation would make the person change their mind.

Finally, recognise the reviewer’s work. Oversight requires access to evidence, enough time, relevant expertise and the authority to stop a release. If all four are missing, describing a process as human-in-the-loop does not make it robust. The human is not a decorative checkbox with a calendar invitation.

What candidates can demonstrate without pretending to know everything

For a developer, a useful discussion can trace one defect from symptom to cause, explain the test that caught it and identify the boundary of the fix. For a finance professional, it can show how a reasonable-looking assumption changes under a different scenario. For a data analyst, it can distinguish a descriptive pattern from a causal conclusion. These examples are suggestions for demonstrating reasoning, not secret hiring criteria or a promise of selection.

Be explicit about tool use. Saying “AI helped draft this; here is what I checked and what I changed” can be more informative than pretending either that no assistance occurred or that the machine owned the decision. Respect assessment rules: if a platform requires independent work, a useful learning tool outside the assessment is not permission to use it inside.

The positive version of this future is attractive. AI can become a patient comparison partner, a source of examples and a way to explore unfamiliar domains. But an organisation has to reward understanding, not just a convincing artefact. The long-term advantage may belong to teams that automate routine effort while deliberately investing in the judgment they cannot afford to lose.

The question worth debating

We should not ask only how many tasks a smaller team can finish. We should also ask how the organisation will produce the people capable of deciding whether those tasks were done well. That question connects hiring, management, learning and safety. It cannot be answered with a productivity screenshot alone.

Would you rather hire somebody who can produce an impressive answer quickly, or somebody who can explain when that answer should not be trusted? The obvious answer is both. The difficult part is building a workplace that actually develops and rewards both.

If AI does more of today’s work, who is responsible for developing tomorrow’s expert: the individual, the employer, the tool provider, or all three? That is the discussion we would like to have.