Code is no longer the bottleneck. Understanding is
As coding agents lower the cost of producing code, the bottleneck in software development shifts from writing code to understanding changes. CodeRabbit introduces "Change Stack," a review view that groups related edits by behavior, providing a traceable hierarchy from intent to code to keep human judgment active.
Code is no longer the bottleneck. Understanding is. | CodeRabbit
Code is no longer the bottleneck. Understanding is.
Harjot Gill
July 21, 2026
7 min read
July 21, 2026
7 min read
Understanding keeps judgment active
A diff is evidence, not a route
One change, two reading orders
The useful unit is behavior
A map must lead back to code
The review interface becomes a stack
Back to blog
Share
Cut code review time & bugs by 50%
Most installed AI app on GitHub and GitLab
Free 14-day trial
Get Started
Catch the latest, right in your inbox.
Add us to your feed.
Catch the latest, right in your inbox.
Add us to your feed.
Keep reading
Opus 5 for code review: Cleaner actionable comments, noisier overall
Opus 5 produced a cleaner actionable-comment stream, but caught fewer known issues and generated roughly four times the baseline's nitpicks. Here is where the model may fit — and where it does not.
Close the loop after every merge: the agent that reviewed your PR can now follow through
Post-Merge Actions use pull request context to handle changelogs, documentation, tickets, and other work that should happen after merge.
GPT-5.6 Sol and Terra: Where they fit for coding agents and code review
OpenAI’s GPT-5.6 family includes capability tiers: Sol as the flagship model, Terra as the lower-cost option, and Luna as the fastest, lowest-cost tier.
GetStarted in2 clicks.
Try it for free
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
CodeRabbit recently introduced Change Stack, a review view that groups related edits into named paths based on system behavior, then links each path back to the exact files and lines. The TanStack/cli pull request #490 shows it on a real change spanning 45 files across authentication, environment handling, templates, package configuration, and tests.
Same change, higher altitude
One diff, two reading orders: file structure and system behavior.
GitHub presents the pull request as 45 changed files. Change Stack organizes the same diff into six review paths based on related system behavior. Neither view changes the code. They change where the reviewer starts.
File organization
GitHub preserves the exact file and line history. That is the evidence a reviewer must be able to inspect.
Change organization
Change Stack proposes a reading order based on related behavior. Each path still opens the code beneath it.
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.
System behavior
Ten files form one request path. The diagram shows how control moves before the reviewer opens the implementation.
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.
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 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