Code is no longer the bottleneck. Understanding is.

Coding agents have changed what is scarce in software.

A plausible change takes less time to produce. A team still needs to decide whether it belongs, how it reshapes the system, and what should happen next. Passing tests do not answer those questions.

This is the explainability gap. Models can take on more context and work in parallel. Human comprehension does not scale the same way. The bottleneck moves from producing code to understanding it well enough to direct it. When a team can no longer explain a change, it stops shaping the system and starts accepting output.

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, but not a summary that asks for blind trust. It needs a path from intent to system behavior to code, with every claim traceable to the diff.

Understanding keeps judgment active

A reviewer is not there to count changed files. The job is to answer a different set of questions:

• What changed at the system level?
• Which parts of the system move together?
• Where are the boundaries and assumptions?
• What deserves human attention?
• Should this design become part of the system?

Tests, static analysis, and agents can verify more implementation detail. People still decide whether a boundary is sound, whether a tradeoff is worth it, and whether the change points the system in a useful direction.

Without a working model of the change, a reviewer can only approve or reject. With one, they can improve the design, challenge an assumption, or connect the change to the next decision.

Reviewers should not each have to reconstruct the change from a file tree. That work is slow, and separate reconstructions make discussion harder. Review should give the team a shared model to test.

A diff is evidence, not a route

A repository path tells a reviewer where code lives. It does not explain why several files changed together or which file should be read first.

Repositories group code by implementation. Reviewers reason about behavior and decisions. One behavior can cross a route, provider, configuration file, template, and test.

The diff remains the exact evidence. It needs a useful reading order.

One change, two reading orders

TanStack/cli pull request #490 is ordinary in purpose but broad in implementation. The update touched 45 files across authentication, environment handling, templates, package configuration, and tests.

GitHub begins with 45 files. Change Stack groups the same diff into six paths through related system behavior. Neither view changes the code. They change where the reviewer starts.

The two views answer different questions. GitHub shows where the code changed. Change Stack proposes which changes should be judged together.

Those six paths are not a verdict. They are a claim about which code ranges belong in one thought, and reviewers can challenge that claim.

The useful unit is behavior

One Change Stack path joins ten files into a single sign-in flow. No one file contains the behavior the reviewer needs to judge. It exists between the route, provider, callback, configuration, and tests.

The diagram gives the reviewer a model to test against the code. The first question becomes not “what is this flow?” but “is it correct, complete, and safe?”

The author, reviewer, and maintainer can challenge the same proposed flow instead of carrying three private interpretations of the diff.

A map must lead back to code

Abstraction is cheap when it ends at a polished summary. Traceability is harder.

In this review, the reviewer can move from the pull request to a change layer, from the layer to a system flow, and from the flow to semantic entities, files, and lines. They can judge the behavior at a high level, then test each claim against the implementation.

Each level has one job. 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. Files and lines provide the 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.

The review interface becomes a stack

As coding agents produce more, larger diffs and longer summaries will not make the work governable. Both leave the reviewer to reconstruct the system. A useful review model can be inspected, corrected, and discussed.

The review interface needs a stack, not a prettier summary. Each level answers a different question, and every level connects back to code.

No representation is sufficient alone. The value comes from moving between intent, behavior, and exact evidence without breaking the chain.

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. 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 stays the ground truth. The stack makes it usable for judgment.

Inspect the merged pull request on GitHub · Open the same pull request in Change Stack