Keeping your edge when the agent does the typing

Talk to engineers a year into working with agents daily and a quiet worry comes up, usually after the enthusiasm: *I'm not sure I could still do this without it.* Debugging instincts feel a beat slower. The blank file feels blanker. It's not imagined — the skills that make you a good supervisor of AI work are trained by the very reps you're now delegating away. That's the trade at the center of the new workflow, and it's manageable. But only on purpose.

The atrophy loop

Reviewing code well depends on abilities you built by writing code: predicting what a change will do, sensing where the bug probably lives, knowing what a good solution smells like. Delegate all the writing and those abilities don't disappear overnight — they decay on a lag, quietly, while your output stays high. By the time you notice, you're approving work you can no longer independently verify. The supervisor's judgment was funded by the practice the supervisor stopped doing.

Aviation hit this exact problem decades ago. Autopilot made flying safer and pilots' manual skills worse — so the industry's answer wasn't less autopilot. It was mandatory hand-flying: deliberate, scheduled practice of the skills the automation had absorbed. That's the right frame for us. The goal isn't to type more for its own sake. It's to keep the judgment account funded.

What actually needs maintaining

Not everything, thankfully. Some skills are safe to let go — nobody's judgment depends on memorizing standard-library signatures, and losing that is no different from letting the compiler catch your syntax. The skills worth deliberate maintenance are the ones your *oversight* runs on:

• Debugging from first principles — tracing a failure through logs and code yourself, forming a hypothesis before anyone (human or model) hands you one.
• Deep reading — building an accurate mental model of unfamiliar code, because that's the muscle every review depends on.
• Starting from blank — writing the first version of a design or a tricky function yourself, where the struggle is the training signal.
• Decomposition and estimation — knowing what's a day and what's a week, which is how you catch an agent confidently walking into a swamp.

Reps that fit inside a real job

None of this requires abandoning the tools or carving out study evenings you don't have. The practice fits inside the work you're already doing — it's a matter of where you place yourself in the loop.

Predict before you run. Before executing the agent's change or reading its explanation, write one sentence: what you expect the diff to contain, or why you think the test is failing. Ten seconds. Being wrong is the valuable part — it shows you exactly where your model of the system has gone soft, while it's still cheap to fix.

Keep one hard thing hand-made. Once a week, pick a task you'd normally delegate — a gnarly bug, a small design, a function with real edge cases — and do it yourself, tools closed, timer on. Like hand-flying, the point isn't efficiency. The point is that the skill is still there when the automation isn't.

Take the first twenty minutes of every debugging session yourself. Form your own hypothesis before you hand the stack trace to the agent. If the agent then finds something you missed, don't just apply the fix — study the gap between your guess and the answer. That gap is your curriculum.

Make the agent a sparring partner

The same tool that causes the atrophy is a strangely good gym. After it explains something, explain it back and ask it to poke holes in your version — the explain-back is where the learning actually happens. Ask it to quiz you on the module you just merged. Have it generate a bug and see if you can find it. Treat its diffs as reading practice with a patient author who never tires of "why did you do it this way?"

The difference between using an agent as a crutch and using it as a coach is entirely in who does the thinking first. Same tool, same session — opposite effect on your skills.

This isn't nostalgia

To be clear: the answer to skill atrophy is not returning to artisanal hand-typed code. The leverage is real, and the engineers who refuse it will be outrun by the ones who don't. But the market is quietly repricing what it can't automate — and what it can't automate is exactly the judgment that delegation erodes by default. Interviews are already shifting from "can you build it" to "can you debug it, review it, and stand behind it."

So treat your core skills the way you'd treat any depreciating asset you depend on: maintain them on a schedule, not when they fail. A prediction before each run, one hand-made hard thing a week, the first twenty minutes of every debug. Small, boring, deliberate — and the difference, a year from now, between an engineer who directs the work and one who can only watch it happen.