The skills that decay first when AI writes your code

If most of your code now arrives as a diff you review instead of a file you type, you have probably had the moment this article is about. You went to write something small by hand, a filter over an array or a date comparison, and it came out slower and with more mistakes than it used to. One slow attempt proves nothing by itself. You might have been tired, or the task less familiar than it felt. But there is a specific mechanism in the memory literature that predicts exactly this experience, and predicts why you would be the last to notice it. This piece lays out that mechanism, then makes a reasoned guess about which skills it hits first and gives you a ten-minute test to see where you stand.

Why reading AI output feels like understanding

Two findings from memory research matter here. The first is the testing effect. In Roediger and Karpicke's 2006 experiments, students either repeatedly re-read a prose passage or repeatedly tested themselves on it. A week later, the students who had tested themselves retained substantially more, even though the re-readers had felt more confident during study. Retrieving knowledge strengthens it in a way re-exposure does not, and re-exposure produces a fluency that feels like knowledge.

The second concerns how recall and recognition hold up over time. In Bahrick's fifty-year study of Spanish learned in school, people who had not used the language since class could still recognize vocabulary at rates far above what they could produce from memory. Recall scores fell steeply in the first years after training while recognition stayed comparatively high across decades. That is school Spanish, not code, and it does not license a general law about memory. What it does show is that recognizing an answer and producing one are separable tasks, and that the two can drift far apart without the person noticing.

Neither experiment involved programmers, and reviewing a generated diff is not literally re-reading a passage. The code is usually novel, and a careful review involves real reasoning about whether it is correct. The narrower parallel is the one worth taking seriously: a review-heavy workflow gives you constant exposure to plausible code and very few occasions to produce any from memory, and exposure is exactly the activity that left Roediger and Karpicke's re-readers feeling confident while doing little for their retention. When your assistant writes a correct Promise.allSettled call, recognizing it and producing it at a blank buffer are different retrieval tasks, and if the recall-versus-recognition pattern transfers to code at all, producing is the side at risk. The gap stays invisible from the inside, because every review keeps confirming that you still recognize this stuff.

Your felt sense of the workflow is not a reliable instrument either. In METR's 2025 randomized trial, experienced open-source developers using early-2025 AI tools on their own mature repositories completed tasks 19% slower on average, while estimating they had been about 20% faster. That is one narrow setting, and the authors are explicit that it should not be stretched into a claim about developers in general. The modest lesson survives the caveats: in at least one careful measurement, developers' sense of their own speed pointed the opposite direction from the stopwatch, so "I would notice if my skills were slipping" deserves less confidence than it usually gets.

The order things go in

Nobody has run the longitudinal study that would rank skill decay in working engineers, so treat this ordering as a hypothesis with a logic you can argue with. The logic follows from the recall and recognition split above. Skills that depend on exact production from memory should fade first, because production is what fell steeply in Bahrick's data, while skills that lean on recognition and judgment get some incidental exercise every time you review a diff, so they should hold on longer. Each entry says why it sits where it does, and the placement is exactly the part worth arguing about.

Syntax recall without autocomplete

This goes first because it is pure production and the modern workflow removes the rep entirely. Between editor autocomplete and agents that write whole files, you can go weeks without producing a line of syntax from nothing. What fades is exact production. Does splice or slice mutate? What is the argument order of reduce? What does Promise.any reject with? You still recognize all of it on sight, which is why the loss hides so well. The tell is a whiteboard or a screen-share with autocomplete off, when the words simply do not come.

Reading unfamiliar code cold

This sits second because the rep shrinks drastically without vanishing. Landing in an unfamiliar codebase, you can ask for a summary of any file, and the summary is usually decent. What disappears is building the model yourself: tracing a value from where it is created through everything that touches it, until the structure sits in your head. A summary hands you the conclusion without the construction, and the construction was the skill. The consequence shows up in review. When a generated explanation is subtly wrong about control flow, the atrophied reader nods along, and the same reader approves subtly wrong generated code for the same reason.

Debugging without pasting the stack trace

The pre-AI debugging loop was hypothesis-driven. Read the trace bottom-up, guess a cause, pick the cheapest experiment that could falsify the guess, run it. Pasting the trace into a chat window jumps straight to a proposed answer, so the hypothesis-forming muscle gets no work, and forming a hypothesis is production in the same sense that writing syntax is, which is why it sits this high on the list. The atrophy is harmless while the model's first guess is right. It hurts on the bugs where the guess is wrong: a race that only appears under production load, or an internal service the model has never seen. On those bugs the model needs you to drive the loop, and a loop that has not run in months localizes slowly.

SQL by hand

ORMs started this erosion and assistants finished it. You describe the query in English, something plausible with a LEFT JOIN and a GROUP BY comes back, and it usually works. What decays is the model underneath: what a grouped result actually contains, and why a WHERE clause on the right table silently turns your left join into an inner one. It sits below debugging because most engineers still read schemas and query results daily, which keeps the recognition side half-alive. You notice the gap the first time a generated query is slow and the EXPLAIN output means nothing to you. Keeping SQL warm with small reps is cheap compared to relearning it mid-incident.

