How do you stay technically sharp when AI writes most of your code?

Stay sharp when AI writes your code: an honest method

You stay sharp by deliberately re-doing some of what your AI did. Two hours a week of unaided code review with spaced repetition on the parts you cannot explain yourself is enough. The risk is not laziness; it is that you confuse fluent reading with the ability to author from scratch.

About a year into running agents on most of my code, I noticed a small alarm in the back of my head. A junior engineer asked me to explain why we were using a particular caching pattern in one of my own repos and I had to think about it for an embarrassingly long time. I had not written that code; Claude had. I had reviewed it, accepted it, and shipped it. I could read it. But I could not have written it from scratch. That gap — between reading fluency and authoring fluency — is the thing nobody warned me about when I started leaning on coding agents, and it is the gap that the Hacker News post on the open-source spaced-repetition tool Fata caught my attention this month because of. The founder's confession in the launch — I am seeing a lot of my technical skills decreasing due to AI coding — is exactly what I had felt.

The first instinct is to assume the problem is laziness or screen time. It is not. The problem is structural. Reading code triggers a different cognitive process than producing code. You can read a paragraph of fluent French and feel like you understand it without being able to write the equivalent paragraph yourself. The same illusion happens with code, and AI agents accelerate it because they remove all the small productive frictions — the syntax you would have looked up, the pattern you would have searched for, the bug you would have spent twenty minutes debugging. Those frictions are not the cost of work; they are the work. Cal Newport in Deep Work calls this the difference between consuming knowledge and producing it. When you let an agent produce, you are not training the muscle. You are watching someone else lift weights.

What I do now is two practices, and Fata is a sharpened version of the second one. The first is a Friday afternoon block I call slow review. I take one piece of code an agent wrote that week — usually the most important commit — and I rewrite it by hand without the agent's help. Not from scratch, not pretending the agent did not exist. I open my own file, I think about how I would have approached it, I draft the solution, and then I compare. Sometimes my version is better. More often the agent's is, and the comparison teaches me why. The point is not productivity; the point is the production muscle. Two hours a week is enough to keep it warm.

The second practice is spaced repetition on the concepts I had to look up. This is where a tool like Fata, or just plain Anki, earns its place. Whenever I review agent code and find myself thinking I am not sure why that works, that moment becomes a flashcard. The next time I see the same pattern, I either know it cold or I add it back to the queue. Anki has been the obvious tool for this since 2007; Fata's bet is that spaced repetition for the specific failure mode of AI-coding skill rot deserves a focused tool with the right prompts and the right deck primitives. Whether Fata wins the category or not, the underlying practice is correct: skill that is not rehearsed degrades, and the rehearsal has to be deliberate because nothing in the agent loop will force it on you.

There is a deeper layer here, which is the one Kenneth Stanley writes about in Why Greatness Cannot Be Planned. Stanley argues that the path to expertise is built out of stepping stones — small, often unprofitable explorations that do not pay off in the moment but compound into capability you cannot otherwise reach. Letting an agent do all your coding optimises the wrong objective. You shorten the path to the working feature and you destroy the path to mastery. The way to recover the second path without giving up the first is to insist that some part of every week is stepping-stone work — code you write yourself, problems you solve unaided, concepts you actively practise — even though the agent could do it faster.

The argument I make to other founders who feel the same alarm is that this is not about staying technical for the sake of it. It is about staying able to lead. The senior engineer Andrej Karpathy keeps making the point that the people who get the most out of AI tools are the people who could have done the work themselves and chose not to. You cannot direct a coding agent on a hard problem if you do not know what good looks like for that problem. And you stop knowing what good looks like the moment you stop producing yourself. So the real prescription is small and unglamorous: two hours a week of unaided code, a flashcard for every concept you could not have explained without the agent in the room, and a willingness to be slower on Friday afternoon in service of being faster — and more in control — for the next decade.