Research lens
The claim, its evidence, and what's still open.
This page is for the reader who wants to know what's actually been shown. Not what's plausible — what's been measured, what's been contested, and what remains a hypothesis the discipline is trying to test.
A working research program, not a finished thesis. Every claim below carries a stated evidence tier. Where two published findings disagree, the disagreement is named.
The thesis
A well-established tendency, steepened.
Lead thesis. Under sustained, low-control AI-agent iteration, a codebase does not merely accumulate ordinary technical debt. It undergoes a qualitatively different, compounding decay — arriving there through several specific, nameable mechanisms rather than through generalized "getting worse." Reducing or removing human review removes the last interruption capable of stopping this before it compounds.
This is a claim about an eventual, mechanistically-driven end state under sustained conditions — not a claim that every codebase is actively collapsing right now. The corollary is what T2D2 is built to demonstrate: a discipline built around a pre-code structural proposal, checked deterministically against implementation and correlated forward into runtime, is expected to measurably slow or interrupt this compounding process relative to regimes that rely purely on human judgment or purely on agent self-assessment.
Neither claim has yet been tested against real data at the time of this writing. That is the honest state. Below is the mechanism-level understanding that exists, the supporting evidence, and what a research program would need to test.
Five mechanisms
Compounding drift, decomposed.
Treating "drift" as a single undifferentiated process makes it impossible to test. T2D2 decomposes it into five mechanisms, each with a distinct causal story and a distinct diagnostic signal.
1. Performance degradation
Accumulated structural cruft — redundant paths, deeper call chains, patched-over inefficiencies — degrades runtime performance over successive iterations.
2. Combinatorial intractability
As features and constraints multiply, the interaction space grows combinatorially. Past some point, no single reasoning pass holds the full space in working attention — a sharper constraint for a bounded context window than for a distributed human team.
3. Parallel structures
Multiple inconsistent implementations of the same concern accumulate — not through decision, but because each new change is easier to satisfy locally than to correctly extend the existing one.
4. Patched over root causes
Successive fixes address symptoms local to each change rather than the underlying structural issue — because diagnosing the root cause costs more, in the moment, than a local patch.
5. Uncorrected signal degradation
An indefinite telephone game. Each iteration's output becomes the next iteration's input, with no built-in moment where the current state gets checked against the original intent.
Why this decomposition matters
Each mechanism is a distinct RQ in T2D2's research program. Testing them as one undifferentiated "drift" metric would make it impossible to know which T2D2 actually helps with, or how much.
Theory
Control-type vs. warning-type verification.
The framing borrowed from Shingo's poka-yoke tradition is a distinction between two kinds of gate. A control mechanism halts a process automatically at the point of deviation and requires no ongoing human vigilance to function. A warning mechanism signals that something may be wrong and depends on a person, or another judgment-making process, noticing and acting on that signal.
Human code review is a warning mechanism. So is an LLM asked to review its own output. Each functions like an analog relay: it passes along whatever error has already accumulated from earlier stages, and while it may catch a new error introduced at its own stage, it has no structural mechanism for detecting earlier error that happens to look locally plausible.
The Fidelity Check is proposed as a control mechanism. It functions like digital regeneration in a communications network: at each checkpoint, the current state is compared against a clean, persistent reference (the structural graph), and a clean signal is regenerated rather than accumulated noise being passed forward.
The two verification types should produce a difference in the shape of failure over time, not merely in its rate. A warning-type regime should show errors compounding smoothly across iterations, resembling generation loss in analog copying. A control-type regime should show error resetting toward the reference at each gate — with any residual drift attributable specifically to whatever the gate's scope doesn't cover.
A difference in failure shape, not just failure magnitude, is a stronger and more falsifiable claim than "T2D2 produces less drift." It is what T2D2's research program (RQ-D4) is designed to test.
Direct engagement
The Monperrus paper, on its own terms.
Monperrus (arXiv:2606.13175, June 2026), "The End of Code Review: Coding Agents Supersede Human Inspection," argues that coding agents have crossed a capability threshold where human review is no longer a necessary quality gate. T2D2 engages this directly, at the claim level, rather than arguing against a vague industry mood.
The premise that human review at current staffing levels cannot scale to agent-volume change is genuinely hard to argue against. T2D2 does not contest it. What T2D2 contests is the conclusion drawn from it.
On the "cost-benefit flip." Monperrus argues that a static cost-benefit comparison has already flipped — agent review is instantaneous, consistent, auditable, while the marginal defect-detection value of human review shrinks as agent capabilities grow. This is a snapshot comparison, taken at a single point in time and codebase state. It does not account for what the five mechanisms describe: a compounding cost that accrues specifically because oversight was reduced, growing with codebase size, complexity, and — critically — the number of successive iterations since oversight was reduced.
The counter-model is a trajectory, not a snapshot: total cost of ownership as a function of codebase size, iteration count, and control-regime type. Even where Monperrus's static comparison is correct at the moment it is measured, the trajectory determines whether it still holds N iterations later.
On "structured agent sign-off." Monperrus's own proposed alternative to human review — test coverage thresholds, security scan results, style compliance, reasoning traces — is a warning-type mechanism wearing the vocabulary of a control-type one. "Coverage threshold" is a check on the presence of tests, not on their substance. The mutation-testing evidence (see problem class 2) shows exactly how a coverage threshold can pass while asserting nothing. The Fidelity Check, by contrast, is a comparison against a persistent structural reference — a control-type mechanism by Shingo's definition, not merely a warning-type one with a stricter rulebook.
On "developers become specifiers and orchestrators." This is the concession in the paper that undermines its stated thesis. If developers still evaluate agent output at a higher level of abstraction and intervene when stakes are high, this is not the elimination of code review. It is code review, relocated to a higher level of abstraction and triggered by different signals. Precisely: it is architectural inspection — human oversight spanning both the code level and the structural level, triggered and facilitated by deterministic alerts rather than exercised continuously.
Which is, worked through carefully, a redescription of T2D2's own model using different vocabulary.
Safety-engineering lens
Why "removing inspection because it can't keep pace" is not a recognized response.
Consider a factory whose machine can produce a product faster than humans can inspect it for defects, where the defect rate is known to be significant and non-zero, and where the product carries real potential for harm. The question is not whether inspection capacity has been exceeded — by hypothesis, it has. The question is what follows from that fact.
In every safety-critical engineering discipline — pharmaceutical manufacturing, aerospace software (where verification rigor is tied to failure severity via Design Assurance Levels), automotive functional safety, nuclear systems — the answer is to slow production, add verification capacity, or both, until the process is characterized and in control. Removing inspection because it cannot keep pace is not a recognized response in any of these domains. It is closer to the specific failure these domains were built to prevent.
This argument is strongest for software where defects carry real potential for harm, and correspondingly weaker for low-stakes software where a shipped defect costs little. A marketing website's AI-merged CSS bug is not the same category of problem as a defect in code controlling a safety-relevant system. Treating them identically would be a real weakness.
But when large organizations apply the "review can't keep pace, so trust the same systems producing the errors" logic uniformly — rather than scoped to genuinely low-stakes code — the scope of potential harm increases. So does long-run operating cost and the cost and time of ongoing maintenance, even where no acute harm materializes. The near-term savings from removing review is a cost shifted forward and compounded, not a cost eliminated.
Open questions
What's still open.
A working research program is defined by what it's trying to find out. These are the questions T2D2's own research proposal is designed to answer — not yet answered.
Does compounding drift actually compound?
Not just "does code get worse" — does the rate of degradation increase over successive uncorrected iterations? Measured per mechanism, not as one undifferentiated metric.
Does a control-type gate outperform a warning-type one?
Specifically on the drift patterns Monperrus's premise would leave uncorrected. The single highest-priority study if only one can run before first publication.
What's the precision/recall of the Fidelity Check itself?
The proposed graph is authored by a human during the Comprehension ceremony, not inferred by a model — so its accuracy is a question about its author, not an eval problem. The measurable one sits downstream: whether the deterministic conformance check flags genuine deviations without a false-positive rate high enough that teams learn to route around it. A gate people bypass has become a warning mechanism again, whatever it was labelled.
Do teams actually deploy the gate where it can't be bypassed?
Tamper-resistance is not an empirical property of the graph — it follows deterministically from where the check runs. Execute it in a pipeline the agent cannot alter, report through a channel it cannot fabricate, and the property holds by construction. What remains open is organisational: whether teams under delivery pressure keep it there, or relocate it somewhere the agent can reach.
Selected references.
Note on scope. The two 2025 entries below — AgentIF and IFScale — were verified against their arXiv records; author names, titles, and identifiers match. The 2026-dated entries carry the titles and identifiers as published in the working source materials for the research proposal, with one still under a working title. Venue and acceptance details are reproduced from those sources; full verification and formatting to a single consistent citation style (ACM or IEEE) is a scheduled task before formal submission. One entry — Meta's TestGen-LLM — is cited in the problem classes analysis and listed here for completeness.
- Monperrus, M. (2026). The End of Code Review: Coding Agents Supersede Human Inspection. arXiv:2606.13175.
- Maddila, C., Rashik, M., Khan, E. M., Jha, S., Saindon, J., Nagappan, N., & Rigby, P. C. (2026). From Code Review to Code Critique: Intent, Drift, and Spotlight for AI-Generated Diffs at Scale. arXiv:2607.29516. The system described is ARCTIC.
- Qi, Y., Peng, H., Wang, X., et al. (2025). AgentIF: Benchmarking Instruction Following of Large Language Models in Agentic Scenarios. arXiv:2505.16944. NeurIPS 2025 Datasets & Benchmarks Track (venue as published in the source proposal).
- Jaroslawicz, D., Whiting, B., Shah, P., & Maamari, K. (2025). How Many Instructions Can LLMs Follow at Once? arXiv:2507.11538. Introduces the IFScale benchmark.
- Tang, N., Chen, C., Xu, G., et al. (2026). How Coding Agents Fail Their Users: A Large-Scale Analysis of Developer-Agent Misalignment in 20,574 Real-World Sessions (working title). arXiv:2605.29442.
- Alshahwan, N., et al. (2024). Automated Unit Test Improvement using Large Language Models at Meta. arXiv:2402.09171. The TestGen-LLM system; the filter-and-retry figures quoted in the problem-classes analysis come from this paper.
- Harnad, S. (1990). The Symbol Grounding Problem. Physica D 42(1–3).
- Bender, E. M., et al. (2021). On the Dangers of Stochastic Parrots. FAccT 2021.
- Yamaguchi, F., et al. (2014). Modeling and Discovering Vulnerabilities with Code Property Graphs. IEEE S&P.
- Spec Kit Agents (2026). arXiv:2604.05278. Also cited in the problem classes analysis.
- De-Hallucinator (2024). arXiv:2401.01701.
- Yu, L., et al. (2013). An Empirical Study of Lehman's Law on Software Quality Evolution (Tomcat, Ant).
- Olbrich, S., Cruzes, D., Basili, V., & Zazworka, N. (2009/2010). Empirical study on code-smell evolution (Lucene, Eclipse).
- Mitchell, M., & Krakauer, D. (2023). The Debate Over Understanding in AI's Large Language Models. PNAS.
- Shanahan, M. (2024). Talking About Large Language Models. Communications of the ACM.
- Senge, P. (1990). The Fifth Discipline: The Art and Practice of the Learning Organization. Reinforcing and balancing feedback loops — the systems framing for compounding drift.
- Shingo, S. (1986). Zero Quality Control: Source Inspection and the Poka-yoke System. Productivity Press.
- Deming, W. E. (1986). Out of the Crisis. MIT Press.
This page summarises the argument. The full case is Structural Fidelity as a Control Mechanism for Human-AI Software Development (26 pp., Tyrone Thomas, BreakThrough Technologies LLC) — a research proposal for partnership, in working-draft status, with evidence labelled by strength and unaudited claims marked as unaudited. Section 11 consolidates what would still need to be true, or measured, before it could guide funded or partnered research. Read the research proposal (PDF) →