Regex

Honestly, this is the most defensible skill to outsource, and that is exactly why it sits this low even though production is almost entirely gone. Producing regex from memory was always low-return for most engineers, and letting a tool draft the pattern is a reasonable trade. The skill you still need is reading, and reading gets steady incidental exercise because patterns keep turning up in diffs and configs whether you write them or not. The risk is letting the reading go too. An unescaped dot matches any character rather than the literal period you meant, and a greedy quantifier eats past the delimiter you assumed would stop it. If you can no longer parse ^(\d{4})-(\d{2})-(\d{2}) at a glance, you are approving patterns on vibes.

Algorithmic reasoning under time pressure

The everyday kind, the sort you use in review rather than in interviews. Will this nested loop matter at 50,000 users? Should these repeated .find calls be a Map? The rep that vanished is sketching the approach before any code exists; in the AI workflow the code arrives first, looks reasonable, and you rationalize it, which runs the process backwards. I put this last because it leans least on exact recall and gets the most incidental exercise. Every diff is a chance to ask whether the loop matters, so the recognition side stays warm even while the sketching side cools. Whether that is enough to preserve the skill is precisely what the missing study would tell us, and the stakes of guessing wrong are real, since a quietly quadratic implementation looks almost identical to a linear one when both read cleanly.

A ten-minute self test

Set a timer, close every AI surface, and turn autocomplete off, or use a plain textarea. The four items cover syntax recall, SQL, regex reading, and cold reading with a complexity judgment; each carries a pass condition, so score every item pass or fail. Debugging is handled separately below, because it does not compress honestly into a timed drill.

1. Two minutes, JavaScript. From an empty file, write a function that groups an array of objects by a key into a Map<string, T[]>. No docs. Pass: it would run correctly as written, allowing at most a typo-level fix. This is roughly the shape of a daily rep on the JavaScript and TypeScript track.
2. Three minutes, SQL. Given users(id, email) and orders(id, user_id, total, created_at), write the query that returns each user's email and total spend over the last 30 days, including users who spent nothing. Pass: a left join from users, the date condition placed where it does not drop the zero-spend users, and their totals coming back as 0 rather than NULL.
3. Two minutes, regex reading. Without running anything: what does ^(\d{4})-(\d{2})-(\d{2})T match, and which substrings does \d+\. match in 3.14.15 with the global flag? Pass: the first matches an ISO-style timestamp prefix such as 2026-07-27T at the start of the string, capturing year, month, and day, and the second matches 3. and 14., with the trailing 15 failing because no dot follows it.
4. Three minutes, reading plus complexity. Read this cold:

function dedupe(items) {
  const out = [];
  for (const item of items) {
    if (!out.some((existing) => existing.id === item.id)) {
      out.push(item);
    }
  }
  return out;
}

What does it return, and how does it behave at 50,000 items? Pass: it keeps the first occurrence of each id in original order, and the some inside the loop makes it quadratic, so at 50,000 items it does on the order of a billion comparisons; a Set of seen ids makes it linear.

Four passes means your cold production is in reasonable shape and the reps you get from real work are probably enough for now. Three points at one specific skill to patch. Two or fewer is a signal worth acting on, with one caveat about what it proves. The test has no baseline, so it measures your current state, not a decline; you supply the baseline from your own history. If you know you used to write that left join without hesitation and today you could not, that gap is what this article is describing. If you are not sure, keep your answers and rerun the test in a month; two data points beat one. Either way, a weak result says nothing about your judgment or design sense.

Debugging gets tested on your next real bug instead. Pulling and verifying a representative trace can eat more than three minutes on its own, and the frame at the top of the trace is often not the root cause, so a timed version would mostly measure log access and reward premature anchoring. The honest version is to write down, before pasting the trace anywhere, one hypothesis about the cause and the cheapest experiment that would falsify it, then compare notes with whatever the model proposes. If you cannot form a hypothesis at all, that is your result.

What rebuilds recall

The same research that explains the decay names the fix, retrieval practice. In practice that means short, spaced attempts to produce answers from memory, with feedback, rather than more passive review.

There are two honest ways to get it. The stronger one is building something real with assistance switched off, a side project or a gnarly bug you refuse to paste anywhere, because it exercises everything at once, including the skills no drill can touch. If you cannot carve out that time, the cheaper option is small daily reps in the stacks you care about, spaced so the questions you miss come back sooner. That is the whole design of Unrot: five minutes a day of producing answers from memory in the stacks you pick. Five minutes of drills will not replace shipping real work, and we would rather say that plainly than oversell it; the pitch is that daily reps keep the retrieval paths warm enough that the next blank buffer is not a shock.

Whether assistants make you a worse engineer overall is a bigger and more contested question than this piece tries to settle. The claim here is narrower, and by its own framing still a hypothesis: a review-heavy workflow gives these six skills far fewer maintaining reps than they used to get, and if the recall data transfers to code, the production-heavy ones fade first. Ten minutes with a timer tells you more about your own case than any general argument can.