AI-Generated Code Without Understanding Debt: Explain, Test, and Review Before Merge

The more code AI produces, the merge question stops being “are the tests green?” and becomes “can a human explain why this change exists?” Understanding debt — also called epistemic debt — is working code nobody can diagnose or safely change. Merge it anyway and the bill arrives at 3 a.m.

📑Table of Contents

1. Generation is fast; understanding is still the bottleneck
2. Separate technical debt from understanding debt
3. When review capacity is exceeded, unreviewed code remains
4. Ship with an explanation gate and a verification loop
5. FAQ
6. Summary

Why 14% writing time still leaves a bottleneck

ACM Queue cites a Microsoft 2025 study of more than 450 engineers: developers spent about 14% of their time writing code. Speeding generation does not automatically speed review, verification, or maintenance. Merge counts and green CI can look healthier while that debt grows.

---

What you can apply after this article

This article distinguishes technical debt from understanding debt, shows the review-capacity arithmetic, and supplies an explanation gate plus verification loop you can apply to one recent AI diff. After you read it, add one missing control — not another model license.

---

Generation is fast; understanding is still the bottleneck

Halving writing time does not halve the job. The slow parts are usually comprehension, review, and integration.

Inner-loop speed does not raise the outer loop

Generation is the inner loop. Design, review, and maintenance are the outer loop. Accelerating the inner loop without strengthening the outer loop simply moves the load downstream.

ACM Queue’s back-of-envelope is:

• if coding is about 15% of the work, doubling coding speed cannot raise overall productivity by more than 15%
• the other ~85% is meetings, design, review, environment, and understanding existing systems
• a related split is 18% coding on a good day versus 11% on a bad day

The point is the same: writing is not most of the day.

---

Treating writing as the bottleneck overflows review

GIGAZINE (2026-08-05) restates the eight myths in Japanese: if you treat writing as the bottleneck, review, test, and integration overflow. Lines of AI-written code are a poor success metric. They reward volume and can raise debt and security follow-up.

---

Faros numbers are a secondary citation

Brain Detox secondarily cites Faros numbers for high-AI-adoption orgs:

• PR size +51.3%
• files touched +59.7%
• median review time +441.5%
• bugs per PR +54%
• PRs merged without review +31.3%

Treat Faros as a secondary citation here, not a re-measurement. The 14% figure is one Microsoft 2025 organization, not a greenfield startup. Before buying more seats, look at review wait time and diffs nobody can explain.

---

Separate technical debt from understanding debt

Three debts that look different on a dashboard

Technical debt is a compromise in the repository. Understanding debt (epistemic debt) is code that runs, passes its tests, and still cannot be explained, diagnosed, or changed safely. Verification debt is the remaining work of checking correctness, security, and maintainability after generation became instant. Dashboards stay green. The invoice appears later in incidents, migrations, and audits.

---

How the three debts show up

Kind	Where it accumulates	How it looks	When you pay	Typical sign
Technical debt	Code structure	Duplication, hasty fixes, coupling	Interest on every change	Modules nobody wants to touch
Understanding / epistemic debt	People and shared models	Clean, CI green, approved	Incident, migration, 3 a.m.	It works; nobody can say why
Verification debt	Review and test	Generation is instant	Checks around merge	Debugging almost-right output

---

Sources for the three-debt split

Sources: arXiv 2602.20206, Luis Mori, ZDNET Japan (as of August–September 2026)

---

Explanation gates change repair more than utility

arXiv 2602.20206 studied 78 U.S. novices in Cursor for two hours.

Measured results:

• Unrestricted GenAI: 92.4% functional utility, 23.1% repair
• Explanation Gate group: 89.1% utility, 61.5% repair (38.4 points)
• Proxy Ed = utility − repair: 69.3 unrestricted, 27.6 gated, −4.0 manual
• Median gate friction: 14.2 minutes
• 72% initially called it annoying; 64% of those who fixed the later logic bomb said the gate is why they knew where to look

Green tests answer yes or no. Participatory understanding — what to change next — is a separate check.

---

Green metrics miss dependence and verification debt

Luis Mori notes that merged PRs, throughput, and green CI can improve while understanding debt grows. GitClear / GitKraken (623 million changes, 2023–2026) reports:

• duplicated blocks +81%
• refactoring line moves −70%
• long-term legacy maintenance −74%

Cheap generation without explainable owners makes the next change dangerous.

---

Dependence and almost-right answers

ZDNET Japan (2026-08-24) reports a Coddy Tech survey of 305 developers: 80% felt dependence more than benefit.

Related survey direction:

• Stack Overflow 2025: 45% were frustrated by almost-right answers (verification debt, directionally)
• n=305 is not a census
• Dell’Acqua et al. (BCG, 758 consultants): quality and speed gains inside the AI frontier, and a 19-point drop in correctness outside it

Experts may find a blanket explanation gate unnecessary on boilerplate. Limit it to logic-bearing diffs.

---

When review capacity is exceeded, unreviewed code remains

Arrival rate and headcount are no longer coupled

Agents raise PR arrival rate. Human review rate stays tied to headcount. When arrival exceeds capacity, some work is unreviewed or rubber-stamped. Writing speed used to cap arrival. Agents cut that coupling. A 100% human-review policy converts overflow into stamp-and-merge.

