How to keep your fundamentals sharp when AI writes most of your code

AI can remove a lot of useful friction. It can draft a test fixture, fill in a mapper, suggest a regex, or produce the first version of a migration before you have opened a second tab.

That is useful. It also changes where your practice comes from.

When you used to write a small parser by hand, you had to remember how to walk a string, handle boundaries, and decide what a bad input should do. When an assistant writes the first version, you may still review it well enough to ship it. A few weeks later, though, you might struggle to recreate the approach without the chat window.

Keep using AI, but make room for the small acts of recall that work used to force on you.

The skills that tend to decay first when AI writes your code are usually the ones hidden inside routine implementation work: tracing control flow, reading an error, choosing a data structure, or explaining why a query returns duplicate rows.

Rereading feels productive because it is easy

Most developers respond to rust by opening documentation, scanning old notes, or reading a familiar tutorial again. It feels responsible. You see code you recognize, so it seems like the knowledge is still there.

Recognition is weaker than recall.

You can look at a React effect, a SQL join, or a Go interface and feel certain you understand it. Close the page and ask yourself to write a small example from memory, then explain the edge case that matters. The gap between those two experiences is the part worth paying attention to.

Research on retrieval practice has repeatedly found that trying to recall information supports later retention better than simply studying it again, even when restudying initially feels more fluent. In one well known experiment, students who practiced retrieval remembered more after a delay than students who spent the same time rereading material. Roediger and Karpicke, 2006

For programming, that doesnt mean memorizing API signatures for their own sake. It means creating situations where you must produce an idea before seeing the answer. Documentation remains useful when you are solving a real problem. It is poor as your only maintenance plan for knowledge you want available under pressure.

A rep is a small problem with the answer hidden

A programming rep should be short enough to start between meetings and narrow enough that you can tell if you got it right.

“Review JavaScript promises” is not a rep. It is a vague intention, followed by browsing.

“Without running it, what does this promise chain log, and why?” is a rep.

“Write a SQL query that returns every customer, including customers with no orders this month” is a rep.

“Given this Python function and input, find the first line that raises and explain why” is a rep.

A good rep asks for one concrete output. You write code, predict output, trace state, choose between two approaches, identify a bug, or explain a tradeoff in your own words. Then you check the answer immediately.

The check matters. Guessing without feedback can leave a wrong model in place. Looking at the answer before attempting the problem skips the recall part. The useful sequence is attempt, compare, explain the mismatch, move on.

Here are a few rep formats that work well for experienced developers:

• Read ten lines of unfamiliar code and state what value reaches the return statement.
• Rebuild a small function from memory, then compare it with a reference implementation.
• Look at a failing test and name the most likely bug before seeing the production code.
• Explain why a cache key is unsafe, why a transaction boundary matters, or why a type narrowing fails.
• Take an AI generated snippet and identify one assumption you would test before merging it.

The last one is especially relevant now. AI review can become a passive activity too. A better habit is to pause before accepting the suggestion and make a prediction: what will this do with an empty array, a null value, concurrent requests, or a Unicode string?

Space the reps instead of cramming them

Increase the interval when you can answer a concept cleanly without much effort. A tricky closure question today might return in four days with different names and a different surface problem. A database indexing question could return next week as an investigation of a slow query plan. The delay makes recall harder, which is the point.

Vary the problem when you want to check if the idea transfers. Repeating the same closure question can show that you remember its answer. A closure hidden inside an event handler or loop checks if you can recognize the same behavior in a different situation.

A large review of spacing research found that the best gap depends on how long you want to retain something, but distributed practice generally improves retention compared with packing the same study into one session. Cepeda et al., 2006

You dont need a complicated spreadsheet to use this. Keep a short list of concepts that gave you trouble. Revisit one after a few days, then after a couple of weeks. If you answer cleanly, make the next gap longer. If you hesitate or get it wrong, bring it back sooner.

This is one reason a daily practice tool can be helpful. Unrot's tracks organize short reps around a stack and bring concepts back over time, so you do not have to decide every morning what to practice. But the method works with index cards, a small repository of exercises, or notes from bugs you actually fixed.

Five minutes is enough to maintain a habit

Five minutes is rarely enough to learn a new framework from zero. It is enough for one honest attempt at a focused problem.

A daily practice session should fit in the gap before standup, while a test suite runs, or after you finish a ticket. If your plan requires a quiet hour and a perfect evening, it will lose to work, family, and the plain fact that you are tired.

Try this for a week:

1. Pick one stack you want to keep warm.
2. Set a five minute timer.
3. Do one rep with the answer hidden.
4. Check it and write one sentence about what you missed.
5. Stop when the timer ends.

Do not turn the session into a side project. The goal is frequent contact with the mechanics you want to retain. One rep per day is modest, but it gives you many chances to notice where your mental model has gone fuzzy.

If you are a senior engineer who mostly reviews designs now, choose problems close to the code you no longer write. Trace a retry loop. Explain a race condition. Sketch the SQL behind a report your team depends on. If you changed stacks, alternate your current work language with the old one. A TypeScript developer moving to Kotlin might use one session for current work and another for JavaScript event loop behavior.

Practice should feel a little uncomfortable

Deliberate practice is often reduced to a slogan about huge hour counts. That is not a useful way to plan your week. Ericsson and colleagues described deliberate practice as structured activity aimed at improving a specific part of performance, with feedback and repeated adjustment. Their work did not say that a fixed number of hours guarantees expertise. Ericsson, Krampe, and Tesch Romer, 1993

For a developer, the useful part is the structure.

Choose a skill just beyond automatic. Make an attempt where failure is visible. Get feedback. Repeat later with a small variation.

If every rep is trivial, you are checking a box. If every rep requires twenty minutes of setup or sends you into three docs pages, it is too broad for daily maintenance. Aim for questions that make you pause, then let you reach a clear answer.

You can also use work as the source material. After fixing a production bug, turn the cause into a small question. After reviewing a pull request, save the tricky condition you nearly missed. After an AI assistant suggests code you cannot fully explain, remove the answer and make that explanation tomorrow's rep.

Drilling has limits

Practice reps can keep concepts accessible. They cant replace building software.

A rep about cancellation in async code can tell you if you understand the mechanics. A real service teaches you where cancellation interacts with timeouts, logging, cleanup, retries, and people waiting on a page. A rep about indexes can sharpen your understanding of query access paths. It cannot show you the cost of a bad schema decision after a year of product changes.

Keep both in your routine. Build things, debug real systems, read code written by other people, and review changes with context. Use short drills to make those activities less dependent on a prompt window or a lucky memory.

AI is still part of that workflow. Ask it for an explanation after you make your own prediction. Ask it to generate variations of a bug you just solved. Ask it to review your reasoning, then verify the important parts yourself. Stay capable of judging the help AI gives you.

Start with the part you would hate to forget

Pick one narrow topic this week. Maybe it is SQL joins, TypeScript narrowing, Python iterators, HTTP caching, shell quoting, or the old language you used before your team changed stacks.

Write five prompts that require an answer from memory. Keep them small. Mix prediction, implementation, and explanation. Return to the ones you miss after a few days.

If you want the routine already set up, try a short Unrot practice session. If you would rather keep your own notes, that is fine too. Protect a few minutes where your brain has to retrieve, not merely recognize.