Keeping Your Skills

The skills you stop using fade, and an agent can take over exactly the ones that make you able to supervise it: reading code closely, debugging, holding a model of the system in your head. Every habit in this book depends on judging what the agent wrote, and judging code requires being able to write it.

None of this is nostalgia for typing. An engineer who can no longer write the code cannot stay its author for long. This page looks at what the first careful study found, which skills go first, and the small, scheduled practice that keeps them without giving up the tool.

The Supervision Paradox

Look at what the earlier chapters asked of you. Reading the diff in Chapter 6. Recognising a call to a function that does not exist in Chapter 7. Knowing which edge case the agent missed in Chapter 8. Refusing a fix that hides the symptom instead of removing the cause. Every one of those uses the knowledge you would need to write the code yourself.

Delegate all of the writing and, slowly, you lose the ability to check it. The better the agent gets, the worse this becomes: its mistakes grow rarer, so you exercise the checking skill less often, and the rare mistake arrives when the skill is weakest. The reviewer who would catch the mistake is the one the tool has been quietly replacing.

The Evidence So Far

A randomised study published in January 2026 put numbers on part of this. Fifty-two software engineers, most of them early in their careers, learned an asynchronous programming library none of them had used before. Half could use an AI assistant while working through the exercises and half coded by hand. Afterwards everyone took a quiz on the concepts they had just used.

The assisted group finished about two minutes faster, a difference too small to be statistically significant. It scored an average of about 50% on the quiz, against about 67% for the group that coded by hand. The largest gap was on debugging questions: finding what was wrong in code that used the library.

How they used the assistant mattered more than whether they used it. Participants who delegated the code to it, leaned on it more and more, or let it debug for them averaged under 40%. Participants who asked it conceptual questions, asked for explanations alongside generated code, or generated code and then worked to understand it averaged 65% or more, close to the hand-coders. The authors are careful that these usage patterns show associations, not causes, and it is one study of 52 people. It is also the best evidence available, and it points in a clear direction.

What Fades

Some skills go first because they are the ones the agent does most completely. Tracing code by hand, line by line, keeping the state in your head. Reading an error message all the way to its cause instead of pasting it into the session. Recalling the everyday functions of the language and libraries you use. Debugging without a candidate fix sitting there to accept. Estimating how long a change should take, which depends on having done changes like it.

Kai is the case. After his months of vibe coding, he can describe the waitlist's behaviour fluently: who gets the offer, how long it is held, what happens on expiry. He cannot trace it. Asked to step through what happens when a cancellation and the 30-second sweep try to offer the same freed place in the same second, he reaches for the agent. That is the third week of Chapter 2 seen from the inside: the code nobody could change was code its author could no longer read.

Deliberate Practice

Nobody has to stop using the tool. What keeps the skills is doing, on purpose, the parts that build judgement. Write the failing test yourself before the agent writes the code, as Chapter 8 recommends; specifying behaviour is the skill supervision runs on. Spend the first ten minutes of a bug alone, reading the evidence, before you hand it to the agent. Write by hand the core of your domain and anything you are learning, the decision Chapter 5 made for a single change.

Two more habits cost almost nothing. Before you open a diff, predict what it should contain, then compare: every surprise is either the agent's mistake or a gap in your model of the code, and both are worth knowing. And once a sprint, finish a whole task without the agent. Practice that is scheduled happens; practice that is intended does not.

Kai started with the ten-minute rule, because it was the cheapest. In the first week he found he could not get far in ten minutes without the agent. By the third week he was finding the cause of about half his bugs before he handed anything over, and the evidence he did hand over was sharper, which made the agent's answers better too. The skill came back faster than it had faded, which is the reason to start now rather than after an incident shows the gap.

The Agent as Tutor

The January 2026 result points at a mode of use that does not cost you the skill. Ask for explanations rather than code. Ask the agent to quiz you on a module before you change it: "ask me five questions about how offers expire in this file, then check my answers against the code". Write your own version first and ask it to review yours, instead of asking it to write its own.

The same tool is a crutch or a coach depending on which of these you ask for. No setting decides which one you get. Who does the thinking decides it: if the agent does it, you get the code; if you do it and the agent checks, you get the code and keep the skill.

A Team Habit

Individual resolve fades faster than skills do, so Cragmoor made it a team habit. Ines keeps one agent-free task per engineer per sprint, chosen from the ordinary backlog rather than invented as an exercise. The newest engineer on the team writes the first version of each feature's tests, so the person with the most to learn does the specifying. And in review, the author explains the change back in their own words, without reading out the agent's description, which is the question Ines asked Kai in Chapter 13.

None of this slowed the team measurably in the month it counted. All of it keeps a team that can still check its tools, which is the only kind of team that can safely use them.