AI didn't make me a worse coder. It made me a worse reviewer.

I built a lot of apps last year. I approved most of the code and commits that went into them, and a good portion of it I could not explain.

Not "couldn't explain to a junior." Couldn't explain to myself. The tests were green, the diff looked like something I would have written, and I hit approve. If you had stopped me forty minutes later and asked why that function needed a lock, I would have had to go read it again like it was someone else's code.

Which, in a sense, it was. And because most of these were my own projects, there was no second reviewer downstream of me. I was the entire quality gate — and the gate had quietly stopped reading.

I am not going to pretend this is a novel observation. If you read dev.to you have already seen this post four times this spring, and if you read r/ExperiencedDevs you have seen the thread where someone calls themselves "a tourist in their own codebase" and four hundred people say yeah, same. One in five developers in the 2025 Stack Overflow survey picked "I've become less confident in my own problem-solving" as a top frustration with AI tools. The fear is not underreported. It might be the most reported feeling in software right now.

So this isn't a diagnosis post. The diagnosis is done. What I couldn't find anywhere was an honest answer to the next question: every fix anyone proposes for this has the same shape, and that shape is known to fail. Including the one I spent two weeks designing.

That's what I want to work through, and then I want to ask you something.

What actually decays

The reframe that finally made this click for me came from aviation, and it's about thirty years old.

When researchers tested airline pilots who had trained on manual flight but then spent their careers flying highly automated aircraft, they found something specific. The procedural skills — scanning instruments, hand-flying the aircraft — were rusty but largely intact. The pilots could still fly the plane.

