# 67% Debug AI Code Longer Than Writing It (Escape Here)

> Most developers now debug AI code longer than writing it. The cause isn't bad code — it's unverified code. The prove-first workflow inside.

Source: https://boringpush.com/blog/67-percent-debug-ai-longer-fix

## Faster writing, slower shipping

AI writes the feature in four minutes. You spend forty understanding it, twenty finding the null dereference, and another thirty on the second bug the fix introduced. Net: slower than writing it yourself — with less understanding of the result.

Surveys keep confirming it (one widely cited: most developers debug AI code longer than they'd have spent writing it — treat exact percentages as directional, not census). The paradox resolves simply: generation got 10x faster while verification stayed human-speed. Speed without proof is just faster debt.

Debug ai code longer is not an argument against agents. It is an argument against accepting their output the way you accept your own — your code carries your mental model; theirs carries nobody's.

## Where the debugging hours actually go

| Hour sink | Share of pain | Cure |
|---|---|---|
| Understanding generated code | Largest | Small tasks (diff fits in head) |
| Finding the real bug | Large | Curl unhappy paths immediately |
| Fix-induced second bugs | Medium | Gate + re-curl after every fix |
| Scope surprises (12 files?!) | Medium | File-count caps per task |
| Re-prompting loops | Growing | Better task slicing, not wording |

Three details compound the loop:

1. **Big diffs defeat review.** A 400-line agent diff gets skimmed; bugs hide in skimmed lines with perfect syntax. Small tasks (one behavior, ≤3 files) produce reviewable diffs — debugging shrinks with diff size, superlinearly. The 500-LOC cap from the slop post is a debugging intervention disguised as review hygiene.
2. **Fixes without reproduction multiply.** "Try null-checking" without curling first produces fix candidates, not fixes — each candidate needs its own verification, and wrong candidates add their own bugs. Reproduce (curl the 500), then fix, then re-curl: the scientific method, enforced as process.
3. **Context loss across sessions.** Yesterday's agent knew why the workaround exists; today's session "cleans it up" and reintroduces the bug. Session notes (what was decided, what was avoided) travel in commit messages and code comments — continuity written down survives model swaps and Mondays.

The token-loops post covers cost; this one covers time — the scarcer currency.

## Debug ai code less with prove-first

The shape that flips the ratio: generation stays fast, verification gets cheap, debugging starves.

**Step 1 — Slice tasks until diffs fit in your head.**

```md task sizing (the whole technique)
BAD:  "add coupons to checkout" (8 files, 400 lines, 2 hours to review)
GOOD: "add coupon_pct column + migration" → "apply pct in order total" →
      "show line item in UI" (3 tasks, 3 small diffs, 20 min total review)
```

Small tasks debug fast because the suspect list is short: three files changed, bug in one of them, found in minutes. Slicing is the highest-leverage debugging skill in the agent era — cheaper than any tool, effective against every bug class. Size the task to the review, not to the ambition.

**Step 2 — Demand proof with every delivery.**

```bash
# session exit ritual (blocking, pasted in transcript):
node --check <touched> && npm run lint          # form proven
curl <changed endpoint, happy + unhappy>         # reality proven
curl -s /api/health                              # neighborhood proven
```

Proof-per-delivery converts debugging from archaeology (what did it do?) into arithmetic (which proof failed?). The done-but-500 post details the gate; the principle here is economic: five minutes of proof prevents forty of debugging, every single time, with interest. Unproven deliveries are debugging scheduled for later at higher rates.

**Step 3 — Keep a bug ledger that teaches.**

```md docs/bug-ledger.md (5 lines per entry)
- 09-24 coupon null → UI omits field, test mirrored omission → RULE: curl real payloads
- 09-21 paywall bypass → refactor dropped guard → RULE: grep guards per diff
- Ledger reviewed monthly → recurring classes become AGENTS.md clauses
```

Repeated bugs are curriculum: each entry's RULE graduates into the instruction file (curl real payloads → gate ritual; grep guards → review checklist). Debugging time compounds downward as the ledger converts incidents into prevention. Teams call this postmortems; solos call it five lines per bug. Same learning, less ceremony.

That's the shape of it — agents fast, humans certain, ledgers wise.

## Debug ai code longer trend, reversed

| Month of agent features | Accept-first (old) | Prove-first (this post) |
|---|---|---|
| Features shipped | 12 | 12 |
| Debug hours total | ~30 (long tail) | ~8 (caught at proof) |
| Midnight incidents | 3 | 0 |
| Review time total | ~4 (skimmed) | ~8 (real reads) |
| Net engineering time | Baseline | ~40% less |

No use pretending otherwise: prove-first spends review and proof time upfront — roughly double the per-feature ceremony — to reclaim the long debugging tail.

BoringPush measures total time, not ceremony time: eight real-review hours plus zero midnights beats four skimmed hours plus thirty debugging. Front-loaded rigor is cheaper than back-loaded archaeology, month after month.

## FAQ

### Is debug ai code longer inevitable, or specific to bad setups?

Setup-specific, overwhelmingly: unfenced repos with big tasks and accepted claims produce the horror stories; fenced repos with sliced tasks and proof gates report net gains. The surveys average both populations — your setup decides which half you're in. Inevitability is what unfenced setups call their process gap.

### How small is small enough for task slicing?

Diff-reviewable in one sitting without scrolling fatigue: ≤3 files, ≤150 lines changed, one behavior. Bigger tasks split by layer (schema → provider → route → UI) or by behavior (happy path → unhappy paths → edge states). When in doubt, split once more — over-slicing costs a minute of overhead, under-slicing costs an hour of debugging.

### Should junior developers use agents differently than seniors?

Yes — juniors need smaller slices (they can't yet smell wrong code) and mandatory proof (their review catches less). Seniors review diffs; juniors review diffs plus run every proof twice. The workflow scales strictness inversely with experience: least able to verify verifies most. Mentorship in the agent era is proof discipline, not syntax help.

### What metrics prove my debug tail is shrinking?

Three numbers monthly: debug hours per shipped feature (target: falling), midnight incidents (target: zero), proof-gate pass rate first-try (target: rising). The bug ledger supplies the qualitative half (recurring classes → new clauses). Measure lightly, review monthly, adjust slicing and gates on evidence. What gets measured gets smaller.

### Do better models reduce the need for prove-first?

Marginally — stronger models write subtler bugs (correct-looking, wrong-meaning) that demand more verification skill, not less. The 67% figure persists across model generations precisely because capability gains flow into bigger tasks, not safer ones. Process scales across models; model-hoping doesn't. Bet on workflow, enjoy model upgrades as tailwind.

### When is hand-writing faster than agent-plus-proof?

Cryptic algorithms, novel architectures, and anything where you already hold the full mental model — the proof overhead exceeds generation savings. Roughly: if you can write it in under 20 focused minutes, write it; if it needs exploration, research, or boilerplate volume, agent plus proof wins. Know both speeds, choose per task, never ideologically.

## Keep reading

- [Agent Said Done. Checkout 500s. (The 10-Second Check)](/blog/ai-agent-says-done-but-500-fix) — the war story this workflow prevents
- [Endless AI Slop Is Killing Code Reviews (Fix Inside)](/blog/ai-slop-endless-stream-review-friction) — the volume half of the same problem
- [Build Features With AI That Don't Need Rewrites](/blog/build-feature-with-ai-data-first) — slicing by pipeline layer