Jones Codes

Review Before You Push: Why Local Code Review Matters in an Agentic Workflow

7 min read

Review Before You Push

I’ve been running multiple Claude Code sessions in parallel for a while now. Two or three agents working across different parts of a codebase, each tackling its own task. The speed is real. But so is the mess that shows up on GitHub when you skip the review step.

An agent finishes its work. The code compiles. Tests pass. You push it up, open a PR, and that’s when you notice it. The agent refactored a utility you didn’t ask it to touch. It renamed a variable for “clarity.” It added error handling to a function that was already fine. The diff is twice the size it should be and half of it is noise.

Now you’re making fix commits. Reverting the extra changes. Leaving PR comments to yourself. It’s a waste of time and it’s entirely preventable.

The Pattern I Kept Seeing

I wrote about this feeling in my Codex experimentation journal months ago. “There are multiple instances where Codex adds a few extra changes that could introduce other new issues.” That observation stuck with me because the problem only got worse as I started running more agents.

The issue isn’t that agents write bad code. They usually don’t. The code is syntactically correct, well-typed, and often more thorough than what I would have written by hand. The issue is that agents don’t understand intent boundaries. You ask for input validation on a signup form and the agent also restructures your form state, changes how errors display, and adds a debounced uniqueness check on the username field. Each of those changes might be reasonable in isolation. Together, they represent scope creep that nobody asked for.

When you’re running one agent, you catch this in real-time because you’re watching it work. When you’re running two or three, you can’t watch everything. Changes slip through.

The GitHub Tax

Here’s what the workflow looks like without a local review step:

  1. Agent finishes work
  2. You stage and push
  3. Open a PR on GitHub
  4. Start reviewing the diff on GitHub’s UI
  5. Notice unintended changes buried in the diff
  6. Pull the branch back down, make fixes
  7. Push again
  8. Re-review on GitHub

That round trip is expensive. Not in compute or dollars but in attention. Every time you context-switch between your editor, the terminal, and GitHub’s diff viewer, you burn mental energy. And if you’re juggling multiple agent branches, multiply that overhead by however many PRs you have open.

The fix is simple. Review the diff locally before it ever touches GitHub.

Building DiffPrism

This is why I built DiffPrism. It’s a local-first code review tool designed specifically for agent-generated changes. You install it globally from npm and point it at your staged changes. It opens a browser-based diff viewer with syntax highlighting, a summary of what changed, and a simple approve or reject flow. That’s it.

npm install -g diffprism
 
# Review staged changes
diffprism review --staged
 
# Review with a title for context
diffprism review --staged --title "Add auth middleware"
 
# Review a specific range
diffprism review main..feature-branch

A browser window opens. You see every file that changed, line by line, with an impact analysis that categorizes files by risk level. Critical changes surface first. Mechanical changes like formatting or imports get flagged as low-risk so you can skim them.

You approve or request changes. The result comes back as structured JSON to your terminal. Done.

DiffPrism review UI

Where It Really Shines: The MCP Integration

The CLI is useful on its own but the real power is the Claude Code integration. DiffPrism runs as an MCP server, which means Claude Code can trigger a review directly.

The agent finishes writing code. It calls open_review with the diff reference, a title, a description of what it changed, and its reasoning for the changes. Your browser opens with the diff. You review it right there, in the moment, while the context is still fresh. You approve and the agent moves on. You request changes and the result flows back to the agent as structured feedback it can act on.

# Start the MCP server for Claude Code
diffprism serve

The feedback loop is tight. No pushing to GitHub. No opening a PR just to see what changed. No fix commits. The review happens at the source, before the code leaves your machine.

Why Local-First Matters

There’s a philosophical point here beyond the workflow optimization. When you review code locally, you maintain a relationship with your own codebase. It’s easy to fall into a pattern where agents write code and GitHub becomes where you discover what they wrote. That’s backwards. You should understand changes before they’re committed, not after they’re merged.

Local review also catches something that CI never will: intent drift. Your linter passes. Your tests pass. Your types check. But the agent changed something you didn’t ask it to change, and no automated check can flag “this wasn’t part of the task.” Only a human looking at the diff with the original intent in mind can catch that.

I’ve been thinking about this for a while. The best work I’ve gotten from agents is when I spend most of my time conceptualizing the problem, gathering context, and presenting it clearly. DiffPrism is the other side of that coin. It’s the step where you verify that what came back actually matches what you asked for.

The Multi-Agent Case

This matters even more when you’re running agents in parallel. Say you have three Claude Code sessions going:

  • Agent A is adding a new API endpoint
  • Agent B is refactoring the auth middleware
  • Agent C is writing tests for an existing feature

Agent B’s refactor might change a shared utility that Agent A’s new endpoint depends on. Agent C’s tests might lock in behavior that Agent B just changed. Without reviewing each agent’s output before committing, you’re setting yourself up for merge conflicts and subtle breakage that’s hard to trace.

With DiffPrism in the loop, you review Agent A’s work, approve it, commit. Review Agent B’s work, catch that it touched a file Agent A also modified, decide how to reconcile. Review Agent C’s tests, confirm they align with the current state of the code. Each review takes a minute or two. The alternative is untangling conflicts on GitHub after the fact, which takes much longer.

What I’ve Learned

Review at the moment of creation, not after the fact. The longer you wait between an agent finishing its work and you reviewing that work, the more context you lose. DiffPrism opens the diff immediately. You’re looking at the changes while the task is still fresh in your mind.

Agents are fast, humans are the bottleneck, and that’s fine. The value isn’t in matching the agent’s speed. It’s in maintaining accuracy and intent. A two-minute local review prevents a twenty-minute cleanup later.

Structure the feedback. DiffPrism returns a ReviewResult with a decision, comments tied to specific files and lines, and a summary. When this flows back to the agent, it’s actionable. “Request changes: line 42 of auth.ts introduces a side effect I didn’t ask for” is infinitely more useful than “fix this PR.”

No data leaves your machine. This was a non-negotiable for me. DiffPrism runs entirely locally. No accounts, no sign-ups, no code being sent anywhere. It’s a local server that opens a local browser tab.

If you’re running agents and pushing their output straight to GitHub, try adding a local review step. The diff is worth looking at before it becomes a PR. DiffPrism is open source, MIT licensed, and takes under a minute to set up.

Your agents are fast. Make sure you keep up.

Graph View

Recent Posts