Building Interactive Agentic Code Reviews in 20 Minutes

In the previous post in this series, I argued that software factories aren't a product but a workflow you can implement in your organization. Once in place, you can use them to automate the parts of the work that need less human input. This makes them more practical, but for many organizations and many types of work, they are still too much. There is one part of the workflow, though, where every team and every developer can benefit from automation: code reviews.

In this article, I'll show how to assemble an interactive code review process out of the same building blocks. With it, you can get higher throughput without sacrificing quality.

In This Series

This two-part series explores how to build practical agentic software workflows:

The Problem

Many developers don't really review code anymore. They just pretend. A review that adds value takes a lot of time, and the number and size of PRs keep growing. The old-school way no longer works.

To solve this problem, let's first figure out what code reviews are for.

What Are Code Reviews For?

We need code review for a few reasons:

Helping another human developer understand the nature of the change.
Checking that the change is architecturally correct—getting the high-level picture right.
Catching low-level problems, such as race conditions.
Verifying that APIs are used correctly and small but important edge cases are handled.
Keeping the code in line with community and organizational best practices.
Preventing malicious code from landing in main.

Historically, one process covered all six: a senior engineer read every line of every change. That no longer works. Everyone produces too much code, and agents are now better at some of these jobs. They are probably better at 3 and 4, maybe even 5 and 6, although that's debatable. But they cannot do 1—conveying the change to a human—and they are terrible at 2 because they don't understand the long-term implications of a change.

Since 1–6 are so different, one mechanism shouldn't cover them all. We need different mechanisms for different items.

Code Review Process

Now, let's set up a process that will address some of these items.

FIND WORK. Check the issue tracker (e.g., Linear) for items awaiting review.
GET PRs AND SESSIONS. Figure out which PRs and sessions the issues point to.
SET UP REPOS. Check out the right repos at the right SHAs.
SET UP AGENTS. Transport the history of the agents that implemented the change to the reviewer's machine. This unlocks everything.
ADVERSARIAL REVIEW. If the change is non-trivial, run an automated adversarial pass on it.
MANUAL REVIEW. A human examines the results and can talk to the agents directly.
SUBMIT FEEDBACK. Leave comments and/or push changes to the PRs.
COMPLETE. Mark the item as reviewed in the issue tracker.

The Capabilities We Need

To implement the steps above with an agent, we need the following:

VCS
Issue tracker
Institutional memory
Ephemeral workspaces
Cross-repo orchestrator
Adversarial reviews
Trigger

Let's Build It

Once we have these capabilities, building the automation is easy: it's just a script that wires everything together.

This video shows how I use the script:

We'll use GitHub for VCS, Linear as the issue tracker, and Polygraph for institutional memory, ephemeral workspaces, cross-repo orchestration, and adversarial reviews. Polygraph is an agent-agnostic meta-harness.

The script is about 600 lines, and most of it is Linear integration.

This is the high-level view of what the script does:

main():
    issues = linear.query(
        "In Progress / In Review issues in $LINEAR_PROJECT_NAME
         NOT assigned to $ME"
    )

    for issue in issues:
        processIssue(issue)

processIssue(issue):
    if issue already SUBMITTED / COMPLETED: return skipped

    verdict = claude -p --model haiku "does a comment ask $ME to review this?"
    if verdict != "yes": return skipped

    # FIND SESSION: which Polygraph session holds the work
    sessionId = findSessionBasedOnAttachedReferences(issue)
    # Direct references, or matched via opened PRs
    if no sessionId: error

    runReviewPipeline(sessionId)

runReviewPipeline(sessionId):
    overview = claude -p "
      load polygraph:adversarial-review skill and review session $sessionId
      after generate high-level view of this effort"

    reviews.json[entry] = { sessionId, overview, status: SUBMITTED }

It gets the issues from Linear that I need to review, matches Polygraph sessions with them, performs an adversarial review, and then creates a summary of each change. The results are stored in a local file called reviews.json.

I also have a tiny TUI that provides a convenient way to review and manipulate reviews.json.

Reviewing Sessions

Note the subtle shift: we are sort of reviewing sessions, not PRs. The PRs are still there, and the goal is still robust code, but we no longer look at PRs on their own. We are reviewing the decisions made in the session. Some of those decisions show up in the code, but some don't.

Making Changes and Testing Stuff

The reviewer has a live session, so small fixes are cheap: ask the agent to make them and push. Reviewing becomes collaboration. For interesting changes, you can go further: run commands, test things, and see how they look. If you apply some of the adversarial review's feedback directly instead of sending it back to the author, you can validate the result on the spot.

Running in the Background

All of this should run in the background on a schedule. Adversarial reviews take a while, so as a reviewer you want to open a session that is already pre-reviewed—warm, so to speak—and start interacting right away.

In my case, the script maintains a small file locally, and my little program lists everything that has already gone through the automated pass. Those sessions are warm, and the agents are ready to chat. I can resume any of them and discuss the change.

This means I can check on things a few times a day and get a few changes that my agents have already examined and set up completely. I can go talk to them, run commands, and explore the change without waiting for the automated pass.

These Go to Eleven

The script is intentionally small. The beauty of this approach is that you can combine capabilities like Polygraph and Linear to create a process that fits into your existing workflow.

PR-Based Code Review Tools

What about tools that review your hunks right on the PR? They are a bare-bones version of the adversarial review step: less context, weaker models, and no ability to verify anything by running it. In this flow, they are largely redundant.