How to Actually Build a Code Review Agent — With a Second Model, Not the Same One
Why self-reviewing code with the same model misses blind spots, and how to route diffs to a genuinely different model before merging.
Building a code review agent sounds straightforward. Prompt an AI to check a diff, catch the bugs, approve the merge. The first version almost always uses the same model that wrote the code. It feels efficient. One system, one context window, one prompt chain. Then the review passes, the code ships, and the same logical gap that the writer missed is also missed by the reviewer. Self-review is a known cognitive trap in software engineering, and asking an AI to do it creates a mirror image of the same problem. The fix isn't to prompt better. It's to route the diff to a genuinely different model before it touches main.
1. The echo chamber of identical models
Why it happens: Training data and prompt instructions create predictable reasoning patterns. When model A generates code and model A reviews it, both share the same training biases, the same blind spots, and the same tendency to optimize for fluency over correctness. You get a smooth-sounding approval that validates the original logic without actually stress-testing it.
The fix: Separate the writer and the reviewer into distinct model calls. Use a fast, cost-efficient model for generation, then pass the exact diff to a model with a different architecture or training focus for review. The review prompt shouldn't ask for a general summary. It should ask for specific checks: missing error handling, edge cases in the loop, or security assumptions that don't match the actual input. When you run this on a real pull request, the second model stops echoing the first and starts flagging the exact boundary condition that will throw a null pointer at runtime.
Connect the Claude or Codex you already pay for — the rest runs on workers that cost a fraction.
Download meshcode →2. Feeding the full file instead of the diff
Why it happens: It's easier to paste the whole file into the context window and ask the agent to "read through this and tell me what's wrong." The model returns a polite, high-level list of suggestions that sound helpful but don't actually touch the lines that need changing.
The fix: Feed only the diff, not the full file. Ask the reviewer to respond in a structured format that maps each comment to a specific line number and proposes a concrete replacement. When you test this with a real branch, the model stops giving vague advice like "consider adding validation" and starts flagging the exact line that silently swallows a timeout error. You can see the suggestion land on the right line, not drift into the documentation section.
3. Treating the agent's output as a final stamp
Why it happens: The agent says "LGTM" and the terminal looks clean, so it's tempting to let the merge button auto-click. Automated approvals feel like a win, especially when the review took seconds instead of hours.
The fix: Use the agent's output as a first pass, not a final approval. Route the review summary to a human checklist. Verify the proposed line changes match your intent, check for dependency shifts, and only then apply the patch. A real scenario: a review agent caught a missing try/catch around a network call, but the human reviewer noticed it would also drop a critical auth token refresh. The agent flagged the gap. The human caught the consequence. The second model caught the syntax. The first pass caught the flow.
The pattern underneath all of these
Most of these pitfalls come from treating the review step as a formality instead of a stress test. The agent that writes the code is optimized for speed and completion. The agent that reviews it should be optimized for friction and edge cases. Routing the same diff through two different models forces that separation, and it catches the quiet failures that slip through when one system checks its own homework. meshcode is a native desktop app built around exactly this workflow — it creates files, runs terminal commands, and builds real, working software from plain-language descriptions, with your code staying as ordinary files on your own machine. You can start for free with the built-in model before topping up anything, or bring your own Claude or Codex if you already pay for one, and it runs on one of the world's lowest coding token costs — top up prepaid balance from $1, no subscription, nothing auto-renews.
👉 Download meshcode — Mac, Windows.