Skip to main content
  1. Posts/

The reps you skip are the intuition you don't build

·1104 words·6 mins·
Table of Contents

There’s a line in my training notes that I keep having to apply at work: in-session performance is not learning. The drill that feels smoothest tonight is often the one teaching you least, and you don’t find out which was which until next week, when you see what’s still there.

I train Shaolin kung fu twice a week, and that line is the most useful thing I’ve picked up from it. It’s also, I think, the sharpest available description of what AI is doing to how engineers build judgment.

What the smoothness is actually telling you
#

Motor-learning research has spent decades on the gap between performing well during practice and having actually learned something. They come apart more than you’d expect. Practice conditions that make you look good in the moment — blocked repetition, heavy guidance, immediate correction — frequently produce worse retention than conditions that make you look worse. Robert Bjork’s term for the useful kind of friction is desirable difficulties, and the name is doing a lot of work: the difficulty isn’t a cost you pay for the learning, it’s the mechanism.

That’s an uncomfortable idea to sit with, because it means the feeling of a session going well is not evidence that it went well. It might be the opposite.

Now think about what an AI-assisted session feels like. Smooth. The structure appears before you’ve finished deciding on it. The function you half-remember gets written correctly. The error you’d have spent forty minutes on resolves in two. Every friction point that used to be where the learning happened is precisely what the tool is optimized to remove.

I’m not building to “so struggle more.” That’s the cheap version of this argument and it’s wrong. But the tool is optimizing for exactly the variable the research tells you is the misleading one, and it would be strange if that had no effect at all.

Reps build something that isn’t knowledge
#

Here’s the part that’s easy to get wrong. The thing you lose isn’t facts. You can look those up, and could before.

What reps build is a felt sense of where the risk lives. I’ve written about reviewing a diff you didn’t watch grow, and the core of that problem is exactly this: when you review code you co-authored, you carry a map of which part felt shaky, which shortcut you took at 4pm. That map is the review. It came from having done the work, and there’s no way to acquire it by reading the result.

The same thing shows up one level out. When I looked at what got better and worse on my team after we started building with AI, production debugging was the capability that didn’t move. It’s the skill that depends most on having built the thing yourself, and it’s the one the tooling helps least with. That isn’t a coincidence. It’s the same mechanism, showing up in an on-call rotation.

Repetition without repetition
#

There’s a second half to this that the “just do it the hard way” framing misses completely.

The Soviet physiologist Nikolai Bernstein watched blacksmiths strike the same spot thousands of times and found they never repeated the same movement to do it. Every strike was a slightly different solution to the same problem. He called it repetition without repetition, and it reframes what a rep is for. The value was never in grinding an identical motion. It was in solving the same problem under conditions that keep shifting, which is what builds something flexible enough to survive a situation you haven’t seen.

Applied honestly, that cuts against doing everything manually. Typing out boilerplate you’ve typed a hundred times is repetition with repetition. It’s the low-value kind, and handing it to a model costs you nothing. The reps worth protecting are the ones where the problem is genuinely new to you, where you don’t yet know the shape of the answer, and where getting it wrong would teach you something specific.

So which reps do you keep?
#

This is where I’d rather give you a criterion than a list, because the list is personal and mine wouldn’t fit you.

The question I’ve landed on: would I be able to debug this at 2am without the thing that just built it? If the answer is no, and the code matters, that’s a rep worth doing the slow way. Not all of it. The part I don’t understand yet.

For anything I did hand over, the discipline is the one I already try to hold on agent diffs: read it as though a stranger wrote it and I’m the last line of defense, because on that diff, I am. That’s a weaker substitute for having built it. It’s not nothing, and it’s what’s available.

The harder version of this question isn’t about me. It’s about the engineers who are three years in. I built my intuition on a decade of doing things inefficiently, and I can’t honestly recommend that path to someone who has a tool that makes it optional. What I can say is that the intuition came from somewhere, it wasn’t free, and nobody has yet shown me the version of the job where it stops mattering. If you’re early and you let the model take every hard rep, you’re making a trade whose cost lands years later, on a night when the thing is broken and nobody can tell you why.

What the kung fu makes obvious
#

The reason I keep reaching for the training analogy is that a body makes this legible in a way a codebase never does.

You cannot outsource a rep in a physical skill. There’s no model that opens your hips, and no amount of understanding the mechanics produces the capability. The gap between knowing and being able to is visible every week, which means you can’t lie to yourself about it for long.

In engineering, the same gap exists and is nearly invisible. You can read about a system all year and feel like you understand it, and be wrong in a way nothing tests until production tests it. AI widens that gap and simultaneously makes it more comfortable to sit in, because the output is right often enough that the absence of understanding rarely surfaces.

Not every rep is worth doing yourself. That’s the honest version and it’s what makes this a real decision rather than a reflex. But it is a decision now, and it didn’t used to be. The struggle used to be included by default. Now it’s opt-in, and nobody is going to prompt you to take it.

Chandler Thompson
Author
Chandler Thompson
I lead engineering teams and coach the people who run them. This is where I write down what actually worked.

Related