Design AI code review engineers will trust: diff, data, cost

An engineer opens a pull request and sees an AI finding. Before acting, they need three answers: what changed, where their code goes, and what the run will cost.

• Show the diff evidence.
• State the data path.
• Cap the cost.

CodeRabbit secured $143M in funding for its software-change control layer. The raise points to the hard part: making software change safe enough for engineers to rely on daily, not simply getting model access.

More bugs found is not the metric that keeps a tool in the loop. A reviewer that shouts without receipts becomes noise.

The diff carries the proof

A finding that names the changed line, the affected path, and the failing case gives an engineer something to check. The diff is the smallest unit of trust in code review, and the claim is only as strong as the evidence attached.

A good review UI makes the model show its work. The finding should link to the exact hunk, name the risk, and suggest a check that would prove the claim. If the engineer has to reconstruct the context from memory, the finding is too weak to act on.

In CodeRabbit's evaluation, GPT-6 Astra identified roughly 4% more labeled bugs via developer-actionable findings than GPT-5.6 Sol, and roughly 22% more than Opus 5. For more difficult cross-file reviews, GPT-6 Astra's improvement reached 20% relative to GPT-5.6 Sol and 33% relative to Opus 5.

Those numbers show where a model earns attention; they do not replace the need for evidence. A percentage does not tell a developer which line to change, which test to run, or which assumption to challenge.

The strongest objection is that better models make trust automatic: if the model catches more, engineers will accept it. Evaluation can rank a model, but it cannot replace the product surface that makes the result inspectable. A designer should ask what the engineer sees first: a score, a summary, or the changed lines with a reason attached.

The data path is the privacy promise

Engineers do not send private code to a reviewer because the model is clever. They send it because the product promises a boundary. That boundary has to be visible, not buried in a legal page.

Neither CodeRabbit nor its model providers use customers' proprietary code or personal data from private code reviews to train AI models. OpenAI and Anthropic follow different data-retention policies, and CodeRabbit permits only models that meet its data-protection requirements for customer reviews.

Make that chain legible: where the diff goes, which provider sees it, how long it is retained, and whether it can be used for training. The promise should be part of the workflow, not a hidden footnote. When a private repository is connected, the UI can show the provider, the retention window, and the training exclusion in the same place where the review starts. If a model changes, the data path changes too; say so in the review UI.

The cost ceiling is the budget control

AI trust also lives in the invoice. A model that improves findings can still be the wrong default when the bill scales with every pull request. Cost control means a visible budget per review and a hard stop before the model spends the team's money.

A cap should be visible before the review starts, not discovered in finance after the fact. The interface can show estimated tokens, estimated spend, and the ceiling that will stop the run. If the estimate crosses the ceiling, pause and ask for a human decision.

Astra's listed standard API price is $10 per million input tokens and $50 per million output tokens. Using a fixed illustrative workload of 100,000 uncached input tokens and 10,000 billable output tokens, Astra's cost was 2.5 times Sol, about 4.7 times Terra, and about 47 times Luna. The spread is the price of choosing a stronger model. A team that cannot predict it will not let the model run unattended.