Keep the hard part

1. Opening Claim

The instinct to keep AI away from anything that requires real thinking is not paranoia, and it is not technophobia. It is a correct read of a mechanism, applied with the wrong tool. Skills decay when they stop being used. That is true of a surgeon who stops operating, a pilot who flies only on autopilot, and an engineer who stops debugging because a model hands back an answer that looks finished. The person refusing to offload mental effort to AI has identified something real: cognitive load is not a cost to be eliminated, it is the thing that keeps the capability alive.

Where that instinct goes sideways is in the conclusion. Avoidance treats the technology as the variable. It is not. The variable is whether the work still forces you to engage. You can atrophy your problem-solving skills with no AI in sight by outsourcing every decision to a senior colleague, by copy-pasting from documentation without reading it, or by letting a framework make all the architectural choices for you. The degradation pattern predates large language models by decades. AI just makes the offloading frictionless, which means it makes the decay faster.

So the real claim is narrower and more useful than “don’t use AI for hard things.” It is this: any intelligence, human or machine, loses the function it stops exercising. The defensible position is not abstinence. It is designing how the tool sits inside your workflow so that the hard part of the work still lands on you, and the model handles the parts that were never building the skill in the first place. That is a system design problem, not a willpower problem, and it has concrete answers.

2. The Original Assumption

The original assumption goes like this: if I let AI solve the problems, I will stop being able to solve them myself. It is intuitive because it maps onto lived experience. Most people who have used GPS heavily in an unfamiliar city know the feeling of being unable to reconstruct the route without it. The 2000 study of London taxi drivers by Maguire and colleagues found measurable differences in the hippocampus tied to years of building and recalling routes manually. Stop building those routes and the structure that supported them has no reason to persist. The brain is metabolically expensive and it prunes what it does not use. That is not a metaphor, it is how the system manages cost.

Applied to problem-solving, the logic holds up to a point. When you hand a model a bug and accept its fix without tracing why the bug existed, you skip the exact step that builds debugging intuition: forming a hypothesis, testing it, being wrong, and narrowing down. When you ask for an architecture and ship it without understanding the trade-offs it made, you never develop the judgment that lets you make that call next time. The reasoning you skip is the reasoning you fail to internalize. Over enough repetitions, the muscle that used to do that work gets weaker, and you become dependent on the thing that replaced it. The fear is that you wake up one day unable to function without the system, and worse, unable to tell when the system is wrong.

That last part is the strongest version of the argument, and it is worth taking seriously before moving past it. Skill loss is not just about being slower without the tool. It is about losing the ability to evaluate the tool’s output. A developer who has stopped reasoning about concurrency cannot catch the race condition the model confidently introduced. A writer who has stopped structuring arguments cannot tell that the generated essay is fluent and hollow. The danger compounds: you lean on the system more precisely because your own judgment has eroded, which erodes it further. This is the feedback loop the refusal is trying to break. The instinct is sound. The blanket solution is too blunt for the actual shape of the problem.

3. What Changed

What changed is the recognition that the dangerous variable was never “using AI.” It is the mode of use. There is a hard line between two interactions that look identical from the outside. In one, you offload the reasoning: you ask the model to solve the problem and you accept the result. In the other, you offload the labor while keeping the reasoning: you do the thinking, form the judgment, decide the approach, and use the model to execute the parts that are mechanical, repetitive, or already inside your competence. The first mode atrophies the skill. The second one frees up attention to spend on the skill. Same tool, opposite outcomes, and the difference is entirely in how the workflow is structured.

This reframes the whole question as design rather than discipline, which matters because discipline does not scale and design does. Relying on willpower to “not over-rely on AI” fails the same way every willpower-based system fails: under pressure, on a deadline, when tired, the path of least resistance wins. The model is always one keystroke away from doing the thinking for you, and in a hard moment you will let it. A designed system does not depend on you making the strong choice every time. It makes deliberate engagement the default by building friction into the right places and removing it from the wrong ones. You constrain where the model is allowed to operate, and you reserve the cognitively load-bearing steps for yourself by construction, not by intention.

Concretely, this looks like inverting the usual pattern. Instead of asking the model for the answer, you produce the answer and ask the model to attack it, to find what you missed, to argue the opposing case. Instead of generating the architecture, you decide the architecture and use the model to enumerate the trade-offs you should pressure-test. Instead of accepting a fix, you require yourself to state the root cause before you are allowed to apply one. Each of these keeps the hard cognitive work on the human and pushes the model into a role that sharpens judgment instead of replacing it. The shift is from AI as an oracle you consult to AI as a system you design around a human who stays in the loop on purpose. That is the move, and the rest of this is about how to build it so it holds up under real conditions.

4. Mechanism of Failure or Drift

The mechanism is not dramatic, which is exactly why it is dangerous. Skill does not vanish in a single session. It erodes one skipped repetition at a time. Picture the workflow as three stages: a problem comes in, reasoning happens in the middle, an answer comes out. The reasoning stage is the load-bearing one - it is where hypotheses get formed, tested, and corrected, and it is the only stage that builds capability. When you let the model occupy that middle stage and you keep only the input and the output, the workflow still runs. Problems go in, correct answers come out. That is the trap. The system keeps producing green results while the human capability behind it quietly drifts red. You are watching the wrong gauge. ‘Did it work’ stays lit long after ‘can I still do this’ has gone dark.

