The 2026 Anthropic coding-skill study measured what AI assistance does to skill formation in learners: a ~17-point comprehension-quiz gap (50% vs 67%) favouring the hand-coding cohort. The working-developer commentary that landed alongside it — Addy Osmani's Avoiding Skill Atrophy and VirtusLab's cognitive debt in code piece — points to a more specific erosion. The skill most readily replaced by AI assistance, and the one working developers report losing the fastest, is reading. Writing code with the AI is easy. Reading the code AI produced is the part that quietly atrophies.
This post is the six-rule playbook for keeping the reading skill alive in the AI-coding era. The rules are drawn from the published evidence and from working developers who report holding the skill across an AI-heavy year.
Why reading is the foundation
A point that's almost too obvious to be made carefully. Reading code is the prior cognitive act for everything else in software work. Code review is reading. Debugging is reading. Onboarding to a new codebase is reading. Code archaeology — figuring out why something was done a certain way three years ago — is reading. The writing skill rests on the reading skill in ways that aren't always visible when AI is generating the writing.
The pattern documented in the VirtusLab piece on cognitive debt in code and across the broader 2026 developer-skill commentary is that AI-assisted teams ship code their team can't read. The artefact is fine. The team's collective ability to reason about the artefact has dropped. That's a reading-skill problem, even when it presents as a writing-skill or maintenance-skill problem.
The Anthropic study reinforces this. The comprehension quiz the hand-coding cohort outperformed on rewarded understanding the library well enough to reason about it, not just produce code with it. Understanding is reading.
Rule 1: Read at least one diff a day without AI summarization
The single most important rule. Pull requests, your own PRs from a week ago, open-source projects you follow — read one diff a day, end-to-end, without asking the assistant to summarize it.
The diff is the right unit because it's bounded (you can finish reading one), interesting (someone changed something), and load-bearing (the cognitive act of figuring out what changed and why is exactly the practice surface this rule maintains).
The AI summarization tools are good. They produce useful, mostly-accurate summaries of what a diff does. They also let you skip the reading. If you let them, the reading skill drifts.
Practical version: bookmark one open-source project you find interesting. Subscribe to a colleague's PR feed. Skim your own diff history. The source doesn't matter; the daily rep does.
Rule 2: Read your own old code without the assistant
A specific case worth carving out. Pick a project you wrote six months to two years ago. Open a file. Read it. Reconstruct what it does in your head before consulting the assistant or your own notes.
Why this rule:
- Your own old code is the cleanest test of your reading skill. You wrote it; you have the context; the comprehension gap, if there is one, is a pure measurement of how much your reading skill has changed.
- It surfaces the AI-assisted writing patterns. Code you wrote with substantial AI assistance often reads differently from code you wrote without — the comments are different, the variable names follow different patterns, the structural choices are sometimes AI-default rather than considered. The reading exposes the pattern.
- It builds the code archaeology muscle. The skill of reading your past self's intentions is the same skill you need for reading any unfamiliar codebase.
The Addy Osmani warning-signs essay specifically flags this — can you still read your own old code without help? is one of the cleanest self-tests for skill atrophy.
Rule 3: Mentally walk unfamiliar code before asking the model
When you encounter a piece of unfamiliar code — a library you're new to, a service you've never touched, a stack trace from an area you don't own — spend a few minutes mentally walking it before opening the assistant.
The mental walk is:
- What are the inputs?
- What are the outputs?
- What's the most likely thing this function does?
- What's the second-most-likely thing?
- Where is the part I don't understand?
Then open the assistant — to confirm, to fill in, to clarify. The assistant joins your existing mental model; it doesn't substitute for forming one.
The cognitive act of forming the mental model is what builds the reading skill. The assistant filling in the model after you've formed it is the calibrated use. The assistant forming the model for you is the offloading.
This rule is the direct application of the generation-after-thinking principle from the broader cognitive-debt literature, adapted to code reading. Think first, prompt second.
Rule 4: Read the docs, not just the AI-generated summary
A specific failure mode. The assistant tells you what a library function does; you accept its summary; you move on. The summary is usually right. The cumulative effect of always taking the summary instead of reading the docs is that your relationship to the library never deepens.
Two practical patterns:
- For the first use of a new library function, read the actual docs. The function signature, the parameter types, the edge cases, the examples. Not the AI summary.
- For repeated use of a function you already know, the AI summary is fine. The rule isn't never use AI summaries. It's read the docs once.
Working developers who hold the skill across an AI-heavy year mostly report some version of this rule. The first encounter with a piece of unfamiliar material goes through the actual material. Repeat encounters can go through the AI summary.
Rule 5: Pair-review with a colleague at least weekly
The social dimension of the reading skill. Once a week, sit with a colleague and walk through a piece of code together — not for a formal code review, but as a reading rep. One person reads the code aloud; the other notes what they see; the conversation surfaces patterns neither would have caught alone.
Why this rule:
- Two readers catch what one reader doesn't. The pair-reading is denser than the solo reading.
- The reading aloud surfaces structure. Code, like prose, reveals its rhythm and structure when read aloud. AI-generated code often has rhythm patterns that solo silent reading skips over.
- The conversation is the artefact. The discussion you have about the code is the cognitive engagement that maintains the reading skill. The assistant's summary doesn't produce that conversation.
The VirtusLab piece on cognitive debt in code makes a related point: teams that ship AI-assisted code without regular pair-review accumulate code nobody on the team can reason about. The pair-review is the structural defence against that.
Rule 6: Keep a daily unaided reading rep on the calendar
The last rule is the one Senwitt is specifically built for. The five rules above describe what to do; the sixth is the structural support that makes the rules survivable.
A daily unaided reading rep, short and bounded, in a context that doesn't include the assistant. Seven minutes a day of mixed cognitive reps — including a Reading rep and a Code rep — keeps the practice surface alive that the rest of the workday's AI-assisted reading is putting through strain.
The Senwitt Daily Set is the artefact. The Code Skill reps run most days. The Reading reps run alongside. The point isn't to substitute for your actual code-reading; it's the warm-up that keeps the reading muscle warm for your actual work.
Why this rule sits at the end: the first five rules are easy to skip on a hard day. The sixth — the seven-minute Set — is hard to skip because the bound is so small. The bounded rep is the load-bearing structural defence against drift.
What this playbook does not do
Three hedges.
It does not say stop using AI for coding. None of the six rules is anti-AI. The assistant remains in the workflow throughout. The rules are about how the assistant is used, not whether.
It does not promise skill immortality. Skills change with the work you do, the codebases you live in, and the tools available. The playbook protects the daily reps that keep the skill trainable. It doesn't lock it in.
It does not work as a one-off. Each rule is cheap and the cumulative effect comes from doing them consistently. The Anthropic finding is about daily practice patterns; the six rules reflect that.
A four-week install plan
If you're starting from a workflow where most reading is AI-summarized, the staged install across four weeks.
Week 1. Install Rule 1 only — one diff a day without AI summarization. One rule. Establish the floor.
Week 2. Add Rule 3 — mental walk before prompting on unfamiliar code. Two rules now, both about the order of operations.
Week 3. Add Rule 4 — read docs for first-use of new functions. Three rules, all about the daily reading practice.
Week 4. Add Rules 2, 5, and 6 — old-code reading, weekly pair-review, daily Set on the calendar. Four weeks in, all six rules running.
The staged install works because each rule has time to stabilize before the next one is added. Trying to install all six at once has a higher failure rate.
