Protect the skill

Protect the Skill

Two predictable mistakes surround AI adoption, and they're mirror images. One: automating a task because it looks automatable, when the real constraint lives somewhere the tool doesn't touch — so you get speed on the wrong step and no actual gain. Two: offloading a task successfully, then discovering the capability you offloaded has quietly withered, leaving you worse off when the tool is absent or wrong. This skill runs both checks before you adopt: where is the bottleneck really, and what skill will I lose if I hand this over?

Check 1: Locate the real bottleneck (task ≠ job)

Automating a task only helps if that task is the binding constraint. Often it isn't — the automatable part was never what limited output.

• Is the bottleneck inside or outside the automatable step? Radiology image-reading is highly automatable, yet radiologist headcount grew — because the bottleneck was case volume, liability, and procedural work around the read, not the read itself. Document review, by contrast, was the bottleneck for paralegal work, so automating it shrank the role. Same "AI reads/reviews" surface, opposite employment effects, because the constraint sat in different places.
• Task-level automation doesn't imply job-level automation. A job is a bundle of tasks; automating one can leave the bundle intact (or even more valuable) if the remaining tasks are the constraint. Ask what the person actually spends their scarce time on, and whether the tool touches that.
• Exposure is not outcome. "This role is 70% exposed to AI" measures technical susceptibility, not displacement. Outcome depends on where the bottleneck is, bargaining power, demand, and whether the freed time redeploys to something valuable. (See hype-check, analogy-check.)
• The verification-overhead reversal. Automating a step can slow you down if checking the tool's output costs more than doing the step yourself — documented for experienced people working in familiar, idiosyncratic contexts, where the tool's unfamiliar conventions cost more to verify than they save. Automate where verification is cheap; be wary where it's expensive.

Conclusion of Check 1: automate the step that is actually the constraint and where verifying the output is cheaper than doing it. If neither holds, the adoption won't pay off — or will quietly cost you.

Check 2: Flag the deskilling risk (what atrophies?)

Offloading a cognitive task can degrade the underlying capability — and the decline follows the behavior, it isn't there beforehand. The evidence is consistent: heavier turn-by-turn navigation use predicts worse independent navigation later (it recruits neither the hippocampus nor prefrontal cortex the way self-guided navigation does); specialists' unaided detection rates dropped after working alongside a detection AI; heavy LLM-assisted writing showed sharply lower neural engagement and worse recall of one's own just-written work, and the effect persisted after the tool was removed.

Ask, before offloading:

• Which specific capability does this remove from active use? Name it. "Using AI to draft" might offload structuring an argument (high-value to keep) or fixing comma splices (fine to lose). The two are not the same bet.
• Is it a skill you need to retain — for judgment when the tool is wrong, for the times it's unavailable, for training the next person, for keeping the expertise to supervise the tool at all? Offloading the very skill you need to catch the tool's errors is the trap.
• Scaffolded vs. unscaffolded use. The decisive variable is how you offload. Structured use — the tool handles lower-order steps while you keep the analysis and evaluation — tends to preserve or build skill. Unstructured use — the tool produces the whole answer while you rubber-stamp it — is where atrophy and "cognitive surrender" show up. Design the former, not the latter.
• Retention needs practice, not just exposure. If a capability matters, build in deliberate tool-off practice, the way a pilot hand-flies to stay current. Convenience alone will erode it.

Procedure

1. Break the target into its actual constituent tasks; identify which one is the binding constraint on output/quality.
2. Bottleneck check: does the tool automate the constraint? Is verification of its output cheaper than doing the task? If no to either, reconsider or narrow the adoption.
3. Deskilling check: name the specific capability being offloaded; decide whether you must retain it (for judgment, unavailability, training, supervision).
4. If you must retain it, design scaffolded use (tool does lower-order steps; human keeps analysis) and schedule tool-off practice.
5. Decide: adopt (and where), adopt-with-guardrails, or don't automate this step — with the reason.

Output template

TARGET: <task/role/workflow> | TASKS: <the constituent steps>

BOTTLENECK: <which step is the real constraint?>
  Tool automates the constraint? <yes/no>
  Verification cheaper than doing it? <yes/no>
  → Adoption pays off? <yes / only if narrowed to … / no>

DESKILLING: capability offloaded = <name it>
  Must retain? <yes/no — for judgment / unavailability / training / supervision>
  Use design: <scaffolded (keep analysis) | unscaffolded (rubber-stamp — risky)>
  Retention plan: <tool-off practice, if the skill matters>

DECISION: adopt-here | adopt-with-guardrails | don't-automate — <why>

Example (compressed)

Question: "Should our junior analysts use AI to write first-draft financial models?"

TASKS: gather data → structure the model → build formulas → sanity-check
  assumptions → interpret results.
BOTTLENECK: for juniors, the constraint on quality is *judgment about assumptions
  and interpretation*, not typing formulas. AI automates formula-building (not the
  constraint) and can draft structure. Verification of its assumptions is
  expensive precisely because juniors can't yet judge them — the risky zone.
  → Pays off for formula scaffolding; risky for assumption-setting.

DESKILLING: offloading "structure a model from assumptions" removes exactly the
  capability juniors are supposed to be building — and that seniors later need
  them to have to supervise the tool. Must retain: yes.
  Use design: scaffolded — juniors set assumptions and interpret; AI accelerates
  formula construction and formatting. Not unscaffolded "generate the whole model,
  glance, submit."
  Retention plan: periodic from-scratch models, tool off, in review.

DECISION: adopt-with-guardrails. Automate the mechanical build; keep assumption-
  setting and interpretation human, or you deskill the pipeline that produces
  your future seniors.

Gotchas

• "It's faster" isn't the whole question. Faster on a non-bottleneck step, or faster now at the cost of a skill you'll need later, can be a net loss. Check both.
• Deskilling is not an argument against all automation. It's an argument for choosing what to offload and how. Offload the low-value, keep and practice the high-value.
• The person who can't do it can't supervise it. Retaining a skill is often required precisely to catch the tool when it's confidently wrong.
• Pairs with hype-check and analogy-check (exposure≠outcome), disaggregate (effects differ by seniority/experience), and validate-the-claim (the tool's own accuracy claims).