How Eblan reviews your code

Since we opened the private beta, the question we get most often — from users and from curious engineers — is some version of "what's actually happening when Eblan reviews my PR?" This post is the honest answer.

It starts with the diff, but it doesn't end there

A diff on its own is a terrible thing to review. It shows you what changed, but not around what. A two-line change to a function signature can ripple through a dozen call sites; a "simple" retry loop can double-charge a customer if idempotency is handled three files away.

So when a PR opens, Eblan collects three layers of context:

1. The changeset itself — every commit, every file, with the full diff rather than a truncated fragment.
2. The surrounding code — the complete files that were touched, plus the definitions and call sites the change interacts with.
3. Your conventions — contribution docs, similar past PRs and their review threads, so feedback matches how your team already talks.

This is where modern long-context models changed the game. Fitting a whole changeset plus meaningful surrounding code into a single prompt simply wasn't practical until recently.

Why Claude

We benchmarked several frontier models against each other on hundreds of real pull requests — some clean, some with bugs we'd planted, some with bugs we didn't know about yet. Claude won for two reasons that mattered more than raw benchmark scores:

It reasons about behavior, not syntax. The failure mode of weaker models is pattern-matching: flagging anything that looks like a known anti-pattern. Claude traces what the code actually does — where the value comes from, what happens when it's missing, what the caller expects back. That's the difference between "consider adding error handling here" and "this retry can double-charge, and here's the exact interleaving."

It knows when to shut up. The fastest way to make a developer mute a review bot is noise. Claude's judgment about confidence is good enough that we can enforce a strict bar: if a comment wouldn't survive a senior engineer's "so what?", it doesn't get posted. Today, roughly a third of Eblan's comments flag an issue a human confirmed as real — and the rest are, on the whole, things humans were glad someone said.

Keeping the latency budget

A review that arrives tomorrow is a history lesson. We hold ourselves to a median time-to-first-comment of two minutes, which shapes the pipeline: context gathering runs in parallel with the first review pass, trivial diffs take a fast path, and we stream structured findings as they're ready instead of waiting for a monolithic response.

The result: today the median first comment lands in 94 seconds, and a full review of a large PR rarely takes more than four minutes.

Structured, ranked, and honest

Claude returns findings in a structured form — location, severity, explanation, and a suggested fix where one exists. We rank them, cap the count per PR, and attach one-click suggestions wherever we can. When Eblan finds nothing worth saying, it says so: an approval with a short summary, not a forced list of compliments.

And to be clear about the boundary: your code is sent to the Claude API for analysis and never used to train models. Eblan stores lightweight PR metadata — nothing else.

What's next

We're working on deeper monorepo awareness, review analytics for team leads, and a self-serve onboarding flow. If you want to kick the tires, join the waitlist — and if you're the kind of engineer who reads blog posts about review pipelines, we'd especially love your feedback.

— The Eblan team