u/coffeebeforelogicc

Should a review agent see the implementation thread, or only the diff?

Been testing a three-role setup on a small code change: one model handled the implementation, another reviewed it, and a third drafted the release notes.

Until now, I did this manually. I’d open another chat, paste in the diff, sometimes include notes from the first model, and ask what it missed. I hadn’t really considered whether those notes were helping the reviewer or anchoring it to the original explanation.

For this run, I added three providers through BYOK in MiniMax Code. The part I wanted to test was the handoff, so I gave the reviewer the diff and test output but none of the implementation conversation.

It caught one case the first model missed. An API response field was typed as string | null, but the patch treated it as always present. Every test fixture happened to populate the field, so the tests still passed. The reviewer flagged the missing null branch.

That’s only one run, so I can’t say the missing context caused the catch. It did make me wonder whether a review agent should start cold and ask for the reasoning only when it needs it.

There are downsides. Cross-provider calls were slower, I had three separate quotas to watch, and an isolated reviewer can flag a deliberate tradeoff simply because it doesn’t know why the decision was made.

For people separating implementation and review, do you give the reviewer only the diff and test output, or include the design reasoning too?

reddit.com
u/coffeebeforelogicc — 1 day ago