Review as the Control Point

Sources#

• 3100 Opinions on Code Review in an AI World: Building Causal Theory from Practitioner Discourse
• Characterizing the Quality Profile of AI-Generated C++ in Production
• developer responses agent review comments
• Prompting Claude Opus 5

Summary#

Agarwal, Miller, Kästner & Vasilescu (Carnegie Mellon, arXiv 2607.07980, July 2026) synthesize practitioner discourse at scale into an explanatory causal theory of how coding agents reshape code review: 26 constructs and 67 relationships (64 directed, 3 contested), built from 3,100 coded grey-literature documents. Its organizing claim: review is the control point through which a coding agent's effect on software is decided, and AI does not fix the sign of that effect — the team does, through the expertise its reviewers bring and how it adapts the review process. "AI is changing code review" is turned into falsifiable propositions with named constructs and moderators.

The paper is the vault's first non-vendor, mechanism-level account of AI's effect on review dynamics, and a direct foil to Faros's vendor telemetry (see the contradiction below).

Evidence note. empirical, with a load-bearing distinction. The theory is a proposed explanatory theory grounded in what practitioners argue, filtered through the researchers — "we confirm none of these relationships." Its constructs and edges are hypotheses to test, not measured effects; treat P1–P17 as falsifiable claims, not findings. The genuinely measured part is a motivating observational GitHub study (2.5M+ PRs across 2,860 agent-exposed public repos) — real telemetry, but the authors' headline is that it is direction-unstable under defensible analysis choices. So this page does not out-measure Faros on quality outcomes (it measures none); what it adds is non-vendor over-time telemetry and a rigorous argument that surface trends can't be read without a causal model.

