Rhys Brett-Bowen Coding in the age of AI

Augmented Reading

updated

Confidence cited cognition research; applying it to AI-assisted reading is a reasoned bet, not measured

“In the case of good books, the point is not to see how many of them you can get through, but how many can get through to you.” — Mortimer Adler, How to Read a Book

A dense page of text and code passes through a narrow clay lens that spaces and orders it, rather than being compressed into a smaller block.

The reflex, when a model meets something long, is to make it shorter. Summarise the PR, TL;DR the paper, have the agent review the diff and hand back the findings. It all points one way: read less.

I reach for a model on a heavy read for the opposite reason — not to skip the reading, to survive it. A dense diff, a spec outside my domain, a paper I actually have to understand: the model’s job is to serve it to me in a shape I can get through, so I read more of it and read it properly. It doesn’t render the verdict. It makes the reading tractable.

So a model can replace your reading or it can amplify it. Replace is the default the tools are built around. Amplify is the one worth having.

Bottom line up front

  • Amplify, don’t replace. Use the model to read more, not less. A summary you read instead of the source is replace-mode — and now you’re trusting the compression, which is the one thing you sat down to check.
  • Serve the reading the artifact wants. Prose has an order the author chose; pace along it. Code doesn’t — it’s navigated, and a linear feed strips the locality that carries meaning. Don’t impose an order the artifact doesn’t have.
  • Verify every gloss against the raw. A summary, a tag, an analogy — each is a claim to check, not a fact to accept. Drill until it grounds out in something you can see. The friendlier the rendering, the further it is from the source.
  • Place each agent where its weakness costs least. The machine doesn’t fatigue the way you do; put it on the widest surface. You do; arrive at what’s left fresh.
  • The scaffold is reader-contingent. Its value scales inversely with your fluency on this material. Redundant on the familiar; worth it on the unfamiliar and the huge. Build the model first, then sweep.

Amplify, don’t replace

The failure isn’t summarising. It’s reading the summary instead of the thing. Do that and the model’s compression is load-bearing — you’re trusting exactly what you came to verify, and a summary can say one thing while the source says another. Replace-mode hands you fluency and keeps the understanding.

Amplify keeps the source under your eyes and spends the model on everything around it: the order to take it in, where to look next, how to render a gnarly part so it lands. You still read every load-bearing piece. The model makes that survivable — which, on a long enough artifact, is the difference between reading it and pretending to.

I’ve done the small version of this plenty: had a model take me through a change one decision at a time, so I’m weighing one thing with its context in front of me instead of the whole wall at once. Slower on purpose — that’s how it goes in.

Serve the reading the artifact wants

What the model should do depends on what you’re reading, and the split is prose versus code.

Prose has an order. An RFC, a paper, a design doc — the author chose the sequence and edited it to flow. There the model can walk you along that line: a piece at a time, confirm you’ve got it, drill where you’re lost. Chunk-and-serve fits, because the line already exists.

Code has none. It doesn’t care what order you put functions in or which file they land in, and expert reviewers read it that way — jumping to the definition, the call sites, the neighbours, not top to bottom. Eye-tracking backs this: programmers read code far less linearly than prose, and experts less linearly than novices (Busjahn et al., 2015), building comprehension by navigating rather than by sequence (von Mayrhauser & Vans, 1995). So a linear feed is the wrong interface for code. Chunk it into a queue and you throw away the locality — where a function sits, what’s beside it, what else moved in the same commit even when it’s unrelated. That’s signal about what the author was doing, and you can’t get it back by asking for the next chunk. For code the model’s job flips from serve the chunks to answer the navigation: where is this used, what calls it, show me the thing in place so I go read where it lives.

Re-representation is the same move one step up: the model renders the raw into the shape that lands for you — an analogy, a table, a walk-through in your own domain. Analogy works by mapping a new structure onto one you already hold (Gentner). It’s also the gloss furthest from the source, so it earns the least trust: transform to understand, then check the understanding against the raw. The analogy is a ladder you kick away once you’re up, not the thing you stand on.

Prose on the left is served in its authored sequence, one section after another. Code on the right is read by jumping among definitions, call sites, and neighbours. The model should pace prose but answer navigation for code.
Pace the sequence prose already has. For code, answer the navigation and keep the source in place.

Build, then sweep

“Programming properly should be regarded as an activity by which the programmers form or achieve a certain kind of insight, a theory, of the matters at hand.” — Peter Naur, Programming as Theory Building (1985)

The served, linear pass does have a place on code — the first one. When the material outruns what you can hold, walking it in dependency order is how you build the mental model. You’ll flag some bugs on the way, but that isn’t the point of the pass; the theory you come out with is — Naur’s word, and the actual product. Then the second pass is the navigated sweep: model in hand, you jump around, check intent, and catch what a tool has no rule for — the gap between what the code does and what it was meant to do. Skip the build on unfamiliar code and the sweep is just scrolling.

Put the tireless one on the widest surface

Reading a long diff, I fade, and the research says everyone does: review defect-detection drops sharply past a few hundred lines and an hour at the desk (Cohen’s study at SmartBear and Cisco). Underneath sits the vigilance decrement — sustained attention on a watch-task decays with time (Mackworth, and seventy-five years since). A diff isn’t a Mackworth clock, but the shape carries: the catch you’d make fresh, you miss tired. Fresh attention is the scarce thing. Don’t spend it on the wide, mechanical surface a tireless machine can pre-filter.

