There's been a lot written about reading code lately. The 404 Media headline about brains rotting. The Anthropic study where the AI group scored 17% lower on comprehension. My own post arguing that AI is quietly making you a worse reader of code.
Diagnosis everywhere. Training nowhere.
Every one of those pieces ends the same way: reading is the skill that atrophies, so protect it. Fine. But protect it how? "Read more carefully" is the coding equivalent of telling someone to "just be more confident": nice sentiment, no plan, no reps.
So this is the other half. Not why reading matters. How you actually get better at it.
Reading is a skill, and skills have drills
Start with a number that predates AI by decades. Robert Martin put the ratio of time spent reading code versus writing it at about ten to one. Ten. Every hour you spend writing, you spend ten reading: your own code from last month, a colleague's PR, the library you're debugging, the stack trace at 3am.
And how much of your training went into reading? Almost none. University taught you to write. Bootcamps taught you to write. Every tutorial you have ever followed handed you a blank file and told you to fill it. The single most-used skill in the job is the one nobody ever coached.
Felienne Hermans wrote a whole book about this, The Programmer's Brain. Her core point: reading code is a cognitive skill built on chunking, the same mechanism that lets a chess player glance at a board and see positions instead of pieces. An expert doesn't read for (int i = 0; i < n; i++) character by character. They see "loop over the array" in one glance, because they've seen that shape ten thousand times. Beginners read it letter by letter and run out of working memory before they reach the body.
Chunking is trainable. That's the whole premise of her code reading clubs: groups that get together and read code, on purpose, as a workout. Not to ship anything. To get better at seeing structure.
Which means reading is a muscle, not a talent you either have or don't. And a muscle you can build, you can also let waste away.
AI moved the ratio, then took your reps
Here's what changed. That ten-to-one ratio was never going down. Now the code you read is generated, so you read even more of it, and it's code you didn't write, which is the hardest kind to read. Meanwhile the writing, the part that built the instinct in the first place, is the exact part you handed off.
More reading. Harder reading. Fewer reps. Every trend line points the wrong way at once.
The brilliant parrot problem is right here: the model writes code that looks right. Plausible variable names, sensible structure, the shape of correct code. Spotting the difference between plausible and correct is a reading skill, and it is precisely the skill going soft while the volume of plausible-looking code explodes. You need to read better than ever, at the exact moment you're practising less than ever.
So train it. Deliberately. Here is the gym.
The routine
None of this is exotic. It's boring the way lifting is boring: the value is in doing it repeatedly, not in any single session being clever.
A merged PR a day. Pick one real pull request, yours or a stranger's, and read it before you read the description. Predict what it changed and why from the diff alone. Then read the title, the description, the review comments. The gap between your prediction and the truth is the exact thing you're training. GitHub is an infinite supply of these, free.
Predict before you run. Take a function you don't know. Before you execute it or ask an AI, write down, in one sentence, what it returns for a given input. Then run it. Were you right? This is the single highest-value drill, because it forces you to actually build a model of the code instead of skimming until it feels familiar. Familiar is not understood.
Explain it back with the AI closed. When an agent hands you code and a tidy explanation, close the explanation. Re-derive it yourself, out loud or in a comment, as if you had to teach it to a junior. If you can't, you didn't understand it, you recognised it. That's the ship rule turned into a daily exercise instead of a merge-time gate.
Read code you would never write. Your comfort language keeps you in chunks you already own. Once a week, read something outside your stack: a Rust parser, a game loop, some gnarly Bash. You'll read slowly and badly, which is the point. That's the muscle under load. Hermans' clubs exist precisely to do this together.
Trace one bug by hand. When something breaks, resist the paste reflex. Pick one bug a week and follow it yourself: read the stack trace top to bottom, form a hypothesis, check it, before any AI touches it. The instinct for where bugs hide is built by finding them the slow way.
Five drills. You will not do all five every day, and that's fine. Pick one. Twenty minutes. The point is the frequency, not the volume, the same way one honest set beats an hour of scrolling between machines.
The mandate nobody will give you
Aviation worked this out. Pilots who lean on autopilot lose situational awareness, so the regulator mandates manual flying hours. Nobody is going to mandate manual reading hours for you. There is no regulator. Your employer wants throughput this quarter, and reading practice pays off later: the day production breaks in generated code and you're the only one who can still trace it.
So the mandate has to come from you. Put the twenty minutes in the calendar like you'd put a run there. Protect it the same way, which is to say badly at first, and then it's a habit.
The reason to train harder is not that AI got worse. It's that AI got good. When the machine writes fluent, plausible, mostly-correct code faster than you can read it, the reader in the loop is the only thing standing between "looks right" and "is right." That reader is you. Reading was always the harder skill. Now it's the whole job.
The gym doesn't close because you bought a forklift. It's the reason you still need to be strong enough to catch what it drops.