The three moderators (the paper's punchline)#

The core claim is that agents don't monotonically help or harm review; they pressure the review system without fixing any single outcome, and three moderators set which way it breaks:

1. Reviewer expertise and disposition — the skill a reviewer brings and whether they read AI code with a trusting or a skeptical frame.
2. Automated-reviewer capability — how good the AI reviewer folded into the loop actually is.
3. Process adaptation — the review governance policy the team adopts in response.

This is the review-side mirror of Returns to Expertise in Agentic Coding: what amplifies (or protects against) a coding agent is the human's understanding and the team's practices, not the technology.

The shape of the theory: drivers → review dynamics → outcomes#

The theory (Figure 2) reads top-to-bottom. Node shape encodes role, edge style encodes sign (solid = increases, dashed = decreases, bold = contested, sign set by a moderator):

• Drivers (exogenous properties of agent code, rectangles): increased volume & velocity of code production ("reviewer throughput grows linearly with headcount; AI generation grows multiplicatively per developer"), surface plausibility (reads clean and idiomatic), code opacity / lost intent (no human formed the rationale), output inconsistency (run-to-run variance), and data & IP exposure risk.
• Review dynamics (the steerable middle, ellipses): skepticism, use of automated review & gating, review governance policy, review budget, focus on high-level intent, review depth, comprehension debt, reviewer skill & experience, coding skill, collective ownership, review effectiveness, review efficiency, review motivation.
• Outcomes (what practitioners care about, hexagons): code quality, code security, review throughput, review latency, maintainability, knowledge transfer & mentorship.

The central core is review depth + reviewer skill — the busiest constructs, through which surface plausibility, ownership, and coding skill reach throughput and quality. The core feeds back on itself (see the loops below).

The key mechanisms (falsifiable propositions)#

• Volume → shallower review or burnout. Higher review load decreases review depth (P1: skimming not reading — "reviewing 200 AI-generated PRs a sprint… they're skimming, not reading") and decreases review motivation (P2), and shifting relative time toward reviewing further demotivates (P3: "after a few hours reading AI code, I'm more drained than after twice as long writing it"). The endpoint practitioners fear: review becomes "shallow or abandoned… performative."
• Surface plausibility disarms the reviewer. Polish lowers the reviewer's guard (P4: "polish can lower the reviewer's guard"; "seniors rubber-stamping code that looks idiomatic but hides subtle bugs") — a defect "dressed as correct code" clears faster because it's scrutinized less. This is Polish No Longer Signals Readiness at the review layer.
• Skepticism is the mirror. Treating AI code as suspect — "like a junior dev who's super confident but only moderately competent, I read every line like it's a puzzle" — raises depth and effectiveness, lowers efficiency (P5), and can compensate for surface plausibility; it's fed by awareness of output inconsistency (P6).
• Opacity degrades review three ways (P7): reconstructing intent lowers efficiency, the missing yardstick lowers effectiveness even at full effort, and the drudgery lowers motivation.
• Automated review: throughput yes, quality contested. Full automation raises combined throughput and cuts latency (P8), but its effect on code quality/security is genuinely contested (P9) — one camp cites CodeRabbit catching ~82% of planted bugs; the other says it "catches style, misses the race-condition-under-load kind of problems" and manufactures false confidence.
• The comprehension trap (P10/P11). AI-assisted review climbs the abstraction ladder ("you are no longer reading every line, you are now an auditor") and raises reviewer skill — but focusing on high-level intent accrues comprehension debt even when review depth is high: "we are not reviewing the recipe, we are tasting the dish."
• Governance policy (P16/P17). A policy that mandates a careful pass raises depth (effectiveness up, efficiency down); its effect on latency is contested and set by calibration — a risk-tiered policy that gates only material changes lowers latency, a blanket policy that gates everything raises it.

The feedback loops (the under-attended human costs)#

The paper's structural contribution is showing that the core loops back on itself, so decisions that buy throughput today erode the capacity for good review tomorrow:

• Low review depth limits growth in reviewer skill (P12) and, compounded by less time coding + low-quality reviews received, undermines the coding skill that review skill is downstream of (P13) — "how can you review what you don't yet know how to build?"
• Review depth builds collective ownership and knowledge transfer; automated review undercuts both by lowering depth and by shortcutting the human arrangement that carried them (P14) — "when no human has deeply reviewed the logic, nobody owns it."
• Low depth + opacity increase comprehension debt, which erodes maintainability, ownership, knowledge transfer, and future review skill (P15) — "if you're merging PRs you don't fully understand, the bus factor climbs to dangerous levels."

Whether the loop turns virtuous (skepticism → deeper review → sharper reviewers) or vicious (rubber-stamping → skill atrophy → still shallower review) depends on many interacting decisions — the paper frames this as a system-dynamics question, not a monocausal one.

The observational study: real telemetry, unstable trends#

The theory grew out of the authors' failure to interpret their own GitHub data. Re-scraping full PR histories (Jan 2020–Feb 2026) for 2,860 agent-exposed repos from the Agents in the Wild corpus, they found agent-authored PRs are, at a point in time, reviewed less independently (author-only review 40.1% vs 21.5% for human PRs; paired Wilcoxon p<0.001), merged several times faster (median minutes-to-hours vs hours), and discussed less (50.2% get no review comments vs 37.9%; thinner even per line changed). This matches prior snapshot studies.

But two things break the easy reading:

1. The no-review rate converges, not diverges. The share of merged agent PRs receiving no human review falls from >50% in mid-2025 toward the stable human baseline of ~14% by early 2026 — an initial willingness to merge agent output unchecked gives way to reviewing it much as human PRs are reviewed. (This runs opposite to Yu et al.'s within-reviewer habituation, where oversight weakens over time — so studies disagree even on the basic direction of whether oversight is consolidating or eroding.)
2. The sign flips with a definitional choice. Whether "independent review" of agent PRs is above or below the human rate depends on whether you count the developer who invoked the agent as an independent reviewer (agent-as-author) or as the author reviewing their own work (agent-as-tool). Same data, opposite conclusion. Figures 5 and 6 support different headlines from the same rows.

The lesson (Pearl: "data are profoundly dumb"): surface traces establish what is changing, not why, and can't be read without a theory of what review is for.

Contradiction: this paper vs. Faros's Acceleration Whiplash#

Faros 2026 (vendor-claim) argues the throughput/quality gap widens with adoption and hits even high-maturity orgs ("even the strongest foundations are buckling"; 31.3% of PRs merged with no review is "the most urgent finding"), i.e., AI's downstream damage has a roughly fixed, worsening sign. This paper tensions that on two axes:

• Direction over time. Faros reads under-review as a deepening crisis; this paper's non-vendor GitHub telemetry finds the agent no-review rate converging down toward the human baseline as orgs learn to review agent code. Caveat both ways: different populations (open-source GitHub here vs Faros's largely-enterprise telemetry), different metric (coverage over calendar time vs adoption-depth cross-section), and this study is observational with no non-adopter control.
• Is the sign fixed? Faros's framing is deterministic ("maturity doesn't protect"); this paper's whole thesis is that AI does not fix the sign — the team's expertise and process do, which is closer to DORA's "strong foundations protect you" than to Faros. But it doesn't measure a maturity effect; it argues the moderators exist, grounded in discourse.

Weighting: neither out-measures the other on quality outcomes (this paper measures none; Faros's are genuine but vendor-selected telemetry). The durable takeaways are (a) non-vendor evidence that under-review of agent code is a transient early-adoption phase, not a widening gap, at least in open source, and (b) a well-argued case that Faros's fixed-sign framing skips the moderators that decide the outcome. A full reconciliation — the "divergence" dissolves into four axes of non-comparability (delta-in-count vs level-of-share, enterprise vs open source, adoption-depth cross-section vs calendar trend, all-PRs vs agent-PRs), leaving only the volume forecast genuinely contested — is filed at The Under-Review Divergence: Faros's Widening Crisis vs. CMU's Convergence.

Put the threshold in the filter, not the detector#

Anthropic's Opus 5 prompting guide (July 2026, vendor-claim) contributes one durable design rule to this page and one contested claim.

The rule. "If your review prompt says 'only report high-severity issues' or 'be conservative,' the model may follow that instruction literally and report less; ask it to report everything and filter in a separate pass instead." A severity threshold written into the review prompt does not raise the bar on reporting — it lowers detection, and the findings it suppresses are unrecoverable because they were never produced. Separating detection from filtering keeps review depth from being silently set by a prompt line, which makes it a process-adaptation decision in the theory's third-moderator sense rather than a phrasing preference. The general mechanism is Instruction Compounding.

The same section supplies a review-budget knob: accuracy reportedly "holds at lower effort settings, which supports a fast pass at review time and a more thorough pass later" — a two-tier allocation rather than one global setting (Large-Scale Test-Time Compute).

The contested claim. Anthropic states Opus 5 "reviews code with high precision and recall… its additional findings are mostly real issues rather than false positives." That is precisely the edge the theory marks as genuinely contested (P9, automated review → quality/security), where the sceptical camp holds that automated reviewers catch style, miss "the race-condition-under-load kind of problems," and manufacture false confidence. It is a first-party claim about a first-party product with no published measurement, so it does not settle P9 in either direction — the vault records it as the vendor's position, not as evidence. Note also what it is silent on: precision and recall per pass say nothing about whether human review depth (P1) or reviewer skill growth (P12) survive when the machine finds most of the bugs.

A production null: the load hypothesis tested, and not found (2026-08)#

Tran et al. (Google, arXiv 2608.06640) is the first source in the corpus to run one of this theory's core mechanisms against production data at scale, and it comes back empty. On 3.52M submitted changes across a year, the authors tested whether standard review metrics — prolonged review time, higher iteration counts — correlate with the survival of inefficient AI-generated C++ into the submitted snapshot, explicitly hypothesizing reviewer fatigue or over-trust. Their result: no clear correlation.

Two readings, and the paper takes the second:

• The weak reading is instrument failure — "conventional proxy metrics for human effort do not adequately capture the cognitive friction of evaluating AI-generated code." Review time and iteration count are the wrong measurement of review depth, so a real P1 effect could hide behind them. That does not rescue P1; it says the two most available operationalizations of it are unusable.
• The strong reading, which is theirs: "human reviewers struggle to consistently intercept these localized inefficiencies regardless of review depth," therefore upstream automated intervention is necessary rather than merely cheaper.

The strong reading is a real constraint on this page's organizing claim. Review is the control point through which a coding agent's effect is decided — but only for the defect classes review can see. A missing move constructor or an unnecessary explicit loop in a correct, idiomatic function is not a thing more attention reliably finds, and the constructs this theory would reach for (depth, skepticism, expertise) have no purchase on it. The control point is class-dependent, and the paper's own remedy for its class is the same one Faros prescribes for its own reasons: fix it at authoring.

This is also the first entry against P4 from the other side. Surface plausibility is supposed to disarm the reviewer; here the code is not merely plausible but correct — it passes review, passes tests, does not get reverted more often (revert rate ~0.9x), and costs 5-8% more compute in production. There is nothing for a disarmed guard to have caught.

Two caveats keep it from settling anything. The correlation test is reported in a threats-to-validity paragraph with no statistic, no model specification and no sample definition, so it is an unquantified null in a paper that quantifies everything else. And a monorepo with mature static analysis is precisely the setting where mechanical checks have already absorbed the findings review would otherwise contribute, which is a moderator (process adaptation, the third one) rather than a refutation.

The other direction of the loop, measured (2026-08)#

This theory is about humans reviewing agent-authored code. Cynthia et al. (arXiv 2607.21997) measures the loop running the other way — an agent reviewing a pull request, and a human deciding whether to act — across 54,713 comments from Copilot, Cursor and Codex in 341 Python repositories. The two share vocabulary and almost nothing else, and the numbers should not be pooled: a resolved comment is an adoption event, not a catch.

What it contributes here is the first sizeable measurement of the theory's second moderator, automated-reviewer capability, and it locates that capability somewhere the construct list does not currently have a slot for. Resolution runs 72.9% (Copilot) / 67.2% (Cursor) / 54.8% (Codex), and the agent-level spread survives controlling for comment characteristics — the authors attribute it to workflow integration and developer familiarity rather than to review quality, which makes it a moderator effect rather than a message effect. Of 470 card-sorted unresolved-but-argued discussions, the modal genuine rejection is project context the agent could not see (23.8%), not correctness; confident false positives are 63 cases against 4 outright hallucinations; and only 11 of 470 were dismissed as low-value noise.

Three consequences for the propositions above:

• P8 and P9 are untouched. This study measures neither review throughput/latency nor code quality/security. Adoption of a reviewer's output is a third quantity, and 71.4% pooled resolution says nothing about whether the resolved comments prevented defects.
• The automated-reviewer moderator binds on context, not capability-in-general. The failure that keeps agent review from landing is the same missing project knowledge that Tran et al. blame for AI's authoring defects — an agent flagging as a bug what the team decided on purpose. Whatever raises the moderator, it is repository context rather than model strength or comment prose (the study's own regression has AUC 0.58).
• A counterweight to the rubber-stamping reading of P1/P4. In the argued sample, developers are engaged enough to catch and correct the agent, and peripheral developers do it slightly more than core ones (35 vs 32 on Incorrect Suggestion). That is not a disarmed reviewer. The caveat is severe and structural: the sample is drawn only from the 6.7% of unresolved comments that got a reply, so it describes the developers who argued and is silent on the 93.3% who said nothing — which is where a fatigue effect would live if there is one.

Connections#

• Same-Model Review Blindness — the second moderator stops being a scalar. Automated-reviewer capability is treated here as one construct — how good the AI reviewer is — and Greptile's paired 500-PR datasets (case-study) say it is a property of the pairing: on the same corpora Opus 4.7 and GPT 5.5 are within 0.6pp of each other on average and 8.9pp apart depending on which agent authored the code, each catching fewer high-severity bugs in its own family's PRs. Routing review by detected authorship is therefore a process-adaptation decision (the third moderator) that moves the second one at no cost in review depth. It also supplies the vault's first recall figure for a deployed automated reviewer — nearer P9's quality half than adoption is, and still not a P9 answer, since recall against a self-built label set is not a code-quality outcome
• Agent Review Comment Resolution — the mirror direction (agent reviews, human decides), and the first population-scale reading on the automated-reviewer-capability moderator: 54.8-72.9% of agent review comments get resolved, the spread survives controlling for comment characteristics, and the modal non-adoption reason is project context rather than error. It confirms neither P8 nor P9 — it measures adoption, not throughput or quality — but it does say where that moderator's ceiling actually sits
• Community Smells Under AI Adoption — where the sustained peer interaction that study measures actually happens, in one respondent's words: "as seniors, we still review everything they do"
• The Tragedy of the Cognitive Commons — what the control point depends on: review is only a control if reviewers can substantively validate, and this names the developmental pathway that capacity comes from
• Acceleration Whiplash — the direct foil: Faros's vendor telemetry says the gap widens and maturity doesn't protect; this non-vendor theory says the sign is team-set and the no-review rate converges (see the contradiction above)
• Telemetry vs. Survey Measurement — sharpens the methodology debate: this is the non-vendor telemetry that OQ asked for, but its headline is that telemetry is direction-unstable without a causal model — telemetry beats surveys on latency yet can't adjudicate alone
• AI as Primary Author — supplies this theory's drivers: volume/velocity, surface plausibility, and code opacity (lost intent) are exactly Faros's authorship shift seen as inputs to review; the "is the invoking human an independent reviewer or the author?" ambiguity is the review-side of "what does acceptance mean"
• Verification as the New Bottleneck — the control-point claim is the bottleneck thesis with a mechanism map; answers "how far do you push automated reviews?" — throughput/latency yes (P8), quality/security contested (P9), latency sign set by policy calibration (P17)
• Returns to Expertise in Agentic Coding — the review-side mirror: reviewer expertise + disposition is the first of the three moderators that set the sign; expertise amplifies (and protects) here as it does at the authoring keyboard there
• Outsource Your Thinking, Not Your Understanding — comprehension debt is Karpathy's "you can't outsource understanding" measured as a review construct; "tasting the dish, not reading the recipe" is the erosion mechanism
• Agentic Technical Debt — comprehension debt is the cognitive twin of architectural drift; both compound through reinforcing loops at agentic-coding speed
• Polish No Longer Signals Readiness — surface plausibility at the review layer: polish disarms the reviewer's defenses (P4), so a prod-looking diff signals less than it seems
• AI Brain Fry — review load → fatigue → rubber-stamping (P2/P3) is the oversight-fatigue mechanism, sourced here from practitioner discourse rather than a controlled experiment
• Loop Engineering — "fold human review into the agent's own loop / a second sub-agent checks the first" is one of the paper's enumerated positions; the maker/checker split is automated review as a review-dynamics construct
• LLM-Assisted Grey-Literature Theory Building — the method that produced this theory (the paper's secondary contribution)
• Instruction Compounding — the mechanism behind the threshold rule: a "be conservative" instruction suppresses detection rather than filtering output, so the threshold belongs in a separate pass
• Large-Scale Test-Time Compute — review as a budget-allocation decision: a cheap low-effort pass at review time plus a thorough pass later, rather than one global effort setting
• Risk-Tiered Auto-Approval — P17 deployed. PostHog's StampHog is a risk-tiered gate running against a real merge queue: PR state + a blast-radius deny-list + a <500-line/<20-file ceiling, with an LLM showstopper check last and permitted only to tighten. It gave the final stamp on ~1 in 3 PRs merged into their main repo (1.6K in a month). Also a large uncontrolled instance of P9: the account reports throughput and measures no quality outcome. Note what it displaced — a Slack stamp-exchange ritual by engineers with "little to no context" — so it makes an existing rubber stamp explicit rather than automating substantive review away
• Agent-Generated Test Quality — a process-adaptation prescription with a measurement under it, which this theory's third moderator mostly lacks: send review attention to error-handling paths, because Try-Catch and Throw lines in agentic PRs go unexercised 81.0–86.0% of the time regardless of whether the agent added tests. It also supplies the positive case for the defect-class dimension below — untested error handling is a class attention can still reach, unlike the missing move constructor that defeated review entirely — and it removes a prop from under the whole control-point picture: for Python agentic PRs the existing suite executes none of the changed lines 64.8% of the time, so a reviewer's implicit "CI is green" is not a weak signal about the diff, it is no signal
• Security Debt of Agent-Generated Code — the outcome-level measurement against this theory's mechanism map, on the same open-source population: review that does happen commented on only 18.9% of genuine leaked credentials in agentic PRs, and reviewers focus on logical/functional correctness rather than security posture (Haider & Zimmermann). It separates coverage from efficacy — the no-review-rate convergence recorded above is a coverage trend, and it does not imply the review being added catches anything
• Dynamic Workflows: An Algebra for Agents — the control point moved up an altitude under volume: on a +1M-line port the human reviewed whether the adversarial reviewer agents were catching real discrepancies, not the diff itself
• Efficiency Debt of AI-Generated Code — the production null above, plus the outcome-side counterpart: 1.92x blocking threads and 1.24x reviewer iterations on AI changes (review load is real and measurable) alongside a revert rate below parity — so this theory's drivers fire while the outcome they are supposed to degrade does not
• Optimizer–Evaluator Decoupling — the architectural precondition for delegating review at all: the author-agent never grades itself, and at scale the reviewer's context is deliberately starved of the author's reasoning
• Post-Acceptance Edit Behavior — the repair layer upstream of everything this theory models, and the filter under all of its denominators. DECODE measures 53.6K in-IDE edits to accepted AI completions before any commit exists. Two consequences. First, a completion deleted 23 minutes after acceptance never enters the review system, so every outcome construct here is conditioned on surviving a stage the theory has no node for — and 31% of trajectories contain a removal edit. Second, the customize-then-remove path is P4 firing on the author rather than a reviewer: a completion plausible enough to be accepted and then tuned, and deleted on the next edit, disarmed the only person who had read it. Note the layer gap before importing anything — inline autocomplete from 2024-vintage models, median 9 lines, not an agent-authored PR

Open Questions#

• Every one of the 67 relationships is a hypothesis, not a finding — the paper's explicit call is for causal-estimand studies (controlling for the other constructs) to confirm, reverse, or drop each edge. Which of P1–P17 survive measurement? Partially answered (direction only, no edge confirmed): Security Debt of Agent-Generated Code (empirical, arXiv 2607.12428) supplies outcome-level evidence pointing the way P1 (load → shallower review) and P4 (surface plausibility disarms the reviewer) predict — 81.1% of genuine credentials in agentic PRs drew no reviewer comment before integration, and the reviewer-focus finding it cites (Haider & Zimmermann, arXiv 2601.19287) is that inline comments on AI-authored code address logical and functional correctness rather than security posture. But it isolates no mechanism, controls for none of the other constructs, and has no human-PR baseline, so it corroborates a direction without confirming an edge. First production test, and it is a null (2026-08-12): Tran et al. have the human baseline the security paper lacks and find no correlation between review time or iteration count and the survival of inefficient AI-generated code — so on the one outcome class they measured, the P1 chain does not reach the outcome. It is reported without a statistic or specification, and it tests one defect class in one review-mature monorepo, so it does not reverse P1 either. The usable result is narrower and new: the mechanism map needs a defect-class dimension, because review depth cannot plausibly moderate what review cannot see. The dimension gets its positive pole the same day: Dipongkor et al. (empirical, 4,882 agentic PRs) identify a class where attention does have purchase and say where to point it — error-handling constructs, unexercised 81.0–86.0% of the time in both languages whether or not the agent wrote tests. So the two ends of the dimension are now instantiated rather than merely postulated: a class review cannot catch at any depth, and a class review can catch if told where to look. P8/P9 remain untested (2026-08-12): Cynthia et al. is the largest study yet of automated reviewers but measures the adoption of their comments (71.4% pooled), not the throughput P8 claims or the quality P9 contests — so the two edges nearest to automated review still have no measurement, only a new third quantity beside them. A fourth quantity, and the closest approach yet to P9 (2026-08-12): Greptile measures automated reviewers' recall on ~1,500 labelled high-severity bugs (52–62% by arm) — not adoption, not throughput, and nearer the quality half of P9 than anything before it, but still not a quality outcome, since it scores detection against a self-built label set rather than defects that shipped. It is case-study, not empirical, and it moves the moderator rather than the edge: automated-reviewer capability turns out to depend on which model authored the code under review.
• Does the no-review convergence hold as agentic authoring crosses from <1% of PRs toward double digits, or does the early-adoption discipline break down under volume the way Faros predicts?
• The paper's own question: which decisions, under which conditions, push the system toward the virtuous loop rather than the vicious one? — the system-dynamics leverage-point analysis it gestures at but doesn't run.
• The three contested edges (automated review → quality/security, P9; governance → latency, P17; and one more) are contested because their sign is moderator-set — what are the moderator thresholds that flip them?

Sources#

• developer responses agent review comments — Cynthia, Widyasari, Roy, Zhang & Lo (Saskatchewan / SMU / Monash, arXiv 2607.21997, 2026-07-24), empirical: §IV (per-agent resolution rates), §V + Table V (the ten-pattern taxonomy of non-resolution), §VI and §IX (the regression and its AUC 0.58). The opposite direction of review — full treatment, parse warning and table recovery at Agent Review Comment Resolution
• Prompting Claude Opus 5 — Anthropic platform docs (retrieved 2026-07-25, vendor-claim): the report-everything-and-filter-separately rule, the low-effort review pass, and the precision/recall claim that touches P9
• Characterizing the Quality Profile of AI-Generated C++ in Production — Tran et al. (Google, arXiv 2608.06640, 2026-08-06), empirical: §4.3 (the five review-friction ratios and the reliability split) and §6 "Human-in-the-loop confounders and review dynamics" (the unquantified null). Evidence note and COI at Efficiency Debt of AI-Generated Code
• 3100 Opinions on Code Review in an AI World: Building Causal Theory from Practitioner Discourse — Agarwal, Miller, Kästner & Vasilescu (CMU, arXiv 2607.07980, 2026-07-08), empirical. §IV (the theory, constructs + P1–P17), §II-B & Appendix 1 (motivating observational study, finding-instability), §VI (discussion: control point, three moderators, system-dynamics framing), §VII (conclusion)