So on a long PR I run the machine pass first, not last. It doesn’t fade with time the way I do — let it eat the widest surface. It has its own decay on volume (recall sags in the middle of a long context), but that’s a different failure mode than fatigue, not the absence of one — so the routing plays two weaknesses against each other rather than betting on a flawless machine. Its comments tell me what it flagged — not everything it examined, just where it had something to say; I scan them, agree or bin each against the code, and that part goes fast. Then the deep read goes where it couldn’t: the code it said nothing about. Not because a flag makes the code around it safe — a flag marks a point, not a neighbourhood, and I’ve caught plenty two lines from something it flagged — but because the unflagged code is where the bugs with no rule live, and that’s what a fresh reader is for. It’s caught things I missed; I’ve caught things it missed. Neither of us owns the verdict.

Which also says when to skip it. Under a few hundred lines I can hold the whole diff in one sitting, so the machine pass is optional — and if the code was written through the same engine already, much of the mechanical bar is met and a second pass is low-yield. That last part is my workflow, not a measurement. Either way it’s the Noticing Is Cheap rule in a new place: route the mechanical to the tireless machine, the intent-bearing to the fresh human. Reading is just where you schedule it.

When the scaffold gets in the way

None of this is free, and it isn’t universal. Guidance that lifts a novice becomes redundant load for an expert, who now reads around the help to reach the thing — the expertise reversal effect (Kalyuga, Sweller and colleagues). Pacing and chunking are guidance, so I’d expect the same reversal, and I see it: on my own code, or a language I live in, the scaffold is a downgrade — I navigate faster than any served order and the chunks are furniture in the way. Drop into an unfamiliar codebase, a huge foreign diff, or a paper outside my field and I’m a novice on that material, and the same scaffold earns its keep. The clearest time it paid for me was reading into unfamiliar technologies I knew almost nothing about, diving in piece by piece to build an understanding I didn’t walk in with. The honest version isn’t “read everything this way.” It’s: reach for the scaffold when the material outruns your fluency, and put it down when it doesn’t. Knowing which you’re in is the skill.

The value of reading scaffolds falls as fluency on the specific material rises. Guidance helps when the material is unfamiliar, crosses a neutral point, then becomes redundant load when the reader is already fluent.
The scaffold earns its keep only while the material outruns your fluency.

The point

The model can read for you or read to you, and only one leaves you understanding the thing. Reading to you — pacing the prose, answering the navigation, rendering the hard part in terms you hold, then getting out of the way so you check it against the raw — is how you get through more of what matters on the days the material is heavier than you are. It doesn’t do the reading. The reading was always the point; this just keeps it yours.


How sure I am: the human-cognition results are cited — fatigue and the vigilance decrement, non-linear code reading, comprehension by navigation, analogy-as-structure-mapping, expertise reversal. Applying them to AI-assisted reading and review is a reasoned bet on top of that research, not something those studies measured — same move, and same caveat, as Thinking at the Speed of Code. The workflow is lived: the machine has caught what I missed and I’ve caught what it missed, which is the whole reason neither owns the verdict. The frame on top — amplify versus replace, serve-the-reading-the-artifact-wants, build-then-sweep, place-by-fatigue — is mine, argued rather than measured. That this is the right default whenever material outruns your fluency is the wager. If it’s wrong somewhere, it’s there.

Sources

  • Mortimer Adler & Charles Van Doren, How to Read a Book (1940; rev. 1972) — reading for understanding over throughput.
  • SmartBear / Cisco Systems code review study (Cohen et al., 2006) — defect-detection effectiveness drops sharply past ~200–400 LOC and ~60 minutes in one sitting.
  • Norman Mackworth, “The breakdown of vigilance during prolonged visual search” (1948) — the vigilance decrement; sustained attention declines with time on a monitoring task.
  • Liu, Lin, Hewitt, Paranjape, Bevilacqua, Petroni & Liang, Lost in the Middle: How Language Models Use Long Contexts (2023; arXiv:2307.03172) — performance “is often highest when relevant information occurs at the beginning or end of the input context, and significantly degrades when models must access relevant information in the middle of long contexts, even for explicitly long-context models.” Measured on multi-document question answering and key-value retrieval, not on code review. “Recall sags in the middle of a long context” above is me applying their result to a diff; that transfer is my extension, not their finding.
  • Busjahn, Bednarik, Begel, Crosby, Paterson, Schulte, Sharif & Tamm, Eye Movements in Code Reading: Relaxing the Linear Order (2015, ICPC/IEEE) — code is read less linearly than prose; experts less linearly than novices.
  • von Mayrhauser & Vans, Program Comprehension During Software Maintenance and Evolution (1995) — the integrated comprehension model; understanding built by opportunistic navigation.
  • Peter Naur, Programming as Theory Building (1985) — a program is a theory the programmers hold, not the text.
  • Dedre Gentner, Structure-Mapping: A Theoretical Framework for Analogy (1983) — analogy as structural alignment onto a known structure.
  • Kalyuga, Ayres, Chandler & Sweller, The Expertise Reversal Effect (2003, Educational Psychologist) — guidance that helps novices becomes redundant load for experts.
  • Background pedagogy: instructional scaffolding (Wood, Bruner & Ross, 1976; Vygotsky); chunking (Miller, 1956); progressive disclosure (Nielsen).

Related: Give Away the Writing, Keep the Reading (keep the reading — this is how, when it’s heavy), A Description Can’t Replace the Code (why you check the gloss against the source), Noticing Is Cheap, Judgment Is Scarce (route the mechanical to the machine, the intent-bearing to you), A Pool of Models Narrows the Overlap (the machine pass is coverage, not a verdict), “Context Debt” Is a Strawman (deriving context on demand is the same read, done without the tool).