Skip to content
Published on

The Claim That Understanding Is the Bottleneck, and Its Circularity — When the Explainer Is the Thing Under Review

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
Share
Authors

This post is based on items I read directly from the Hacker News API and the GeekNews feed on 2026-08-15. Scores and rankings keep moving.

What was up there

An item read from the Hacker News API. The title is Understanding is the new bottleneck, the item number is 49290299, and as of 2026-08-15 it stood at 418 points with 235 comments. The link points to an essay by Geoffrey Litt. The same item appeared in the GeekNews feed.

The author's argument

The starting point is familiar: agents now produce code faster than people can read and absorb it.

That much is common. But the author does not go to the common conclusion. The natural response is to hand verification to the agents too — and doing so, he argues, turns the human from a participant in the creative work into a spectator.

So the shift he proposes is a change of goal: move from understanding in order to verify to understanding in order to participate. That distinction is the heart of the essay. Understanding to verify needs only enough to judge whether this change is correct; understanding to participate needs enough to decide what to do next. The latter demands a mental model of the system rather than a reading of the code.

He then proposes building that understanding with methods borrowed from education, and offers three.

  • Code explainers: give background context first, build intuition before details, include interactive figures, and order the changes by narrative rather than by file path. Paired with spaced repetition quizzes used as a pacing regulator.
  • Micro-worlds: environments you manipulate rather than read. His examples are a purpose-built debugger for a Prolog interpreter and a command-center game for a website migration.
  • Shared spaces: environments where a team builds one model together instead of each person building their own separately.

He notes this does not happen automatically and that the tooling must be built deliberately alongside the development. And he ties the direction back to the old vision of computers as a medium for understanding.

The objection in the comments matters more

The most valuable part of this item is the comments, and one of them runs straight into the proposal.

One comment noted that a major reason to understand the code yourself is to check that the model is not wrong — and that if the explanation itself is generated by a model, that does not work. The same comment added that model-written change descriptions are broadly disliked on their team, because they lay out the mechanical changes at length while carrying no sense of motivation.

That pins the circularity exactly. Understanding is needed because code can be plausible but wrong; if that understanding is supplied by the same kind of plausibility, the point of verification has merely moved one step.

There was a different line of objection too: we have always lacked understanding and have built enormous systems nobody fully understood, and it is only now, with scale a few orders of magnitude larger, that the deficit feels like a bottleneck. That corrects the age of the problem more than it refutes the author.

Testing the three mechanisms against the objection

Sorting the three proposals by the circularity objection splits them, and that split is the genuinely usable part of this piece.

Code explainers are fully exposed to the objection. If the same agent generated the code and the explanation, the explanation inherits the code's errors. When code rests on a wrong assumption, the explanation narrates that assumption naturally. A person reads a coherent story and is convinced.

Literate diffs largely survive. They do not create new content; they reorder a diff that already exists. The code itself is untouched and all the model does is recommend which file to read first. A bad ordering makes reading awkward, but it does not inject false information.

Spaced repetition quizzes invert the objection. A quiz does not measure whether the explanation is right; it surfaces what the reader's model is. And when the answer is checked against the code's actual behavior, what is wrong may be the person's model — or it may be the explanation. Either way the mismatch comes to the surface. That is worth more than the pacing role the author assigns it.

Micro-worlds are the strongest. A debugger or a runnable environment is not reading an explanation but running the system, so the thing giving answers is the code itself. No model-written narration sits in the middle.

Summarized: mechanisms that generate explanations are weak, and mechanisms that force a comparison are strong.

How to apply this

Ordered by what you could try this week.

First, attach a reading order to the diff. When you put up a large change, spend three lines at the top of the description saying which files to read and in what order. It needs no tooling, and it removes the largest block of time a reviewer loses.

Second, leave questions rather than explanations. Instead of writing what the code does, write why it was not done the other way, and what would have to break for this change to be wrong. The second is effectively a verification condition, so it becomes the basis for deciding whether to suspect this change when something goes wrong later.

Third, turn the signal of having understood into a comparison. An approval button is not evidence of understanding. Have the reviewer restate the change's behavior in one sentence; the moment that sentence diverges from the author's intent is the finding. This habit connects with the directions in code review that teaches and a review strategy for AI-generated code.

Who this does not apply to

If agent-written code is still a small slice of your total, this is not yet your bottleneck. Existing review practice is sufficient, and building these mechanisms in advance is overinvestment.

Short-lived code is largely outside this too. Nobody makes a subsequent decision on top of a one-off script or an experiment, so understanding-to-participate is not required. For that code, understanding-to-verify — is this result correct right now — is enough. It is the author's distinction used in the opposite direction.

Conversely, what the essay targets most precisely is a long-lived system that several people are modifying through agents at once. That is where a state in which nobody holds the full model gets built quietly, and where the fact usually surfaces only after an incident.

Summary

The distinction the essay draws — understanding to verify versus understanding to participate — is useful. But the proposed mechanisms do not carry equal weight. Sorted by the circularity the comments identified, the ones that write a better explanation only move the problem, and only the ones that make a person's model get compared against the code reduce it. So if you build one thing, build a place where the comparison is forced, not a better summary.

Sources and related reading

The sorting of the three mechanisms against the objection, and the application advice, are my own, built on the essay and the comments.

Discuss on Twitter • View on GitHub