Coding agents increasingly generate pull requests (PRs) for real-world software issues, yet one-shot PR generation remains open-loop: the PR is proposed without systematic review, diagnosis, or revision. We introduce \textbf{SWE-Review}, a framework for closing this loop with agentic code review. Given an issue and an AI-generated PR, a reviewer agent explores the repository, decides whether the PR should be accepted, and provides structured feedback for revision. We evaluate this setting with our proposed \textbf{SWE-Review-Bench} to measure both review correctness and downstream revision usefulness. We further curate \textbf{SWE-Review-Traj} dataset to study broader applications of agentic review and fill the data-scarcity gap for open reviewer training. Experiments show that agentic review continuously improves PRs through a generate-review-revise loop, outperforms single-turn fixed-context review in both decision accuracy and resolve rate after revision, transfers beyond review to improve issue-resolution models, and enables effective and efficient test-time scaling. These results position agentic code review as a practical mechanism for moving AI coding agents from one-shot PR generation toward closed-loop issue resolution.
Alex: Welcome to another episode of ResearchPod. Today, we're discussing SWE-Review, a framework designed to change how AI agents handle software engineering.
Sam: So, this is basically about stopping AI from making mistakes when it writes code?
Alex: That's the core idea. AI coding agents are quite capable at generating code, but notoriously poor at verifying it. This research tries to close that gap.
Sam: The core problem being that current systems just propose a fix and submit it, without really checking if it works in the real world?
Alex: Exactly. Most agents operate in what you'd call an open loop. Imagine writing an essay, handing it in, and never proofreading it. That's essentially what these systems do — they propose a fix without any systematic review or diagnosis.
Sam: So instead of just submitting a patch and hoping for the best, this framework adds a dedicated "reviewer" agent. How does that actually work?
Alex: Think of it like a detective story. A standard code reviewer reads the list of changes — what was added, what was deleted. But an agentic reviewer actually visits the scene. It doesn't just look at what changed; it explores the entire codebase, traces how different parts of the program talk to each other, and runs tests to see whether the fix actually holds up.
Sam: So it's moving from passively reading text to actively testing behavior. Does the paper have a name for that?
Alex: They call it "Agentic Repository Exploration." The key insight is that bugs are often caused by interactions happening far away from the lines of code that were actually changed. A reviewer that only looks at the diff — the list of changes — can easily miss those hidden connections.
Sam: And when it does find a problem, it doesn't just stamp the patch "rejected," right? It gives the original agent something useful to work with?
Alex: That's the heart of the system. They call it the "generate-review-revise" loop. The reviewer's feedback turns what would otherwise be a binary pass-or-fail verdict into a conversation. The original agent gets specific, actionable notes, revises its patch, and submits again. It's closer to how a junior developer might work with a senior colleague than how a compiler checks for errors.
Sam: Does the data support that this back-and-forth actually leads to better outcomes?
Alex: The study suggests it does. They measure something called the Resolve Rate after Revision — RRR for short. Think of it as asking: when the reviewer flags a problem and sends feedback, how often does the agent come back with a patch that actually works? A higher RRR means the feedback is genuinely useful, not just noise.
Sam: That's a more meaningful measure than just asking whether the final code passes. It's testing the quality of the whole process.
Alex: Precisely. And that connects to another concept in the paper — test-time scaling. Normally, when people want an AI system to perform better, they train a bigger model, which is expensive and slow. Test-time scaling is a different approach: instead of making the model larger, you give it more time and computing resources to think through the problem while it's actually working. The review-and-revise loop is a practical example of that idea.
Sam: So the improvement comes from the process, not just the raw power of the model. Spend more effort checking your work, get better results.
Alex: That's the paper's argument, yes. And it's a meaningful distinction, because it suggests you don't necessarily need a more powerful AI to get more reliable code — you need a more careful workflow.
Sam: It's a more grounded approach than I expected. Less about building a smarter AI and more about building a more disciplined one.
Alex: That's a fair way to put it. The move from one-shot generation to a closed-loop investigation — generate, review, revise — is what the researchers see as the path toward AI coding agents you can actually depend on. Thanks for listening to ResearchPod.