Jev 1.13: decision points in AI code review

Decision points in AI code review are small, specialized judgments: is this finding true, about new lines, matching a rule, and worth a human’s time. A fast yes/no or pick-one model can answer those cheaper than a chat or coding LLM. High confidence is not correctness. Application code still decides when to trust. The architecture bet is many clear questions, not one mega-model doing the whole review.

This is early. We wired a decision model (Jev 1.13, via TypeSafe / OpenRouter) into Revix for those judgment steps on the PR review path, not as another chat or coding model. Treat what follows as how-it-works architecture, not a finished claim that every team should copy tomorrow.

What are decision points in AI code review?

Decision points are discrete yes/no or pick-one judgments the review system asks at specific steps. Each question is narrow, answerable, and owned by application logic that decides what to do with the answer. They are not a free-form chat about the PR and not a request to rewrite the diff.

In practice a decision point looks like a tight prompt plus a constrained output. Examples: true or false; pick the best matching rule from a short list; score whether a comment deserves a human glance. The model is there to judge, not to narrate.

That split matters because PR review is a pipeline of jobs. Finding candidates, matching rules mined from the repo, ranking attention, and writing comments are different jobs. For category basics, see what is AI code review. For why review load grows when shipping accelerates, see more PRs, slower merges.

Why not one large LLM for the whole PR review?

One large LLM asked to find issues, assign severity, invent confidence, match team standards, and write the thread mixes incompatible jobs. The output often sounds fluent while the judgment underneath is mushy. Teams then mute the bot. Splitting those jobs into specialized decision points keeps each answer small enough for application code to trust, suppress, or escalate on purpose.

Specialized decision points keep each job small and checkable. A coding-oriented pass can propose candidate findings. A decision model can answer whether each candidate is true, scoped to new lines, tied to a rule, and worth attention. Application code applies thresholds. Humans still review architecture and product risk.

This is the same honesty we want on noise: useful comments matter more than comment volume. Decision points are one architecture move toward that useful/total bar.

What is a decision model good at (and bad at)?

A decision model is good at fast yes/no and pick-one answers when the question is clear. It is cheap and quick relative to long-form chat. It is bad at open conversation, essay-length critique, and replacing either the coding agent or human review.

Clear questions are the contract. If the prompt is vague, the judgment is vague. If the allowed answers are unconstrained prose, you are back to a chat model wearing a confidence costume. Design the question first. Then call the model. Then let application code decide trust.

On Revix we treat Jev 1.13 as that judgment layer on the review path. We do not ask it to author the PR or own the merge. Standards still come from rules mined from the repository and from humans editing those rules. For the tooling split between repo-derived and generic-diff review, see repo-aware vs diff-based AI code review.

Why high confidence is not the same as correct

High confidence is a model score, not a proof that the finding is right. Calibrated probabilities are useful for ranking and for thresholds. They are not a substitute for deciding when to suppress, post, or escalate. Application code must own that trust boundary, or authors learn to ignore every badge.

Critique findings on our path use calibrated probabilities rather than one vague confidence badge. That lets application code ask harder questions: how sure, relative to what, and what action follows. A 0.9 that the finding is “interesting” is not the same as a 0.9 that it is true on new lines against a specific rule.

If your bot collapses all of that into a single “high confidence” label, authors learn to ignore the label. Confidence theater trains mute the same way volume does.

How does Revix split review questions on the PR path?

We split the judgment into separate questions so one fuzzy score cannot hide four different failures. Each answer can gate posting, ranking, or suppression independently. Rules mined from the repo help identify which standards a diff breaks instead of hoping a single LLM notices.

That table is the product of wanting fewer ignore-on-sight comments, not of wanting more comments. Repo-derived standards give the “match the rule” question something real to check. Generic best-practice lists invent medium findings the team never enforced by hand.

Hosts today: GitHub, Bitbucket Cloud, and GitLab. The decision layer sits on the review path for those PRs. It does not replace Slack notifications, human threads, or your merge policy. For how review shows up in Slack without becoming another mute surface, see AI code review in Slack.

How do meaning-matched review threads protect signal?

Review threads matched by meaning keep related findings grouped so fixing one issue does not hide another. If comments are only matched by brittle string equality or by position that moved, a legitimate fix can erase a sibling problem that still matters.

Meaning match is a decision-shaped problem too: are these two findings the same concern, or two different ones that happen to sit near each other? Getting that wrong either duplicates noise or silently drops signal. We care about the second failure as much as the first.

This is still early. Matching by meaning is hard. The careful flag stays up. The goal is that resolving one thread does not accidentally bury a different rule break on the same diff.

What happens when the decision model fails or returns junk?

The review should still finish. Graceful degrade means an unavailable, empty, or nonsense decision answer does not abort the PR pass. You may lose ranking help or some filtering. You should not lose the review.

Decision points are helpers on the path, not a single point of failure. Application code owns timeouts, fallbacks, and what “junk” looks like. If the decision layer is down, authors and reviewers still get a completed review rather than a half-broken bot.

Junk handling also protects trust. A confident wrong answer that always posts is worse than a skipped judgment that stays quiet. Prefer suppress-and-continue over invent-and-ship when the decision output is unusable.

What does this architecture refuse to claim?

We refuse to claim that a decision model replaces the coding agent or human review. We refuse one mega-LLM owning find, score, match, and comment as if that were “smarter.” We refuse confidence badges that skip the split questions above.

The takeaway is architectural: smaller specialized decision points, clear questions, calibrated probabilities, meaning-matched threads, and graceful degrade. Still early. Measure useful comments on your own repos before you treat any vendor story as settled. If you are comparing tools by noise and fit, Greptile alternatives covers when recall-heavy review still floods the thread.

Revix mines the repository, autogenerates review rules from how the team already writes code, then reviews pull requests against those standards. Decision points sit on that path so judgments stay small and checkable. You edit the rules. You own what “acceptable” means.

If you want to see how that feels on a real PR, try a review on revix.ai.