Konrad Sopala
May 14, 2026
5 min read
May 14, 2026
5 min read
Share
Cut code review time & bugs by 50%
Most installed AI app on GitHub and GitLab
Free 14-day trial
Two updates to the CodeRabbit PR walkthrough went live recently, and together they're a meaningful upgrade to what the walkthrough actually does. One changes how you read a PR, and the other changes how it gets routed to reviewers.
They sit in different parts of the flow, but they pull in the same direction: the walkthrough should explain the PR, not just describe it. A flat diff describes. A flat list of suggested reviewers describes. Neither helps you actually trust the change, or get it in front of the right people.
These two updates do.
You open a PR. The file list is alphabetical.
api/ db/ services/ tests/ utils/ web/
You start scrolling and try to reconstruct what happened: was the migration the starting point, or did it come after the API change? Is this new service the cause of the type changes downstream, or a consequence? Where do the tests fit?
This is the price of a flat diff. The order you read the changes in has no relationship to the order they were made in, or to which parts depend on which. You spend the first few minutes of every PR sorting that out before you can evaluate anything.
It gets worse with AI-authored PRs. They tend to be larger and touch more files at once, so the mental reconstruction tax gets paid more often. And the cost of getting it wrong is higher, because there isn't a human across the desk to ask what they were thinking.
We've written before about explainability, the idea that AI systems doing real work on things that matter have to show their homework, or the trust never quite materializes.
A flat diff is the opposite of that. It tells you what changed, not how the change was reasoned about, what depends on what, or in what order things had to happen for the whole thing to make sense.
The burden of figuring that out lands on whoever opens the PR.
Layer Based Walkthroughs are CodeRabbit's answer. Instead of an alphabetical file list, CodeRabbit reverse engineers how the change was actually built and organizes it into logical layers: what was changed first, what came next, and what depends on what. A typical PR walkthrough might be ordered:
Each layer comes with its own summary scoped to the changes inside it. You can read top-down for the full story, or jump to the layer that matters most to the kind of review you're doing. Security folks tend to want the boundary stuff, frontend folks tend to want the responses.
It works the same way whether a human or an AI agent wrote the changes. But the AI case is where it pays off most: when you can't ask the author what they were thinking, the walkthrough has to show the work instead.
Layer Based Walkthroughs are how CodeRabbit does that.
CodeRabbit has had suggested reviewers in the walkthrough for a while now. The suggestions come from git history and code ownership, which works well in steady-state codebases where the right reviewer for a file is whoever's been touching it recently.
It works less well in two cases:
The right reviewer isn't the most recent contributor. They're the subject matter expert for that area: the security team for anything in auth/, the data platform team for any migration, the SRE on call this week for infra changes.
The right reviewer is a team, not a person.
Suggested reviewers instructions let you spell this out directly in the CodeRabbit YAML file. Map reviewers, individual users or teams, to the conditions where they should be assigned:
When the list is empty, CodeRabbit falls back to its existing prior-PR-based suggestions, so you can be as exhaustive or as selective as makes sense for your team.
A couple of small things worth flagging:
If you've been mentally reconstructing the order of changes in every PR you open, Layered Walkthroughs should take a chunk of that off your plate.
If you've been writing the same Slack messages over and over, "Hey, can someone from the platform team take a look at this?", suggested_reviewers_instructions will handle that part for you.