---

Queueing math and line-budget rules of thumb

TMLS is an analytical queueing model, not a new experiment.

The model says:

• the minimum bypass fraction is a = 1 − μ/λ
• as utilization approaches 1, wait time diverges
• size variance on agent PRs stretches waits further (Kingman)

Cisco / SmartBear guidance:

• 200–400 lines per sitting
• detection drops faster than about 500 LOC/hour
• a well-sized 60–90 minute review finds about 70–90% of defects
• detection declines after about 60 continuous minutes

---

Vendor metrics and DORA point the same way

LinearB 2026 (vendor, 8.1 million PRs) reports:

• agentic PRs waiting 5.25–5.3× longer for review pickup (~16 hours vs ~200 minutes)
• AI-assisted PRs 2.6× larger

That vendor sells review tooling. The direction matches DORA’s stability findings.

DORA 2025:

• 90% adoption
• throughput positively correlated, stability negatively correlated
• 30% have little or no trust in AI-generated code

Google’s claim that more than a quarter of new code in a quarter was AI-generated and “reviewed and accepted by engineers” is a generation-side statement, not proof of review quality. Drop the premise that every PR is read. Allocate reviewer time to high blast-radius changes first.

---

Ship with an explanation gate and a verification loop

Do not close verification on the writing model

Do not let the writing model verify itself. Keep changes small, ask for an explanation before the raw diff, escalate from static analysis to tests to a different model to a human, and auto-merge only the low-risk tail behind gates. Same-model self-review shares bias and hallucination. Understanding used to be a side effect of reading the diff. When writing outruns reading, that side effect disappears.

---

Ship procedure

1. Pick one recent failure or oversized AI PR. Write the blast radius (docs / app logic / auth / billing / deletion / permissions).
2. Split to one concept. If it exceeds 200–400 lines, slice it (TMLS / SmartBear).
3. Before the raw diff, require a short “what changed, why, and what breaks if we do not.” Do not Apply logic lines until you can restate the causal chain in your own words (arXiv Explanation Gate).

---

Verification stack and fit

4. Verification stack: static analysis (milliseconds) → tests (seconds to minutes) → semantic review by a different model than the writer → humans on a strategic ~10% (auth, billing, infra). Shaam centers Guide-Verify-Solve on never closing verification on the writing model.
5. Spend review budget on high risk-density classes first. Docs, tests, and mechanical refactors can auto-merge behind gates. Auth, billing, deletion, and permissions stay human-read even when the queue is busy.

---

When this loop fits

6. Fit: feature work with lint, tests, dead-code detection, and a settled design. Exploration is often faster as small build-and-break.

---

Allocate humans by blast radius

Blast radius	Examples	Human read?	Gate-and-merge only if
Low	Docs, extra tests, mechanical rename	Not required	Lint/tests green and an explanation exists
Medium	App logic, one feature	Sample the diff	Within line budget and at least one extra verification layer
High	Auth, billing, deletion, permissions	Required	Never skip people because the queue is full; split first

---

Sources for the blast-radius table

Sources: TMLS, Shaam, and arXiv 2602.20206 procedures arranged by blast radius (as of August–September 2026)

---

Limits and checklist

The explanation-gate effect size is a novice experiment. Sonar’s “44% fewer outages with automated verification” is vendor-reported. A CMU Cursor study saw 3–5× lines added in month one, then fade around two months, with warnings +30% and complexity +41%. Watching an agent is not review.

---

Merge checklist

Checklist:

• ✓ You can explain this diff in your own words
• ✓ At least one verification layer is not the writing model
• ✓ The change fits the review budget (lines and time); otherwise split
• ✓ High blast radius is human-read; low blast radius has explicit gate conditions
• ✓ Agent-watching time is not counted as review time

The ship condition is not “generation finished.” It is “explanation and verification finished.”

---

FAQ

If every test passes, is understanding debt gone?

No. Tests are a floor for verification (is this correct). Participatory understanding (what to change next) is separate. Code can be tidy and CI green with an empty why.

---

Will a coding AI make shipping faster?

Writing time can drop. In Microsoft 2025, writing was about 14% of the job, so the leftover load moves into review and test. DORA still shows adoption correlated positively with throughput and negatively with stability.

---

Isn’t 100% human review enough?

When arrival exceeds review capacity, the unread remainder is bypassed or rubber-stamped. Slice work to fit capacity and put people on high blast-radius changes first.

---

Can the writing model also review?

It can help with mechanical layers. Do not close verification on the same model. Add a different model, static analysis, or tests, and keep judgment calls with humans.

---

Does an explanation gate slow everything down?

In the novice study, median friction was 14.2 minutes. Utility stayed close (89.1% vs 92.4%) while repair rose from 23.1% to 61.5%. On expert boilerplate it can be extra load. Limit it to logic-bearing diffs.

---

Related articles:

• 13572
• 13563

Summary

Faster generation does not automatically raise understanding or review speed. Keep technical debt and understanding debt apart, and do not treat green tests as proof that someone understands the change. When review capacity is exceeded, unreviewed code remains. Assign people to high-risk changes first.

Do not add another tool seat as the next step. Take one recent AI diff and check four things: explanation, a second verification layer, line/time budget, and blast radius. Add the one control that is missing.