The AI-rejection rate is the share of AI-generated suggestions an engineer refuses during a paired session, scored against the suggestions they could have accepted. It is a measurement of judgment expressed as action. A high rate is not stubbornness, and a low rate is not collaboration. The number means something specific, and the meaning is the most useful single signal we have for senior engineering practice in 2026.
How is it calculated, exactly?
The formula is straightforward. Over a paired session of fixed duration:
ai_rejection_rate = rejected / (rejected + accepted)
Where rejected is the count of AI suggestions the engineer explicitly declined or replaced, and accepted is the count of suggestions the engineer either kept verbatim or kept with light edits. Suggestions that were auto-dismissed before the engineer evaluated them — because they timed out, or because the engineer was typing past them — do not count in either numerator or denominator. They were not refused; they were not seen.
The denominator is the part most people get wrong. The instinct is to divide rejections by total suggestions surfaced. That over-counts because surfaced suggestions include the ones the engineer never read. The honest denominator is "suggestions the engineer evaluated," which is rejections plus acceptances. The metric measures judgment under attention, not exposure.
The session window matters. We use a 90-minute paired-session window because shorter windows produce noisy rates and longer windows mix in fatigue effects. The metric is reported per session and rolled up to a 30-day trailing average. The trailing average is what reviewers see; the per-session number is what engineers use to calibrate themselves week to week.
Why does it correlate with seniority?
Acceptance is cheap. Acceptance can be done without understanding. The model proposes, the engineer presses tab, and the line enters the codebase. Rejection is expensive in a specific way — to reject a suggestion, the engineer has to know what they would have written instead, and they have to know it well enough to weigh it against what was offered. The cognitive act of rejecting is the cognitive act of holding the alternative. That is the part of engineering judgment that does not arrive for free with a better model.
This is why the correlation with downstream regression rate is so strong. Engineers who reject at a higher rate are engineers who maintain a live model of the code, the constraints, and the alternatives in working memory throughout the session. Engineers who accept without rejecting are, in aggregate, engineers who are losing that model. The regression rate downstream is the cost of having lost it. The correlation does not say that rejecting causes lower regressions; it says that the engineers who reject are the engineers who have the working-memory habits that produce fewer regressions. The metric is a proxy for the habit.
The radar above puts the gap in context. AI-rejection sense — the rubric dimension that scores rejection behaviour — shows the widest spread between top-decile and bottom-tercile engineers. The next-widest is defensibility, which is closely related: rejecting a suggestion and being able to explain the rejection are the same skill under two different time horizons.
What's a good rejection rate to aim for?
The honest answer is that no single number is correct. The right rate depends on the task category, the model, the engineer's experience with the codebase, and the engineer's stylistic relationship with the tool. We publish the band table as a calibration aid, not a prescription. An engineer in the 45–55% band is not better than an engineer in the 35–45% band; they have a different working pattern. The bands below 25% and above 65% are the bands we worry about, for different reasons.
| Rejection rate | Band label | What it usually means |
|---|---|---|
| Below 15% | Acceptance-heavy | Likely accepting without evaluation. Yellow flag in any senior context. |
| 15–25% | Light filter | Filters obvious mistakes; not yet weighing alternatives consistently. |
| 25–35% | Working filter | Healthy for mid-level engineers in familiar codebases. |
| 35–45% | Cohort median | The middle of senior practice. Reflects active alternative-holding. |
| 45–55% | Top decile | Active selection. Common in engineers with strong taste and clear constraints. |
| 55–65% | High-rejection | Common in security or refactor work; uncommon in greenfield. |
| Above 65% | Refusal-heavy | Yellow flag in the other direction. Often aesthetic rather than functional. |
The most important thing to read from the table is that both ends are flagged. Below 15% looks like overuse; above 65% looks like underuse, but of a different kind — the engineer is treating the model as a sparring partner rather than a collaborator. Neither pattern produces the best outcomes. The middle is wide, and the wide middle is the point.
Where the metric breaks down
The metric has three known failure modes, and we publish them rather than hide them.
The first is the autocomplete failure. Autocomplete-style single-token or single-line suggestions are evaluated in milliseconds, and the engineer's accept-or-reject decision is more reflex than judgment. Counting those in the rate dilutes the signal toward noise. We exclude them by default and report a separate "long-suggestion rejection rate" for suggestions longer than four lines, which is the version that actually correlates with seniority.
The second is the habit-rejector. Some engineers reject every suggestion as a stylistic posture, then write something close to what the model proposed. This pattern produces a high rejection rate without the judgment the rate is supposed to measure. We catch this through the audio defence — habit-rejectors cannot explain the discriminating criterion for any specific rejection, because they did not actually have one. The rubric scores "named rejection reason" separately from rejection rate, which is the structural protection against this failure.
The third is the aesthetic-rejector. Some engineers reject for code style — naming, formatting, function decomposition — rather than functional correctness. Aesthetic rejection is not worthless, but it is less predictive of regression rate than functional rejection. We do not currently weight them differently in the headline rate, and that is a known limitation. The 2027 rubric refresh will likely split them.
The metric is a proxy for a habit. Treat it as a proxy. If you optimise for the number, you will get the number; the habit is what we wanted, and the habit is what regresses fewer commits next quarter.
How do you measure it on yourself?
You do not need our platform to start. The metric is a counting exercise, and a notebook works fine for the first month. Once you have a baseline you can move it deliberately — the act of writing the rejection down is the act of forcing yourself to know why you rejected, and the why is the part that improves.
How to
Pick a window
Choose three 90-minute paired sessions over the week. The same sessions you would have done anyway; do not perform.
Count long suggestions only
For each session, ignore single-line autocompletes. Tally suggestions longer than four lines: how many you saw, how many you accepted, how many you rejected.
Compute and reflect
Divide rejections by (rejections + acceptances). Note the number. Then read your rejection log and ask: could you name the discriminating criterion for each rejection? If not, the habit is what to work on, not the rate.
The reflection step is the one engineers skip and the one that matters. The rate itself is a thermometer; the named criterion is the muscle. We see engineers move from a 22% rate to a 36% rate inside a quarter once they begin annotating every rejection with a one-sentence reason, because the annotation forces the habit the rate is proxy for.
The full defensibility rubric including the AI-rejection sense dimension, its anchors, and the weight evolution from v2.4 to v2.6.
From Codritium Research
The Defensibility Rubric, 2026
The public scoring rubric behind every Codritium benchmark and certification: six weighted dimensions, twelve task categories, inter-rater agreement, and a frozen reference quarter.
Common questions
Is rejection the same as deletion?
No. Rejection is declining a suggestion before it enters the editor or replacing it immediately. Deletion is removing a line that was accepted earlier in the session. We count both but track them separately. Deletions correlate with regression rate, but less strongly than rejections, because by the time the engineer deletes the line they have already paid some of the cognitive cost of accepting it.
Does the metric punish accepting good suggestions?
No, because a good suggestion accepted is in the denominator, not the numerator. The metric measures share, not count. An engineer who saw 30 long suggestions, accepted 18 and rejected 12 has a 40% rejection rate; an engineer who saw 6 and rejected 2 has a 33% rejection rate. Both numbers are healthy. The metric does not reward refusing for its own sake.
Can the AI itself influence the score?
Yes, and we account for it. A more accurate model surfaces fewer obviously-wrong suggestions, which mechanically lowers the rejection rate without changing engineer behaviour. We control for this by reporting rates against a fixed model baseline per session category. The trailing 30-day number on an engineer's profile is normalised; the raw per-session number is not.
Does the metric apply to autocomplete?
Not in the headline number. Autocomplete-style suggestions under four lines are excluded by default because the accept-or-reject decision is reflex rather than judgment. We track a separate 'short-suggestion engagement rate' for autocomplete behaviour, but it does not enter the rubric. The rubric only sees the long-suggestion rate.
Is rejection rate culture-dependent?
Somewhat. We see modest regional differences — engineers in some markets reject at a slightly higher base rate, independent of skill. We adjust for the regional baseline when comparing across cohorts. The within-cohort distribution still produces the same band shape: a wide middle, a flagged low tail, and a smaller flagged high tail. The culture effect shifts the bands; it does not change the shape.
Where to go next
- The rubric this metric lives inside: The defensibility rubric, 2026
- The platform challenges that measure it: Codritium challenges
- The companion piece on the skill the metric proxies: Defensibility, the engineering skill AI can't replace