The difficulty sweet spot governs onboarding, curriculum learning, and the copilot trap. The support that never fades is the support that prevents the learning.
In 2025, gastroenterologists published a result that should unsettle anyone who has come to lean on a smart tool. Across several endoscopy centers, doctors had been using an AI system that highlights polyps on the screen during a colonoscopy, a real aid, the kind that catches a precancerous growth a tired human eye glides past. Then the researchers measured how those same doctors performed when the AI was switched off. Their adenoma detection rate, the share of colonoscopies in which they find a precancerous growth, the single best quality metric in the field, had fallen, from around 28% to around 22%.
Read that again. Routine help from the AI had left them worse at the core skill than they were before they ever used it. Not worse-without-the-AI-than-with-it, worse on their own than their own former unaided selves. The scaffold had quietly eaten the thing it was holding up. (It's one study, a measured signal rather than a settled verdict, but it's a clean, hard number.) And this failure has a name, an old one. It is the single most reliable prediction of a learning theory laid down by a Soviet psychologist who died in 1934, and the same curve that explains the deskilled endoscopist also tells you, with precision, how to onboard an engineer and how to train a neural network. They are not three analogies. They are one phenomenon.
Lev Vygotsky called it the Zone of Proximal Development: the gap between what a learner can do alone and what they can do with guidance. Learning, he argued, happens inside that gap, and the two ways to miss it are perfectly symmetric. Give a learner a task they can already do unaided and there is nothing to learn; the result is boredom. Give them a task beyond reach even with help, and there is nothing to grab onto; the result is frustration. Both produce the identical outcome: no learning. The productive band is the narrow zone between them, hard enough to stretch, supported enough to succeed.
The support has a name too: scaffolding, a term the psychologists Wood, Bruner, and Ross coined in 1976. And the crucial property of a scaffold, the one almost everyone forgets, is sitting right there in the metaphor. A scaffold is temporary. It is contingent (it responds to exactly what the learner can't yet do), it fades (you take it down as the structure rises), and it transfers responsibility (the building, in the end, has to stand on its own). A scaffold you never remove is not teaching the building to stand. It is holding it up forever, and quietly guaranteeing it never could stand without you. Hold that thought; it is the whole essay.
It would be easy to file all this under soft pedagogy, motivational-poster talk about “stretch goals.” It is not soft, and the reason is a striking piece of work from 2019. A group of researchers (Robert Wilson, Amitai Shenhav, Mark Straccia, and Jonathan Cohen) set out to find the optimal training difficulty for a learner improving by gradient descent, the basic engine of machine learning, and they derived it exactly. You learn fastest when you are getting things right about 85% of the time, failing, in other words, roughly 15%. They named it, deliberately, a “zone of proximal difficulty,” an open nod to Vygotsky. And here is the part that turns a tidy idea into a sharp one: the same 85% optimum held for artificial neural networks and for biologically plausible models of animal brains alike.
The difficulty sweet spot, in other words, is not a human quirk or a machine quirk. It is a property of how gradient-based learning systems behave, and humans and machines are both gradient-based learners in the relevant sense. (Be honest about scope: the precise 85% figure is derived for a specific class of problems, simple classification under gradient descent, so it is not a magic constant for every task in life. What holds up is that the sweet spot is real, quantifiable, and the same shape across radically different learners.) That shared shape is what lets a single curve govern three things technical leaders routinely get wrong.
Start with the most familiar. When a new engineer joins, you are choosing where on the difficulty curve to place them, whether or not you think of it that way. Hand them two weeks of trivial ticket-closing “to get familiar with the codebase” and you have parked them in the boredom zone: comfortable, safe, and teaching almost nothing, because they could have done every bit of it alone, which is the literal definition of below the zone. Throw them at a critical, ambiguous, under-documented system on day three with no support, and you have dropped them in the frustration zone: it is beyond what they can reach even by flailing, and what you harvest is not growth but a churn risk quietly updating their résumé.
The target is the band between, a task genuinely beyond their solo ability but reachable with a mentor, a pairing session, a worked example, a deliberately scoped first slice. Aim for the 85% feel: succeeding most of the time, failing often enough to actually be learning. (This is the same edge-of-ability that deliberate-practice research finds behind every expert: you grow where you are working just past what you can already do.) And then comes the move almost no onboarding plan contains: fade the support on purpose. The mentor who pairs on everything for six months and never steps back has not produced a senior engineer; they have produced a permanently junior one who happens to have been around a while. Contingent support, then a real transfer of responsibility. The hand-off is the point, not a nice-to-have you'll get to later.
Now the identical curve, written in code, because machine learning rediscovered the Zone of Proximal Development on its own and gave it a different name. In 2009, Yoshua Bengio and colleagues published “Curriculum Learning,” showing that if you feed a model its training examples in order (easy first, then progressively harder) it converges faster and generalizes better than if you fling them in at random. The reason is exactly Vygotsky's. An example the model already classifies correctly produces almost no gradient: nothing to learn from, the boredom zone. An example so far beyond the model's current ability that its guess is essentially noise produces a useless, even destabilizing gradient: the frustration zone. The real signal comes from examples sitting right at the model's current frontier of difficulty, its zone of proximal development, where it is right often enough to have a foothold but wrong often enough to have something to fix.
This is why hard-example mining, difficulty-ordered training, and the staged curricula used to train modern reasoning models all work: each keeps the model in its ZPD. And the fade is here too, wearing a disguise. In machine learning you don't withdraw the support, you raise the difficulty as the model improves, so the frontier travels with it and the model never coasts on problems it has already solved. Same curve, same imperative: keep the learner where it is productively failing, and move the bar as it gets better. A curriculum that never gets harder is the model's version of the mentor who never steps back.
Which carries us back to the deskilled endoscopist, and to the assistant on your own screen right now. An AI coding tool is, in these terms, scaffolding. And overwhelmingly it is scaffolding that never fades. It is there for the trivial task and the hard one, the first time you write an auth flow and the thousandth, on day one and on day one thousand, never stepping back, never handing over, always ready to produce the answer. The theory could not be clearer about what permanent scaffolding does: it keeps you in the zone of getting-the-answer and out of the zone of being-able-to. There are three escalating reasons this is worse than it first sounds.
First, un-faded scaffolding doesn't merely fail to help the competent, it actively harms them. This is the expertise-reversal effect, documented by Kalyuga and colleagues in 2003: instructional support that is highly effective for novices becomes, for experts, “not only ineffective but can have negative consequences.” The expert now has to reconcile the tool's guidance with the schema already in their head, and that reconciliation burns working memory the novice never had to spend. The very support designed to help turns into cognitive noise for the person who has outgrown it, training wheels that have started to trip you.
Second, the copilot's headline virtue, its frictionlessness, is, for learning, the defect. Robert Bjork's research on desirable difficulties shows that the conditions which make learning feel easiest in the moment produce the weakest retention later. The productive struggle (the retrieval, the generation, the debugging you had to fight through) is not an obstacle to the learning; it is the learning. A copilot is a machine for deleting precisely that struggle. It feels most helpful in exactly the place it teaches least.
Third, and this is why it is not just theory: the deskilling is measured. The endoscopists are one case. The autopilot is the other, and it is the one with a body count. Aviators have a phrase for pilots who can manage a plane only through the flight computer: “children of the magenta line,” after the colored course line the automation paints across the display. In 2009, Air France 447's airspeed sensors iced over at altitude; the autopilot did the correct thing and disengaged, handing control to humans who, it emerged, could no longer fly the raw airplane it had been flying for them. They stalled a perfectly working jet into the Atlantic. 228 people died. The autopilot was the scaffold that never withdrew; the manual skill beneath it had quietly rotted; the catastrophe arrived the instant the scaffold dropped. It is the copilot trap at the highest imaginable stakes, and it is an argument not against automation, but about what un-faded scaffolding does to the skill underneath.
A fair objection: isn't a copilot simply a tool, and don't experts use tools constantly? Yes, and that is the crucial scope, so here it is precisely. The copilot trap is not “AI assistance is bad.” Expertise reversal cuts both ways: the novice needs the scaffold, and the expert, having already built the skill, can use the very same tool without it becoming a crutch, because for them the scaffold has already faded. They are past the ZPD for that task; the assistant is just accelerating something they could do unaided. The trap is narrow and specific: it is scaffolding clamped onto a skill you have not yet built. The senior engineer who lets a copilot spit out the boilerplate they've written a thousand times is using a tool. The junior who has never once written the auth flow unassisted, and now never will, is acquiring a crutch, and the cruelest part is that the evidence of the trap stays hidden until the day the tool is gone, or wrong.
And the code-specific evidence, unlike that endoscopy number, is genuinely still emerging and contested. Productivity plainly rises with these tools; whether net skill erodes or instead shifts upward toward higher-level work is honestly unsettled, and reasonable people are arguing it right now. So the claim here is not “AI makes you worse.” It is narrower and harder to dismiss: permanent scaffolding risks atrophy, the theory predicts it, and some hard measurements already confirm it, which is reason enough to design against it rather than to assume it away.
Here is the one move all three applications share, and it is the one nearly everyone forgets, because it is the unglamorous half. Designing the support is easy and obvious; everybody does it. Designing the removal of the support is the actual skill. Match the difficulty to the learner's current frontier, aim the 85% band. Scaffold the gap. And then engineer the scaffold's withdrawal as deliberately as you engineered the scaffold itself.
Vygotsky's insight, ninety years on, turns out to be one of the quietly load-bearing design principles in all of technology, and it compresses to a single uncomfortable sentence: the support that never fades is the support that prevents the learning. The boredom of the trivial onboarding task, the noise of the impossible one, the model coasting on examples it already aced, the endoscopist who can no longer see the polyp without the box drawn around it, they are the same failure wearing four costumes, a learner held outside the productive zone by too little challenge or too much help. The fix is never willpower, and it is never simply “more support.” It is to put the learner where they are productively failing, hold them there with a scaffold, and then, on purpose, on a schedule, as carefully as you built it, take the scaffold down. Build the fade in, or one day the fade builds itself: the autopilot clicks off, the AI goes dark, the mentor moves on, and you discover exactly how much of the skill was ever really yours.
The copilot trap hides until the scaffold drops. A record of who did what is how you see it coming.
The cruelty of permanent scaffolding is that the deskilling stays invisible until the tool is gone, or wrong, and the last question this essay asks is “how much of the skill was ever really yours?” That is an attribution question, and it gets sharper, not softer, when the assistant is an autonomous agent and the work product is a mix of what it did and what it merely passed through. Chain of Consciousness anchors each action to a tamper-evident record, so the provenance of a result, what was generated, what was reviewed, what was actually produced unaided, is a fact you can read off the chain rather than a claim you take on faith the day the autopilot clicks off.
See a verified action chain · Hosted Chain of Consciousness
pip install chain-of-consciousness · npm install chain-of-consciousness