> Why not have an agent create a perfect “review plan” for human consumption? Split the review up in parts that can be individually (or independently) reviewed and then fixed by the coding agent. Have a proper ordering in files (GitHub shows files in a commit alphabetically, which is suboptimal), and hide boring details like function implementations that can be easily unit tested.

Yes exactly! I have been using this to create a comment on the PR, showing suggested review order and a diagram of how changes relate to each other. And even this super simple addition has been very helpful for code review so far!

(more on this: https://www.dev-log.me/pr_review_navigator_for_claude/)

Exactly this, existing code review tools became insufficient with the increase of volume of code, I would like to see more innovation here.

One idea that comes to mind to make review easier would be to re-create commits following Kent Beck's SB Changes concept - splitting structure changes (tidying/refactoring) and behavior changes (features). The structure changes could then be quickly skimmed (especially with good coverage) and it should save focus for review of the behavior changes.

The challenge is that it is not the same as just committing the hunks in different order. But maybe a skill with basic agent loop could work with capabilities of models nowadays.

Unfortunately GitHub doesn’t let you easily review commits in a PR. You can easily selectively review files, but comments are assumed to apply to the most recent HEAD of the PR branch. This is probably why review agents don’t natively use that workflow. It would probably not be hard to instruct the released versions of Opus or Codex to do this, however, particularly if you can generate a PR plan, either via human or model.

I've been talking about having AI add comments to PRs to draw attention to things that should be given special attention since last May. I think most code review tools don't do this because A/B testing has shown people engage less/churn more with noisier review output.

I do this. For example, the other day I made a commit where I renamed some fields of a struct and removed others, then I realized it would be easier to review if those were two separate commits. But it was hard to split them out mechanically, so I asked Claude to do it, creating two new commits whose end result must match the old one and must both past tests. It works quite well.

I like this thought. Scaling review is definitely a bottleneck (for those of us who are still reading the code), and spending some tokens to make it easier seems worthwhile.

Yes please. There are many use cases where failure modes are similar to not using AI at all, which is useful.

Many very low risk applications of AI can add up to high payoff without high risk.

“I have a PR from <feature-branch> into main. Please break it into chunks and dispatch a background agent to review each chunk for <review-criteria>, and then go through the chunks one at a time with me, pausing between each for my feedback”