Working With Agents Without Deskilling

Working With Agents Without Deskilling is a design problem rather than a matter of willpower. The abilities that erode under automation are the cognitive ones, meaning diagnosis, situation awareness and judgement, and they erode quietly while your output looks better than ever. The research says vigilance will not save you, so what follows is structural instead.

Key takeaways

• Casner and colleagues, studying 16 experienced pilots in a Boeing 747-100 simulator, found instrument-scanning and stick-and-rudder skills reasonably intact after prolonged disuse while cognitive skills, situation awareness, navigation and diagnosis, were the vulnerable ones, and their retention depended on staying actively engaged in supervising the automation.
• Parasuraman and Manzey's 2010 review found automation complacency occurs under multiple-task load in naive and expert participants alike and cannot be overcome by simple practice, and that automation bias produces both omission and commission errors and cannot be prevented by training or instructions.
• Bastani and colleagues, in PNAS, randomised nearly a thousand Turkish high-school mathematics students and found that access to an unsafeguarded assistant raised performance during practice and lowered it once access was removed, while a safeguarded design mitigated the effect. The population is students on mathematics, so the transfer to engineers is an argument rather than a result.
• Self-assessment cannot be your control. In METR's randomised trial the 16 developers were 19% slower with AI tools and still believed afterwards that they had been 20% faster.
• Delegation depth is the variable you actually control. Anthropic's June 2026 index reports agent-shell sessions carrying 0.53 points more autonomy on a five-point scale than chat for code-producing conversations, with about two thirds of the gap being users delegating more completely.

Read this after Chapter 4, because the ability at risk is precisely the comprehension that chapter builds, and before Chapter 6, which is how to delegate more without delegating the judgement. For agents doing long-running work, the reliability side of the same problem is the long-horizon reliability argument.

An engineer who used to be the person you called for a production database problem notices something in a postmortem. She cannot remember the last time she read an execution plan without asking a model to explain it first.

Her output has not fallen. It has risen: more tickets closed, fewer late nights, and better-formatted queries than she used to write by hand.

What changed is that the diagnosis step left her hands. She still supervises it, and she can no longer perform it cold. The details here are composited from ordinary production shapes rather than one system, and the shape is exact.

Deskilling is specific, and it takes the cognitive half

Define the term narrowly or the argument turns into nostalgia. Deskilling here means the measurable loss of an ability you would still need if the tool were unavailable, wrong, or being used by someone else who needs checking.

It is not about typing. Nobody's career depends on producing boilerplate from memory, and losing that is not a loss. The abilities at risk are the ones Chapter 3's decay research flags as most vulnerable, meaning accuracy-based cognitive tasks. Forming a hypothesis about a failure. Holding a system's state in your head, and deciding what the correct output actually is.

There is a second, quieter loss. Skills you never acquire because the tool did the task the first hundred times, which is worse than decay because there is nothing to recover.

So the question for the rest of this chapter is narrow. Which abilities would you need if the tool were absent, and what keeps those specific ones in practice.

What aviation measured, offered as an analogy

The best-shaped evidence on this comes from a cockpit rather than a codebase, and it should be read as an analogy rather than as a finding about software.

Casner, Geven, Recker and Schooler studied 16 experienced pilots in a Boeing 747-100 simulator, published in Human Factors in December 2014. Their manual flying skills, instrument scanning and stick-and-rudder control, remained reasonably intact despite prolonged disuse. The vulnerable skills were cognitive: situation awareness, navigation and diagnosis.

Their retention depended on something specific. Pilots who stayed actively engaged in supervising the automation retained more than those who monitored passively.

That distinction is the practical content of this chapter. Passive supervision is watching output go past and approving it. Active supervision means forming your own expectation first and comparing. The two look identical from outside and produce different engineers.

Complacency cannot be trained away

The next finding is the one that rules out the easy answer, which is why it matters more than its age suggests.

Parasuraman and Manzey published an integrative review in Human Factors in June 2010, sixteen years ago now, on complacency and bias in human use of automation. Two of their conclusions are decisive here. Automation complacency arises under multiple-task load, appears in naive and expert participants alike, and cannot be overcome by simple practice. Automation bias produces both omission errors, meaning missing what the automation missed, and commission errors, meaning acting on automation that was wrong, in experts as well as novices, and cannot be prevented by training or instructions.

Read that last clause again. Telling people to be careful does not work. Telling yourself to be careful does not work either, and neither does being experienced.

Which is why the rest of this chapter is a set of structures rather than an appeal to discipline. If vigilance were sufficient, the aviation industry would have solved this with a memo forty years ago.

Assisted practice can raise the score and lower the skill

There is one experiment that gets closest to the mechanism, and its population is not ours, which has to be said in the same breath as the result.

Bastani and colleagues, publishing in PNAS, randomised nearly a thousand high-school mathematics students in Turkey across three conditions: a standard chatbot interface, a safeguarded tutor with teacher-designed hints, and a no-technology control. Access improved performance substantially during practice. Students who had relied on the unsafeguarded interface then underperformed once access was removed, which indicates reduced skill acquisition rather than reduced effort. The safeguarded design, which withheld answers and offered hints, mitigated the effect. A published correction to the paper exists.

