How to get better at reading code: a practice routine
6m read time

How to get better at reading code: a practice routine

Everyone diagnoses AI skill atrophy. Nobody trains the fix. Reading code is a muscle you can drill: a concrete practice routine with a merged PR a day, predict-before-you-run, and explaining code back without the AI.

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. The rest of the week, let the agent do the searching while the hypothesis stays yours.

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. Reading is one of the four skills I would build first starting out today, and it is the one with the cheapest daily reps. 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.

(27 of 31)
01You don't have an AI problem. You have a process problem.02Why you should never ship code you don't understand03Stop copy-paste engineering04The lava layer: why AI code is slowly petrifying your codebase05The prompt is not the spec06The brilliant parrot problem: what AI actually does when it 'thinks'07The bureaucracy of bots: why we are checking the checker08The arms race for your trust: Mythos, Cyber and the security hype09Stop letting your agents write Markdown10You can't spot the bug if you didn't write the code11One in four: the security debt nobody's counting12Your 10x developer is gated by a 0.1x pipeline13Caveman vs context-mode: small mouth, or smaller room?14Code churn is the lava you can still measure15The ceiling is made of concrete16The token-saver tax: walking back my Caveman advice17Even the malware is AI slop now18ThePrimeagen was right19Tokenmaxxing is what happens when you measure the wrong thing20They just asked the bot nicely: your support agent is the attack surface21Speed got cheap. Judgement didn't.22The Ferrari has a limiter: a day with Claude Fable 523The off-switch was never yours24An open MCP server is worse than an open database25The off-switch works both ways now26AI writes the tests. Mutation testing checks if they work.27How to get better at reading code: a practice routine28Learning to program in the age of AI: what I would learn first29Who is responsible for AI-generated code? You are, and 2026 wrote it down30When not to use AI for coding: the tasks I still do by hand31Hiring junior developers in 2026: the collapse is a hiring decision