What had cratered were the cognitive skills. Maintaining awareness of where the aircraft actually was. Tracking what the next step should be. Recognizing and handling an instrument failure. (This is Casner et al., 2014; the FAA's response was to recommend that pilots hand-fly for the majority of flights.)

Read that again with your own job substituted in. The typing survives. The model in your head is what goes.

A 2024 review by Brooke Macnamara and colleagues in Cognitive Research extends this to AI assistants specifically, and makes the argument sharper than I would have dared: because AI mimics cognitive work rather than mechanical work, and because cognitive skills decay faster than physical ones, AI-induced skill decay should be worse than the automation decay we already documented in cockpits.

That's the reframe. It isn't that AI makes you slow at writing code. It's that AI is very good at the exact part of the job that used to build your judgment as a side effect, and the judgment does not maintain itself in storage.

Which matters, because look at what the job is now. Reviewing. Catching the thing the model was confident about and wrong about. Knowing what to build. Deciding when the plausible answer is the wrong answer. Every one of those is the cognitive column, not the procedural one. We have automated our way out of the reps that produced the only skills we still get paid for.

You cannot feel this happening

Here's the part that changed how I think about the whole problem. There are three independent findings that all say the same uncomfortable thing: you are structurally unable to self-assess this.

One. Macnamara's review names the mechanism directly. Ordinary skill decay you notice, because you stopped doing the task. AI-induced decay hides, because you didn't stop doing the task — you kept shipping, kept reviewing, kept closing tickets. Only the cognitive engagement stopped. A surgeon still completing successful operations has no signal that their judgment has softened. Neither do you, with a green CI badge.

Two. METR ran a randomized controlled trial in 2025 with sixteen experienced open-source developers on 246 real tasks in their own repositories — projects averaging five years of their own contributions. Developers predicted AI would make them 24% faster. Afterward, they estimated they had been about 20% faster. They were 19% slower.

Sit with that. Not "they were wrong about the tool." They were wrong about their own experience, immediately after having it, on code they knew better than anyone. And the slowdown was worse on tasks where they had high prior experience. Whatever perceptual instrument you'd use to detect this in yourself, that study is the calibration check, and it failed.

Three. The classic testing-effect result from Roediger and Karpicke (2006): students who re-read material rated themselves more confident about remembering it than students who self-tested — and then recalled 40% versus 61% a week later. The re-readers read the passage 14.2 times on average. The testers read it 3.4 times. Re-reading felt like learning and wasn't.

Re-reading a diff until it looks fine is the same operation. It builds confidence and not much else.

So: the decay is invisible by construction, our self-reports are demonstrably inverted, and the review habit we all use produces exactly the false confidence the memory research warns about. Any solution that depends on noticing you have a problem is dead on arrival.

Try this before you read on

Two minutes, on your own code. I'd genuinely like to know what happens.

1. Open the last commit or PR you shipped that an AI mostly wrote. Don't read it yet.
2. In a scratch file, write what it does, why it was needed, and what breaks if you delete it.
3. Now read the diff.

Note where you stalled. Not whether you were "right" — where you stalled.

This has a name in cognitive science: the illusion of explanatory depth (Rozenblit & Keil, 2002). People rate their understanding of how things work as high, are asked to produce an actual causal explanation, and then revise their own rating sharply downward. The effect is much stronger for explanatory knowledge than for facts or procedures — meaning it's strongest for precisely the kind of knowing that code review requires. It's also strongest when the mechanism is visible in front of you, which is a fairly brutal description of reading a diff and feeling like you understand it.

The MIT Media Lab found a version of this last year: participants who wrote essays with an LLM struggled to quote the essay they had finished minutes earlier. Small study, preprint, treat it lightly. But "I shipped this and can't quote it" is a sentence I recognize.

Why I'm not building a skill score

My first instinct was a dashboard. Measure me. Your coding ability: 73% and falling. A number, a trend line, and enough dread to keep me honest.

I'm glad I read the habit-formation literature before writing any code, because that idea is a known failure mode.

A CHI 2016 study looked at Lift (later Coach.me), one of the most popular habit apps of its era. Streaks and reminders did drive repetition — that part works. But they created a dependency: the behavior was attached to the app rather than to the person. Users performed for the streak. And then, inevitably, they stopped opening the app — the same paper notes the wider pattern, that around 74% of users abandon health apps after ten uses — and the behavior went with it. The authors' framing is that these features introduce fragility into exactly the thing they were meant to make durable.

Extrinsic reward crowding out the internal motive is old, well-replicated psychology. A skill score is that trap wearing a developer hat: gamified anxiety. It tells you you're declining, which feels bad, which makes you avoid the tool, which makes the number worse. Week two you uninstall it.

And there's a cleaner objection. A score measures output. Understanding isn't output — it's a capacity, and the only way to observe a capacity is to make someone use it. You cannot report understanding. You can only demonstrate it.

Why the usual advice doesn't work either

This is the part I expect people to argue with, so let me be careful.

Every article on this topic — including the good ones — ends with roughly the same list:

• have no-AI days
• try it manually for fifteen minutes first
• 20–30 minutes of unassisted problem-solving daily
• close the tool and explain every line out loud
• write the architecture yourself

None of this advice is wrong. I think all of it works, when done. But look at the shape of it: every item is discipline-shaped, scheduled, and outside the workflow. It's a separate practice, competing for time, sustained by willpower, with no cue and no consequence for skipping it.

That is structurally the same object as the habit app. It's the pre-app version of the same object. And the reason to expect it to fail is the reason the article gave you in paragraph one: you're being asked to voluntarily add friction to fix a problem you cannot perceive yourself having, using time pressure as the counterweight, in an industry that measures you on what you shipped, never on whether you understood it.

Also — the specific advice to "rotate AI-free days" is trying to solve skill decay with abstinence, and the research doesn't actually support that framing. Which brings me to the useful finding.

The finding that changed the design

In January 2026 Anthropic published a randomized controlled trial (Shen & Tamkin) that is, as far as I can tell, the most directly relevant study that exists. 52 mostly-junior engineers learned Trio, an async Python library none of them knew. Half had an AI assistant; half had docs and web search.

The headline is grim and got all the coverage: the AI group scored 50% on the comprehension quiz versus 67% for the hand-coders — about two letter grades, on concepts they had used minutes earlier. The largest gap was on the debugging questions, which is the precise skill you need to catch bad AI output. The speed advantage was about two minutes and wasn't statistically significant. Same speed. Much less understanding.

But the finding nobody quotes is the one underneath it. The researchers identified six distinct interaction patterns, and three of them preserved learning even with full AI assistance. High scorers averaged 65–86%. Low scorers were under 40%. Same tool, same time budget, double the comprehension.

The three that worked all involved cognitive engagement at the moment of generation:

• generate the code, then ask follow-up questions about it
• ask for code and an explanation together
• ask conceptual questions, then write the code yourself

The three that failed: delegate wholesale, drift into delegation over the session, or use the AI to iteratively fix things without ever understanding them. (Participants in that last group were also slower.)

So the variable is not how much AI you use. It's whether an act of retrieval or explanation happens at the point of use. That's a much smaller intervention than "no-AI Fridays," and unlike willpower, it's the kind of thing software can put in front of you at the right moment.

Microsoft Research and CMU landed in the same place from a different direction at CHI 2025. Surveying 319 knowledge workers across 936 real AI-assisted tasks, they found higher confidence in the AI predicted less critical thinking, while higher confidence in your own ability predicted more. Their design recommendation was for tools that use "proactive prompts" and act as a provocateur rather than an answer machine.

I read that and realized the intervention I wanted had already been specified by people with better data than me. Nobody had built it into the place where the work actually happens.

What I want to build

Not a score. Not an app. A review-time forcing function — something in the hook or MCP layer between the agent and the merge, where I already am.

The agent drafts a change. Before I can rubber-stamp it, it asks me one question:

• What does this change do?
• What breaks if we remove it?
• Where's the edge case this misses?

Then it does the part that makes it more than a journaling prompt: it compares my answer to the actual diff and shows me where my model diverged. Over time the signal isn't a vibe, it's a record — did my explanation match the code? Did I flag the thing that later broke? That's review accuracy and bug-catch rate, which are evidence, not a self-report.

Design constraints, all of them derived from something above rather than from taste:

• In-workflow, not an app. Out-of-workflow practices are the failure mode of the entire genre.
• One question, ~20 seconds. Anything longer loses to delivery pressure, which is the honest reason none of us do the 20-minute practice.
• No score, no streak, no dashboard. Lift, and everything downstream of Lift.
• Explanation-shaped, not recall-shaped. The illusion of explanatory depth is where the gap is largest; quizzing trivia would miss it.
• Retrieval before review, not after. Roediger & Karpicke — you have to attempt the answer before seeing the material, or you've just re-read the diff with extra steps.

The adjacent shape I keep sketching is spaced repetition over your own codebase — Anki for the repo. "Why does this function exist?" "What would break if you deleted it?" I think it's weaker: it's out-of-workflow again, and it drifts toward recall when the thing that matters is explanation.

Where I think this might be wrong

Three real holes, and I'd rather name them than get talked out of them in the comments.

It might become another rubber stamp. Anything mandatory gets gamed. I'd type "makes the retry idempotent" seventeen times a day without thinking. Every forced-friction tool ever built has hit this wall, and I don't have a good answer beyond "vary the question and only fire on non-trivial diffs," which is a hope, not a design.

Something has to grade the explanation, and that something is an AI. Which means I'd be offloading the assessment of whether I understood something to the same class of system whose output I stopped understanding. I think this is survivable — comparing my prose against a diff is a much narrower task than generating the diff — but I notice the shape of it, and it bothers me.

The friction lands in the wrong place. 66% of developers say their top AI frustration is code that's "almost right, but not quite," and 45% say debugging AI output already takes longer than writing it themselves. Those people are not short on friction. Adding a question to their review might be adding a tax to the exact step that's already the expensive one.

The question

I'm asking because I have a rule against starting things right now — one flagship for 90 days, everything else goes in a parking lot file. This idea is in the parking lot. It comes out only if the reaction here says it should, so this is a real question with a real consequence, not a call to action.

Three things, and short answers are genuinely more useful than long ones:

1. Did you run the two-minute test above? What happened — did you stall, or was it fine? Just say "stalled" or "fine" if that's all you've got. I especially want to hear "fine," because if most people are fine then I've written 1,800 words about my own bad habits.
2. What's your actual anti-atrophy practice — not the one you'd recommend, the one you did this week?
3. Would you install this? And if you think it's a bad idea, say so plainly. "This would annoy me into uninstalling it in a day" is the most useful comment I could get, and it costs you one line.

I've been assuming that because I can feel the erosion, a tool should exist. The research above says pretty clearly that my feelings about my own competence are not evidence. Yours might be worth more than mine.

---

Sources, if you want to check my work: METR RCT (2025) · Shen & Tamkin, Anthropic (2026) · Macnamara et al., Cognitive Research (2024) · Lee et al., CHI 2025 (PDF) · "Don't Kick the Habit," CHI 2016 · Roediger & Karpicke (2006) · Rozenblit & Keil (2002) · Stack Overflow Developer Survey 2025

Comments

[Dean Lee]

This is where review becomes the hidden tax. The model saves time on the first draft, then spends part of that gain on checking diffs, tests, and edge cases you would have noticed while writing it by hand.