Those are school students doing mathematics, not engineers writing software, and the transfer is an argument rather than a result. Here is the argument. The mechanism being tested is whether solving with help builds the ability to solve without it, and nothing about that mechanism is specific to algebra.

The design lesson transfers cleanly and is the most actionable thing here. The condition that preserved learning was the one that withheld the answer and gave structure instead, which is a thing you can do to your own workflow deliberately.

Delegation depth is the variable you control

Adoption is a useless variable. Depth is the one that decides what decays.

Anthropic's Economic Index report of 26 June 2026 measures this directly on its own platform. Conversations producing scripts and code involve 0.53 points more autonomy on a one-to-five scale in an agent shell than in chat. Across all conversation types the gap is 0.37 points, and 0.26 points even holding the model constant. About two thirds of that gap is users choosing to delegate more completely rather than anything about the tool. The report draws on roughly 9,700 linked survey respondents from mid-May to early June 2026, and it is a vendor reporting on its own product surface.

The finding I would hold onto is that the same model, in a different interface, receives more of the task. Interface changes behaviour. That is not a warning against agent shells, which are useful, it is a reason to decide consciously what you hand over rather than letting the tool's shape decide it.

The third row is the dangerous one, and it is the most comfortable place to work.

The three steps I keep unassisted

This is judgement rather than evidence, and it is deliberately narrow enough to argue with.

I keep three things unassisted. First diagnosis of any failure I have not seen before, meaning I write down my hypothesis and the evidence for it before I ask anything. Second any change to a data model or a migration, because that is where mistakes are least reversible and understanding is least substitutable. Third the security-relevant read of a path that handles authorisation or money, which I do myself before and after any tool sees it.

For frequency, my rule is one unassisted debugging session a week, on something real, timed. Not a kata. A genuine problem I would otherwise have delegated, worked cold for thirty minutes before any assistance is allowed in.

This is the pattern I trust, and I cannot prove it to you. What I can say is that thirty minutes is small enough to survive a sprint and long enough to reveal whether the ability is still there, and the discovery that it is not is the entire point of running it.

Why your own sense of how you are doing is not a control

The final structural argument is that the natural feedback loop here is broken, and there is a clean measurement of exactly how.

In METR's randomised trial of 10 July 2025, sixteen experienced open-source developers working 246 real issues in repositories they already knew took 19% longer with AI tools available. They had predicted a 24% speed-up. After the study, having done the work, they still believed they had been 20% faster.

Hold the direction of that error in mind. It is not that they were unsure. They were confidently wrong about their own performance, in the favourable direction, on a task they had just completed.

So any deskilling policy that depends on you noticing your own decline is broken by construction. What works is external and boring: the timed unassisted session, a review where you state your expectation before reading the diff, a colleague who asks you to explain a change you merged last month.

The objection: unassisted practice is a luxury my sprint does not fund

This is the strongest objection in the chapter and it deserves the strongest version. Nobody has slack. Velocity is measured, the tool makes you faster today, and a deliberate handicap looks indefensible in a standup.

Three answers, in increasing order of how much they persuade people. The first is that the cost is small: thirty minutes a week is roughly 1% of your working time, and you would not notice losing it to a meeting. The second is that the practice is not separate from the work, because the session is a real ticket done in a different order, so nothing is spent on exercises.

The third is the one that actually lands with a manager. The ability being preserved is the ability to handle the incident nobody can delegate: the failure the tool misdiagnoses, at the hour when the person who can form a hypothesis cold is the only resource available. In my experience that hour arrives about twice a year, and it is the hour that decides how the team is regarded for the next six months. Nobody budgets for it, and everybody remembers it.

Chapter summary

Deskilling under automation is specific: it takes accuracy-based cognitive abilities rather than manual ones, so the loss lands on diagnosis, situation awareness and judgement while output looks better than before. It also includes skills never acquired at all, because the tool did the task the first hundred times. Casner and colleagues, publishing in Human Factors in December 2014, found 16 experienced pilots in a simulator retaining instrument scanning and stick-and-rudder skills through prolonged disuse while situation awareness, navigation and diagnosis were the vulnerable skills, with retention depending on active rather than passive supervision. That transfers as an analogy rather than as a finding about code. Parasuraman and Manzey's 2010 review rules out the easy remedy, since automation complacency and bias appear in experts and novices alike and cannot be prevented by practice, training or instruction. Bastani and colleagues' PNAS experiment on nearly a thousand Turkish high-school mathematics students found that unsafeguarded access raised in-session performance and lowered it once access was removed, while a design that withheld answers mitigated the effect. The transfer to engineering is an argument rather than a result. Delegation depth, not adoption, is the variable, and Anthropic's June 2026 report finds agent-shell sessions carrying 0.53 points more autonomy for code work than chat. Self-report cannot be the control, because METR's trial found developers 19% slower and still convinced they were 20% faster. So the practice is structural: unassisted diagnosis, unassisted data-model work, unassisted security reads, and one timed cold session a week.

Delegating more without delegating the judgement requires the intent to be written down precisely enough that someone else can build it. Chapter 6 is Specifying Intent Precisely Enough to Delegate, and it treats the specification as the artifact that outlives the code it generates.