Every AI code review tool I test ends the same way: it prints a hard label. approve, request changes, block, a severity from 0 to 5. The team reads the label, and the label becomes the ground truth people argue about in the PR comments. Nobody questions the probability mass behind it.
There is a real problem hiding in that flow. When you ask an LLM for its confidence in its own review, the number is not calibrated. "High confidence" on a security finding means roughly nothing, because nothing in the model's training taught it to map its internal uncertainty onto the 1-100 scale it prints. Ask a code review model how sure it is that this is an auth bypass, and it will cheerfully say 0.98 whether it caught a real one or hallucinated a method call that doesn't exist. I have watched the same class of bug get flagged as "critical" on one run and "looks fine" on another run of the same model with a slightly different prompt.
There's a useful way to think about this that maps directly onto code review: treat the LLM verdict as a feature, not as the answer.
The hard-label trap
The core problem is a mismatch. A code review tool is, functionally, a classifier: for every finding it emits a label and a severity. But an LLM is not built as a classifier. Nothing about its training objective gives it a calibrated probability that a finding is real. It is trained to produce plausible text, and an uncalibrated confidence score is plausible text too.
A post that spells this out clearly is LLM Classification Is Feature Engineering. The author walks through what you cannot get from a raw LLM verdict: trustworthy probabilities, threshold control to trade precision against recall, and any mechanism to know whether the model actually used the context you pasted into the prompt. The verdicts are hard labels, and hard labels hide the uncertainty that a review triage process depends on.
This is not an exotic corner of ML theory. It is the difference between "this tool flagged a finding" and "this finding is real." Your reviewers cannot act until they make the second judgment, and the tool is handing you the first one dressed up as the second.
Wrap the verdict, don't trust it
The fix the post proposes is elegant: stop treating the LLM as the final classifier and use its verdict as an input feature to a small model you fit on your own data. Concretely:
p(real problem in this file) = sigmoid(alpha + beta * LLM_verdict)
The special case where beta goes to infinity just recovers the raw LLM verdict, which is the thing you are already doing and the thing that is unreliable. The whole point is to estimate beta from your own history, on your own repo, against your own ground truth, and then choose an operating threshold that matches how your team actually triages.
What this buys in a code-review context:
Per-severity calibration. Most tools collapse everything into one label. If you keep a few features instead, one for the security findings, one for the style noise, one for the "this will break the build" cluster, you learn that your tool's style findings are right 40% of the time and its security findings are right 80%. Now you know to ignore the first category outright and act on the second.
Your baseline is not the model's prior. A model ranks findings against the distribution of code it saw in training, which is not your codebase. Your codebase may have a burst of rare auth bugs or a noisy style history. A logistic regression fit to your own merges and reverts adapts to your baseline instead of the model's baked-in guess about what normal code looks like.
You get a real trade-off dial. Right now you either trust every red flag or train the team to tune all of them out. With calibrated probabilities you can say we action findings above 0.8 and log the rest, and measure after two weeks whether that cut was right. That is a default your reviewers can defend, instead of vibes.
Why this matters more as AI code grows
The volume angle is what makes this urgent. A survey of test-driven and evaluation-guided workflows for LLMs in software engineering describes the loop teams are converging on: generate, verify by execution, refine. As code generation makes it cheaper to produce more code, the review and verification step becomes the bottleneck, not the writing. Productivity research in the AI-era software development metrics literature makes the same point from the other side: proxies like lines of code or commits can keep rising while end-to-end delivery is still constrained by review throughput and architecture fit. Generating more code only matters if you can separate the good from the bad at speed, and an uncalibrated label does not let you do that at speed.
This is also the argument I keep coming back to across my own testing. The model that wrote the code should not be the one reviewing it, because that is one opinion measured N times. The model that reviews it should not decide unilaterally either. Its verdict is a signal your team should condition on, alongside the test failure, the author's explanation, and the file's history. I made the self-review version of this case before in why you shouldn't let the model review its own AI code.
A concrete starting point
You do not need a data science team to get started. Keep the review history from your last few months: the finding text, the model's label, and whether the human reviewer ultimately agreed. That last column is your label. Fit a three-variable logistic regression with the LLM's verdict, the finding category, and the file touch count. Most review tools can export this, or you can collect it from your own merge history.
Then pick a threshold and see where you are. The output is not a magical review tool. It is a review tool whose confidence you actually trust, because you measured it on the code you actually ship. That is the whole difference between a feature and a verdict.