The second failure is subtler, and it targets designed systems specifically - the ones built with friction in the right places. Friction is metabolically and operationally expensive, and under deadline people route around it. The rule that says ‘state the root cause before applying the fix’ holds right up until the sprint is on fire, and then it degrades into a checkbox you satisfy by pasting the model’s own explanation into the box labeled ‘my reasoning.’ This is automation bias: the documented human tendency to accept a machine’s output as correct and to weight it above your own judgment. The verification step does not disappear, which is what makes it hard to catch. It collapses into theater. There is still a stage on the board called ‘review,’ but you are rubber-stamping, not reviewing. Human factors research has a name for the broader condition - the out-of-the-loop performance problem: the operator supervising an automated process loses situational awareness precisely because supervising is not the same as doing.

The degradation runs in a specific order, and the order is what makes it lethal. Generation skill goes first - you lose the ability to produce the solution unaided. Evaluation skill goes second, and it goes silently. For a while you can still tell whether an output is right even after you can no longer generate it yourself, so you feel safe. Then that fades too, and now you are consuming outputs you can no longer verify while still believing you can. The loop compounds in the worst direction: as the model improves, visible errors get rarer, your verification muscle fires less often, and it atrophies further - so the one time the model is confidently wrong about a race condition or a load-bearing assumption, the person who was supposed to catch it no longer can. There is a blunt diagnostic for where you actually sit in this loop. If you cannot predict, in rough terms, what the model is going to say before it says it, you have already left the loop. You are not collaborating with the system. You are being fed by it.

5. Expansion into Parallel Pattern

None of this is an AI story. It is the automation-and-cognition story, and the definitive version of it was written in 1983, before deep learning existed. Lisanne Bainbridge’s paper ‘Ironies of Automation’ laid out the structural problem: when you automate a process, you hand the routine, easy cases to the machine and leave the human with the rare, hard exceptions. But it was handling the routine cases that built the competence to handle the exceptions. So automation systematically strips practice away from the exact people you are counting on to take over when it fails, at the exact moment they are least prepared. AI assistance in knowledge work is not a new phenomenon. It is a fresh instance of a law that has been operating in cockpits and control rooms for forty years.

The parallels are concrete and they all break the same way. Aviation: in 2009, Air France 447 lost its airspeed readings over the Atlantic, the autopilot handed control back to the crew, and a flyable aircraft was stalled into the ocean by pilots who rarely flew manually at altitude. The skill existed on their certificates. It had not been exercised in the conditions that counted. Medicine: radiologists leaning on computer-aided detection show automation bias - missing findings the tool failed to flag that they would otherwise have caught, and faltering when the tool is absent. Navigation: the same effect that thinned the London taxi drivers’ advantage shows up in anyone who follows turn-by-turn directions through a city for years and then cannot draw the map. Arithmetic and the calculator is the oldest version, and the mildest, which is why it is instructive - we made that trade consciously and bounded it. In every case the tool itself was fine. The failure was offloading the load-bearing cognition with no design to preserve it.

What separates the cases that degraded from the ones that did not is a single variable, and it is not the technology. It is who held the reasoning. The calculator did not deskill mathematicians, because the mathematician still decides what to compute and why - the calculator removed arithmetic labor, not mathematical judgment. Where the tool stayed an executor and the human stayed the decision-maker, skill held. Where the tool quietly became the decision-maker and the human slid into rubber-stamping, skill collapsed. Same general law, two opposite outcomes, and the fork between them is a design choice about role allocation, not a property of the tool. That is the proof that the original instinct generalizes correctly. Any intelligence loses the function it stops exercising, and the only control point that changes the outcome is the deliberate assignment of which cognition stays with the human.

6. Hard Closing Truth

Here is the part that does not flatter anyone. Refusing to use AI for hard thinking does not protect your problem-solving skills. It removes one source of decay and leaves every other one running. You can erode your judgment with a senior colleague who answers every question before you have struggled with it, with documentation you paste from without reading, with a framework that makes the architectural calls so you never have to. The abstainer and the person who offloads everything to the model are making the same error from opposite ends. Both treat the tool as the thing that determines the outcome. It never was. The thing that determines the outcome is where the reasoning lives.

So the discipline is not avoidance and it is not willpower, because both fail under the same pressure that makes offloading tempting in the first place. The discipline is design, applied once, in advance, while you are calm enough to decide it. Name the cognition that is load-bearing for the capability you intend to keep, and refuse to let the system perform that part - no matter how cleanly it offers to. Hand it everything else without guilt. The line that matters is not between AI and no AI. It runs between the reasoning you own and the labor you delegate, and it has to be wired into the workflow, because in the moment you will not choose it freely. A system that depends on you making the hard choice every time is a system that has already failed.

The people who come out of this ahead are not the ones who kept AI at arm’s length, and they are not the ones who handed it the wheel. They are the ones who can still do the hard part alone and choose, deliberately, to delegate the rest - because that is the only position from which you can tell when the machine is wrong. Verification is the last skill you can afford to lose and the first one that goes quietly, while every gauge still reads green. Keep it sharp by using it, on purpose, on work that matters, even when the model could have done it for you. The question was never whether the machine can do your thinking. It is what is left of you when it does.