Offloading a capacity does atrophy it. That establishes a trade, not a verdict — and the trade is safe where you keep the ability to check the output. But verification is not a floor: it gets tooled and atrophies too, until the verifier only runs the tool and swaps the part. So the real obligation isn’t “never offload verification” — it’s keeping someone in the system who can still tell the verification layer has failed, and rebuild it.
Links: The Three-Layer Method, The Cyborg Model, Repairing LLM Code, Planner-LM Composites, The Weighting Problem, Reading Outcome Statistics
Parent: The Three-Layer Method’s rule is “outsource thinking, not understanding.” This page sharpens it into something operational and says what to do when someone argues the tools are making us stupider.
Outsource computation. Never outsource verification.
The standard worry — cognitive offloading causes atrophy — is true and insufficient. The standard reply — the extended mind means offloading is just relocation — is true and insufficient. Each is half of the answer, and the missing condition is the same in both cases: can the user tell when the tool is wrong?
That rule is right about where the line falls and wrong that it holds still. Verification is itself a capacity, so it is subject to the same dynamic it was invoked to solve — see § The Rule Is a Frontier, Not a Floor, which is the load-bearing qualification on this whole page. Read the rule as naming what matters, not as promising a stable floor.
Two jobs, and it is easy to notice only the first:
So the historian who confirms the book exists and the quote is on the right page is not indulging nostalgia for manual labour. They are running verification, and it is the same act whether the draft came from a card catalogue, a research assistant, or a model.
The obvious objection to the rule above is that it exempts verification from its own logic. It shouldn’t, and it doesn’t survive doing so.
Verification is a capacity, so it gets offloaded like any other — onto diagnostic computers, scanners, test suites, linters, CI. And when it does, the verifier’s job degrades to a recognisable shape: run the tool, replace the part. Nobody wires motherboards any more. Car mechanics rarely go past a surface reading of what the diagnostic says.
The failure mode is specific and worse than not checking at all:
Why are my shocks leaking oil? Don’t care — just replace them. And the broken spring that wrecked them goes unseen.
You fix the symptom the tool reports. The question the tool wasn’t built to ask stops being asked — and because a check did occur, the gap is invisible. Unchecked work announces itself; tool-checked work with an unasked question does not.
The page’s own car reductio turns out to eat it. If atrophy establishes a trade rather than a verdict, that applies to verification atrophy too — and mostly we accept the trade, correctly. Not wiring motherboards is fine. Surface-level diagnostics are fine almost always. There is no argument here for hand-verifying everything, which would just be the atrophy argument wearing different clothes.
So “never outsource verification” is not achievable and not even desirable. What survives is weaker, and it’s a maintenance obligation rather than a prohibition:
Verification tooling drifts, misses things, and goes stale. Someone in the system has to be able to notice that and retool.
That is the mechanic-in-the-system point applied one level up — to the mechanics themselves. And the shocks example is the warning that this layer has already degraded in places: when the diagnostic culture becomes part-swapping, the capacity to ask “but why did it fail?” is the thing that went missing.
Since the atrophy is invisible from inside, it needs a signature. The reliable one: symptom-fixing without cause-finding. A system where failures get resolved but never explained is one whose verification layer has degraded into tool-execution, regardless of how much checking is nominally happening.
Not hypothetical, and the examples are first-person:
tools/tag-counts.py from the actual back-links. The standing rule is never hand-increment; the count is a derived report variable — verification correctly moved into a tool.raw/videos/2026-06-09%20karpathy-….md as broken because it never decoded %20. The file existed. Two links were nearly recorded as defects on the strength of a tool’s output — the exact failure above, caught only because the result looked wrong. The fix was to retool (decode before testing), not to check links by hand.raw/ immutability moved from a request in prose to an enforced PreToolUse hook — verification promoted from human discipline to tooling, which is the right direction and also creates a new thing that can silently stop working.Each is the pattern working as intended. The third bullet is also the standing risk: every one of those tools is now a place where a missed check would be invisible.
The move to defeat: offloading a capacity atrophies it, therefore the offloading is bad.
The premise is true of the automobile. Cars did atrophy human walking and endurance, measurably and at scale. Nobody concludes we should therefore walk everywhere — because the mobility bought is worth more than the capacity lost.
Atrophy establishes a trade, not a verdict. Whoever invokes it still owes the comparison. This kills the pure form of the argument, and it applies to writing (memory), calculators (arithmetic), and every other case where the objection sounds decisive on its own.
It also disposes of the sharpest-sounding version — “I could ship a program I don’t know how to debug.” That is the position of every driver alive. What it argues for is a mechanic somewhere in the system, not every driver machining their own pistons. The question is never does anyone still hold the skill but is the skill reachable when the thing breaks.
The exception that proves the rule: the trade is only available to someone who had the capacity. A child offloading before the capacity forms isn’t trading — there is nothing to trade with, and nothing for verification to run against. That is the real content of the garbage-in-garbage-out worry: the failure is not atrophy of a capacity but a capacity that never forms, leaving a user who cannot detect bad output. Sequencing is therefore a genuine design constraint, and it is why calculator access in schooling is staged by grade level rather than granted or refused wholesale.
Why arguments about “the average user” go in circles: the same tool is assistive for some users and amplifying for others.
AI is both, and which one it is depends entirely on who is holding it. So “is this tool a crutch?” is malformed. It is a crutch, and that is good: crutches are excellent. It is also an engine.
This dissolves a recurring standoff. One side describes the floor rising — for their median user the realistic alternative isn’t reading journals, it’s talk radio or nothing. The other describes ceiling users who no longer make the climb that would have made them formidable. Both are looking at real people; they are describing different halves of one distribution, and each argues a point estimate where a distribution is needed.
Note that the ceiling is not flattened. Capability still compounds — those with more of it extract more from the same tool — so leverage on cognitive ability increases rather than levels.
Most arguments here ask the wrong question. These tools change output, not IQ.
Population intelligence moves on health, nutrition, disease burden, and genetics. It does not move on tool availability. Which produces a diagnostic worth applying to any “technology X will make us smarter” claim:
Trace the arrows. If the causal chain runs tool → productivity → development → nutrition and disease → cognition, then the claim is about material conditions, and the tool is incidental to the cognitive part. The argument is true and it is not about the tool.
The template for what actually happens is Excel. It did not make accountants smarter. It made them enormously more productive, and expertise in the tool became a valuable skill in its own right. Nobody argues Excel made us dumber — and the reason is precisely the rule at the top: the user still has to know whether the number is right.
When a tool makes an existing measurement stop working, that is instrument failure, and the repair belongs at the instrument.
The clean case: students using AI may score better on an assessment while being less prepared for what the assessment was built to predict. That is not a claim about students. It is a claim that the assessment has decoupled from its target. Banning the tool restores the measurement only until the ban fails, which it does.
The repair is to assess what the tool cannot supply — live reasoning under questioning, which is why oral, in-person examination is AI-proof, and also why it is expensive. Note that this is the same capacity the rule at the top says must be preserved. An assessment that tests verification is automatically robust to tools that only do computation.
The constraint: installed-base resistance. A reform can be correct on the merits and still fail, because the people who must implement it were trained on the prior method and cannot verify the new one. Common Core mathematics is the worked example — a defensible attempt to teach why arithmetic works that ran into teachers and parents who could not check the new method against their own understanding, and lost. So “change the assessment” is a real answer with a real cost, not a free move. Expect the transition to be slow and to fail loudly in places where it is correct.