Does a high AI acceptance rate mean trust is calibrated?

← Back to Blog

“Trust guides reliance when complexity and unanticipated situations make a complete understanding of the automation impractical.”

Lee & See (2004)

In an enterprise survey of 57 developers using AI coding assistants, manual testing and code-execution behavior declined as assistant use rose (Vukovic et al., 2026) (Emerging: single study, self-report, small sample). That finding reads easily as a productivity win. It is also what declining scrutiny looks like from the outside.

Picture two teams running the same assistant, both reporting a 48% acceptance rate on the quarterly dashboard. The first reads each suggestion, runs it, and rejects slightly more than half for reasons its engineers can state out loud. The second accepts whatever looks plausible and rejects whatever breaks the build. Identical number. Opposite epistemic states. The dashboard cannot tell them apart, and neither can the executive reading it.

My argument: acceptance rate cannot distinguish calibrated judgment from compliance, so a trust architecture has to measure what happens at the override and during verification, not how often a suggestion gets taken.

The Research

Appropriate reliance is a relationship between trust and actual system reliability, not a level of agreement (Lee & See, 2004) (Established: the originating model, extended rather than replaced by later work). A team accepting 90% of suggestions from a system that is right 90% of the time may be perfectly calibrated. The same team accepting 90% from a system right 60% of the time is not. Acceptance rate alone cannot tell you which case you are in. Reliability is the missing variable.

Automation complacency shows up first as reduced monitoring and verification, well before any outcome failure surfaces (Parasuraman & Manzey, 2010) (Established: integrative review across decades of automated-work research). That is why I treat verification telemetry as the leading indicator and acceptance rate as the lagging one. By the time acceptance climbs and defect rates follow, the attentional shift happened months earlier. Holland et al. (2024) add a sharper distinction from decision science: reliance and dependence behaviors diverge from stated trust as reliability varies (Emerging). People will tell you they are skeptical while behaving dependently, which rules out survey-based trust measurement as a substitute.

Trust Architecture is the deliberate design of transparency, feedback loops, and calibration mechanisms that support appropriate reliance. The measurement failure here is specific and diagnosable. Guerdan et al. (2023) give a causal framework for when a proxy stops tracking the construct it is assumed to measure (Emerging); acceptance rate is a textbook case, standing in for calibration while measuring throughput. The interface decides whether calibration is possible at all. Zhang et al. (2020) found that surfacing model confidence changed trust calibration in AI-assisted decisions, though explanation alone did not reliably improve accuracy (Emerging). A bare accept-or-reject control gives a user nothing to calibrate against.

What This Means in Practice

Instrument the override, not just the accept. The minimum version is a reason code on each rejection, with four or five options drawn from your system's actual failure modes: wrong API, hallucinated dependency, correct but off-style, correct but wrong context, unverifiable. The distribution of those codes over time is a calibration signal. A team whose override reasons cluster on real defect categories is reading the output. A team whose overrides are mostly "didn't compile" is letting the toolchain do the thinking.

Then watch verification frequency as its own series. Test executions per accepted suggestion, local runs before commit, time between suggestion and commit. Vukovic et al. (2026) found these behaviors moving with assistant use in an enterprise setting (Emerging). A falling ratio of verification events to accepted suggestions is the earliest organizational signal available, and it is cheap to collect from tooling you already run.

Resist the target. Mozannar et al. (2024b), working from 535 programmers and roughly 168,000 suggestions, argue that acceptance rate degrades as an optimization target once teams manage to it (Emerging, large behavioral dataset). Set a quota on acceptance and you will get acceptance.

Three Things to Take Away

Pair every acceptance dashboard with an override log

Without override reasons, acceptance rate reports compliance. Appropriate reliance depends on the match between trust and reliability, which a single agreement number cannot express (Lee & See, 2004) (Established). The override log is where judgment leaves a trace.

Track verification activity, not just acceptance

Reduced monitoring precedes outcome failure in automated work (Parasuraman & Manzey, 2010) (Established). Manual testing and execution frequency moved with assistant adoption in enterprise developer data (Vukovic et al., 2026) (Emerging). Falling verification is an earlier warning than any acceptance figure.

Treat vendor acceptance figures as a reason for skepticism, not a benchmark

Practitioner syntheses this year place enterprise acceptance well below vendor-promoted figures above 80% (Baeseokjae, 2026) (Emerging, non-peer-reviewed). Before setting an internal target, ask what the number would mean if you hit it. Optimizing it makes it less informative (Mozannar et al., 2024b) (Emerging).

My Two Cents

Acceptance rate survives because it is easy to collect and flattering to report. It is a throughput metric wearing a judgment metric's clothes, and the organizations most pleased with their numbers are the ones I would want to audit first. Given a choice, I would take a team at 30% acceptance with a detailed override taxonomy over a team at 70% with nothing but the percentage. Only the first team has built the feedback loop that keeps reliance matched to reliability as the model, the codebase, and the task mix shift underneath them.

Calibration is not a state you reach at rollout. It decays whenever the system's reliability changes and nobody notices. Measuring the override is how an organization keeps noticing.

Read to Learn More

Reading between the lines: Modeling user behavior and costs in AI-assisted programming (Mozannar et al., 2024a). Builds a behavioral model of what programmers actually do with suggestions, including the time cost of verifying them, which is the activity acceptance rate renders invisible.

Your AI coding dashboard counts the wrong thing (The Cloud Codex, 2026). A practitioner argument for replacing acceptance metrics with downstream signals; useful as a translation of the measurement critique into dashboard design.

References