In early 2026, Anthropic published a study on what happens to developer skill formation when AI coding assistants are part of the workflow. The headline number — a ~17-point lower comprehension-quiz score when learning a new library with AI assistance (50% vs 67%) — made it across CIO, Futurism, Psychology Today, and a thoughtful Substack post from Addy Osmani within days.
If you write code for a living, this is the single most useful AI-cognition study published this year. Here's what it found, what it didn't, and what to actually do about it.
What the study measured
The Anthropic protocol randomized 52 mostly-junior developers (all with at least a year of Python) to learn Trio, an unfamiliar async library. One group had AI coding assistance available; the other coded by hand. Immediately afterward, both took the same comprehension quiz. The authors are explicit that this measures immediate comprehension, not long-term retention or on-the-job performance.
The finding that stuck: the AI-assisted group averaged 50% on the quiz versus 67% for the hand-coders — about a 17-point gap, nearly two letter grades. They shipped working code but understood the library less well.
A different study is often quoted in the same breath, and the two get blurred together — so, to be precise: METR's 2025 randomized trial of experienced open-source developers (a separate population, separate researchers) found they took about 19% longer on their own tasks when AI tools were allowed — the review-and-integrate overhead outweighing the time saved on generation. Different study, different population; we keep them apart.
The complementary Psychology Today framing is even more direct: cognitive offloading — using a tool to reduce mental effort on a task — appears to reduce new skill formation in particular. The skills you already have stay reasonably intact. The skills you would have built by struggling through a task on your own are the ones that don't get built when the AI handles the struggle for you.
Futurism's coverage sharpens the dev-community side of this with quotes from engineers describing the experience: working faster, but feeling less like a software engineer and more like an evaluator of AI output. VirtusLab calls it "cognitive debt" — the deferred cost of shipping code you don't fully understand, paid back when production breaks.
Why this happens
There is a clean mental model. When you struggle through a problem yourself, you encode the problem's shape: where the edges are, which pieces fight each other, what trade-offs are real. When the AI takes the struggle, you encode the output — but you don't encode the path. The output is what you need to ship. The path is what you need to remember six months later when the same kind of problem shows up.
This is exactly the cognitive-offloading pattern that pre-dates AI. We have always known that using a calculator means you can't easily do the math without one. We've known since the Sparrow 2011 "Google effect" paper that having Google means you remember where the answer is better than what the answer is. AI coding assistants are the same logic, applied to the act of building software.
The catch is that with code, the "where" doesn't help as much as it does with facts. With facts, knowing where the answer is is often good enough. With code, knowing where the answer is doesn't help you debug a system that doesn't work the way the AI predicted.
How to keep your skills in shape
Addy Osmani's Avoiding Skill Atrophy in the Age of AI is the best practitioner take we've seen. The pattern he describes — and that's echoed across the academic + industry coverage — clusters around four working habits.
1. Use AI for conceptual inquiry more than for code generation
The Anthropic study has a specific finding inside it: developers who used AI primarily to understand concepts scored 65% or higher on comprehension tests, while those who used it primarily to generate code scored under 40%. The difference is the cognitive act. Asking "explain how this pattern is meant to work" loads your brain with the explanation. Asking "give me the code that uses this pattern" loads your codebase with the code, and your brain with very little.
2. Read what the AI gave you, line by line, before committing
This is the cheapest, most effective habit. The encoding gap shrinks dramatically when you trace the output yourself before it lands. Treat AI output the way you'd treat a senior engineer's PR: read it carefully, run it in your head, ask whether it does what you think it does. You'll catch hallucinated APIs faster, and you'll keep your own model of the codebase alive.
3. Do at least one non-trivial thing a day without AI
Pick one small piece of real work each day and do it without AI help. Could be a refactor. Could be a tricky test. Could be a logic walk-through of an existing module. The goal is not to be slow on purpose — it is to keep deliberate practice somewhere on the calendar, even when AI could do the work faster.
This is exactly the role Senwitt's Code Skill is built for: short daily reps in reading code, predicting behavior, spotting bugs, and reasoning through logic. Not long-form practice. Not study. Just a small daily moment that sits next to AI use, not against it.
4. Pair-program with a human regularly
The most consistent finding across the dev-skill-atrophy coverage is that human pairing — where another engineer reasons out loud alongside you — survives AI-assisted workflows in a way that solo AI use does not. The conversation forces both of you to encode the problem.
What this is not
Skill atrophy is real, but the framing has limits.
The Anthropic study does not show that AI tools are net-negative for engineering productivity. They are widely shown to be net-positive for shipping output. The question is about the gradient of skill development underneath the productivity gains — which is the right question, but it's a narrower question than "are these tools good?"
It also does not show that AI tools should be removed from workflows. Senwitt's editorial position aligns with the practitioner consensus: AI tools are part of the modern stack, and the right response is to use them deliberately, while keeping the underlying skills in practice. That is what Senwitt is for.
Where to go next
- The Code Skill page for what a daily code-reasoning rep looks like inside Senwitt.
- The persona page for developers if you're an engineer thinking through your own AI-use boundary.
- The cognitive debt explainer for the broader MIT framing this all sits inside.
- The AI overreliance research page for the cross-domain version of the same argument.
Senwitt doesn't claim a daily Set will fix engineering skill atrophy on its own. It claims, narrowly, that practice keeps practice alive — and that for AI-heavy engineers, having seven daily minutes where you reason through code without AI is a small bet that compounds.
A note for engineering managers
If you run a team, the skill-atrophy pattern has implications beyond individual habits. Three structural moves worth considering.
Make pair-programming a default again. The strongest finding in the dev-skill-atrophy research is that human pairing survives AI workflows. Solo AI use is where the gap shows up most. Even one weekly pairing session — with the AI on, but with both engineers reasoning out loud — produces meaningfully better encoding than solo work.
Protect non-AI windows in onboarding. Early-career engineers are the population whose skill formation is still happening. If their first six months consist almost entirely of AI-assisted output, they ship a lot — but they don't build the deep model of the codebase that lets them debug it later. A simple rule: for the first month, AI is off for at least the first hour of focused coding each day. The remainder of the day is normal.
Reward understanding, not just velocity. PRs that ship working code with strong understanding (visible in clear PR descriptions, real reasoning in review comments, ability to explain alternatives) signal practice that compounds. PRs that ship working code with vague descriptions and minimal review depth signal accelerated output without underlying encoding. Both are valuable, but they're different signals — and code-review culture is where you reinforce the difference.
These are not bans on AI. They are guardrails that preserve the skill-formation pathway underneath productive AI use. The team that does both — uses AI heavily and protects practice — outperforms the team that only does one.
