How MergeHarbor reviews a pull request

Most automated review tools see what you see in the diff: the lines that changed and a few lines around them. That is enough to catch a typo or a style violation. It is not enough to notice that the function you changed is called from three other services, one of which now receives a value it does not handle.

MergeHarbor is built on a different premise: a useful reviewer has to investigate before it comments, and it has to check its own conclusions before it interrupts an engineer. This post walks through what happens when a pull request is opened.

Before the pull request: an index of the codebase

When you connect a repository, MergeHarbor builds three structures and keeps them current with every push:

• A code graph. Files, functions, classes, and the call relationships between them, extracted with language-aware parsers for Go, Python, JavaScript, TypeScript, Java, Rust, Ruby, C#, C, and C++.
• A semantic index. Code is split into meaningful chunks, and each file also gets a short plain-language summary. Searching descriptions of code finds the right place far more reliably than searching raw code alone.
• A text-search index, so exact-match searches stay fast even on repositories with millions of files.

Everything is keyed by the content of each file, not its path. After the first pass, a push only processes the files that changed, and moving or duplicating a file costs nothing.

The pull request arrives

A webhook from your code host is verified and checked against your organization’s settings: is this event a trigger, is the author excluded, is it a draft? If a review should run, it is queued for the worker that holds the repository’s mirror. Rapid successive pushes are coalesced, so a burst of commits produces one review, not five.

The worker computes the diff locally and reads your team’s guidance — .mergeharbor.yml, CLAUDE.md, AGENTS.md, Cursor rules, and the rules your team has taught MergeHarbor — from the merge base, not from the pull request. A pull request cannot change the instructions it is reviewed under.

Before anything is sent to a model, secrets are removed: API keys, tokens, private keys, and credentials in connection strings are replaced with placeholders.

The investigation

The reviewer is an agent with tools that read your codebase:

• read any file at the pull request’s head,
• search by meaning or by exact text,
• find where a symbol is defined, who calls it, and what it calls,
• read recent history of a file.

The pull request’s own new code is visible to these tools alongside the indexed codebase, so a function introduced in the change can be traced just like an existing one.

The agent decides what to read. For a change to a payment handler, it might look up every caller of the modified function, compare the error handling with similar handlers in the same package, and check whether a recent commit changed the transaction boundaries. Findings carry that evidence: not “this might be a problem”, but “these three callers retry on error, and the balance update now runs after the commit”.

Very large pull requests are reviewed in parts, grouped by directory, and combined into a single summary and score.

Verification

Language models are confident even when they are wrong. A reviewer that posts every plausible concern trains engineers to ignore it.

So every finding goes through a second, independent pass whose only job is to disprove it. The verifier has the same tools and reads the code again. Findings it refutes are dropped. Findings it cannot settle are kept with reduced confidence. Then your settings apply: minimum severity, minimum confidence, ignored paths, and the maximum number of inline comments.

Comments that closely resemble ones your team previously rejected are suppressed as well.

What you see

On the pull request:

• a summary of the change with a confidence score from 1 to 5,
• inline comments on the exact lines, each with severity, category, confidence, a suggested change where one applies, and a prompt you can hand to a coding agent,
• a status check that can gate merging on the score or on critical findings.

When you push again, MergeHarbor reviews the new commits, carries forward earlier findings that still apply, and marks fixed ones as addressed.

Learning

Engineers react to comments and reply in the conversation. MergeHarbor turns consistent patterns in that feedback into proposed rules — with the evidence — that an administrator approves before they take effect. Rules taught directly with @mergeharbor remember apply on the next review.

Over time, reviews converge on what your team actually cares about, and stop raising what it does not.

Why this design

Each part exists to protect one thing: the engineer’s attention. Investigation produces findings worth reading. Verification keeps out the ones that are not. Learning removes the categories your team has decided are noise. A reviewer that respects attention is one that gets read — and a review that gets read is the only kind that prevents bugs.