The Skill Agents Erode Fastest: Reading Unfamiliar Code

Of everything coding agents change about how engineers work, one shift gets discussed least and matters most: fewer people are building the mental model that comes from reading unfamiliar code slowly.

Not writing code — writing was always the smaller part. Reading. The activity where you open a subsystem you've never seen, follow a call path until you understand why it's shaped that way, and come out with a model you can reason about later. That activity is where an agent is most obviously more efficient than a person, and efficiency is exactly what makes it easy to skip.

Why it matters more than it sounds

Debugging a system you don't have a model of is qualitatively different from debugging one you do. Without a model, you're pattern-matching symptoms to fixes — which is precisely what an agent does, and it's fine right up until the bug isn't like anything in the pattern space. Then someone has to reason from how the system actually works, and that reasoning has no shortcut.

The same model determines whether you can tell a good change from a plausible one. Reviewing agent-written code is now a large share of the job, and review quality is bounded by your model of the surrounding system. A reviewer without one can check whether the code looks reasonable — not whether it's right in this codebase, with these invariants, given the assumption made three modules over.

⚠️ The compounding version: an engineer who has only ever read code through summaries reviews agent output using an agent, producing a loop where nobody involved has examined the thing directly.

What's actually being lost

Reading code slowly produces things a summary doesn't:

• Where the bodies are buried. The comment explaining a workaround, the function everyone routes around, the module whose tests are all skipped. This is load-bearing knowledge and it doesn't survive summarization, because a summarizer can't tell it's load-bearing.
• A sense of the codebase's grain — how this team names things, which patterns are idiomatic here, what's legacy. It's how you write code that fits rather than code that merely works, and it's absorbed rather than stated.
• Calibrated suspicion. Experienced engineers get uneasy at certain shapes before they can articulate why. That's compressed experience from having seen the shape go wrong, and there's no way to acquire it secondhand.

What I'd actually do about it

Not "read everything manually" — that gives up the productivity, and nobody sustains it.

Distinguish the two modes and pick deliberately. Traversal — "where is X handled?" — is a lookup, and delegating it is pure gain. Comprehension — "why is this designed this way?" — is where the model gets built, and delegating it means not having the model. Most people don't notice they're making a choice, which is how the second one gets skipped by default.

Read the diff, not the summary, on anything you own. For code you'll maintain, read what actually changed before merging. The agent's explanation is a hypothesis about its own work; it's usually right, and "usually" is doing real work in that sentence.

Keep one system you know cold. For anything you're responsible for, invest in a genuine model — read it end to end once, follow the awkward paths, understand the historical decisions. Depth in one system transfers as pattern recognition everywhere else; breadth without depth doesn't transfer at all.

Use the agent to accelerate reading, not replace it. "Walk me through this call path and show me each function as we go" builds a model. "Summarize what this service does" substitutes for one. Same tool, opposite outcomes, and the difference is entirely in what you ask for.

For people leading teams

This is where the effect is structural rather than personal. Someone who joined the field with these tools has had fewer opportunities to build models the slow way — not through any failing of theirs, but because the fast path was always available and usually correct.

The concrete responses are unglamorous: pair on comprehension tasks rather than only on delivery; ask "why is it built this way?" in review, not just "does this work?"; treat a written architecture explanation as a legitimate deliverable. And notice which engineers can debug without the tools, because that's the capability you'll need on the day something breaks in a way no pattern covers.

The takeaway

The productivity gain is real and I wouldn't give it back. But reading code slowly was never only about the code — it was how engineers acquired the models that make judgment possible. Delegate traversal freely; guard comprehension. The distinction takes seconds to make and determines which of the two things you end the year with: more shipped, or more understood.