Harjot Gill
July 21, 2026
8 min read
July 21, 2026
8 min read
Share
Cut code review time & bugs by 50%
Most installed AI app on GitHub and GitLab
Free 14-day trial
GetStarted in2 clicks.
Coding agents have changed what is scarce in software.
Producing a plausible change is getting faster. But a team needs more than evidence that the code runs. It needs enough understanding to decide whether the change belongs, how it reshapes the system, and what should happen next.
That mismatch is the explainability gap. Agent output can expand through more capable models, more context, and more parallel work. Human comprehension does not scale the same way. The bottleneck moves from writing the change to building enough understanding to direct it. When people can no longer explain a change, they stop shaping it and start accepting it.
Most review interfaces start with files, lines, and comments. That evidence is essential. It is also a poor place to begin when one system change crosses routes, providers, templates, tests, and configuration.
Review needs a higher level of abstraction. It does not need a summary that asks for blind trust. It needs a path from intent to system behavior to code, with every claim traceable back to the diff.
A reviewer is not there to count changed files or act as a final checksum. The job is to answer a different set of questions:
Tests, static analysis, and agents can check more of the implementation. That does not remove the need for human judgment. It raises the level where judgment matters. A team must still decide whether a boundary is sound, whether a tradeoff is worth it, and whether the change creates a system they want to keep building.
Without a working model of the change, a reviewer is left with a thin choice: approve or reject. They cannot improve the design, challenge an assumption, or connect the change to the next decision. Comprehension lets the team direct the work.
The scarce work is a shared mental model. If every reviewer has to reconstruct one from a file tree, review capacity cannot keep pace with generation capacity. If each person reconstructs a different one, the team cannot reason about the change together. The interface becomes part of the bottleneck.
A repository path works like a GPS coordinate. It tells you where code lives. It does not always tell you why several files changed together or which file makes the next one intelligible.
The repository is organized around implementation. Review is organized around decisions. One system behavior can cross a route, provider, configuration file, template, and test without respecting the folders that hold them.
The answer is not to replace the diff. The diff remains the exact evidence. The missing layer is a useful route through that evidence.
TanStack/cli pull request #490 is a useful example because it is broad without being exotic. The change touched 45 files across authentication, environment handling, templates, package configuration, and tests.
In a file view, the reviewer starts with 45 coordinates. In Change Stack, the same code becomes six paths through related system behavior. Nothing about the underlying change is hidden or rewritten. Only the starting point changes.
The diff preserves every changed line. The review map gives those lines a system-level reading order.
GitHub preserves the exact file and line history. That is the evidence a reviewer must be able to inspect.
Change Stack proposes a reading order based on related behavior. Each path still opens the code beneath it.
Both views are accurate. One answers where did the code change? The other proposes which parts should be evaluated together?
The six paths are not an authoritative interpretation of the pull request. They are a review map: a proposal about which code ranges belong in the same thought. A useful map lowers the cost of orientation. A trustworthy one also lets the reviewer challenge the grouping.
One path in the TanStack change connected ten files into a single sign-in flow. No one file contained the behavior the reviewer needed to judge. The behavior existed between the route, provider, callback, configuration, and tests.
Ten files become one request path. The diagram exposes how control moves through the change before the reviewer opens
the implementation beneath it.
The diagram does not replace the code. It gives the reviewer a model to test against it. Instead of spending the first pass discovering that a flow exists, the reviewer can spend it checking whether the flow is correct, complete, and safe.
That model also gives the team a common object to challenge. The author, reviewer, and maintainer can discuss the same proposed flow instead of carrying three private interpretations of the diff.
That is the useful change in altitude: from repository structure to system behavior.
Abstraction is cheap if it only produces a polished summary. The hard requirement is traceability.
In this review, the path runs from the pull request to a change layer, from the layer to a system flow, and from that flow back to semantic entities, files, and lines. The reviewer can zoom out to ask whether the behavior makes sense, then zoom in to test the claim against the implementation.
Zoom out to recover intent and behavior. Zoom in to verify the map against code. The abstraction is useful only when
both directions remain open.
Each level answers a different question. Intent explains why the change exists. System behavior shows how parts interact. A layer sets a review boundary. A semantic entity names the function, route, or type involved. The file and line provide the exact evidence.
Remove the upper levels and the reviewer must reconstruct the system from coordinates. Remove the lower levels and the reviewer is asked to trust a story they cannot verify.
Agentic development will not become governable through larger diffs or longer summaries. Both leave the reviewer doing the same reconstruction work. A summary is one-way. A useful model can be inspected, corrected, and discussed.
The review interface has to become a stack. Intent explains why the change exists. System behavior shows how parts interact. A change layer defines what belongs in one review path. Semantic entities, files, and lines provide the exact evidence.
No representation is sufficient alone. The value comes from moving between them without losing the chain of evidence.
The goal is not to read less code. It is to spend code-reading time testing a coherent model instead of constructing one from scratch. It keeps human judgment attached to the design, not only to the final approval. Machines can organize the change and expose the paths. Humans decide whether the model is accurate, the boundary is sound, and the direction is worth taking.
The diff remains the ground truth. The stack gives the team a way to think with it.
Inspect the merged pull request on GitHub · Open the same pull request in Change Stack
