diff debt (n.) — the accumulated risk of merging AI-generated diffs that no human has actually read.
I shipped code I've never read. So did you.
Here's a confession. A few months ago I built a desktop automation bot called Erci — GUI, computer vision, license system, the whole thing. It works. People use it. And I have never truly read most of its code.
I'm not even a professional developer. I described what I wanted to an AI assistant, it produced the code, I ran it, and when it worked, I moved on. Thousands of lines accumulated this way. The bot is great — until something breaks in a module I've technically "owned" for months, and I open the file and realize I'm reading it for the first time.
If you're a professional developer, your version of this story is more subtle but structurally identical: the agent produces a plausible 900-line diff, the checks are green, the sprint is on fire, you skim, you approve, you merge. The pull request looked perfect. That's exactly the problem — it looked perfect.
I started calling this diff debt: the gap between what was merged and what was actually reviewed.
Why it needs its own name
We already have good words for the neighborhood. Technical debt lives in the code — shortcuts you consciously took. Verification debt (a framing AWS CTO Werner Vogels pushed at re:Invent 2025) is the macro cost of inadequately checking AI output. Comprehension debt (Addy Osmani's term) is the erosion of the mental model you used to build for free just by writing code yourself.
Diff debt is the unit-level version. It accrues one unread pull request at a time, which is exactly why it's invisible: no single skimmed diff feels like a decision. Nobody chooses to stop understanding their codebase. It happens 400 green-checked lines at a time.
The math got broken
Generation got fast. Review didn't.
An engineer writing 500 lines by hand builds understanding as a side effect of writing. An agent producing 5,000 lines in six minutes produces zero understanding — that work is now a separate, unpaid job called review, and the numbers say it isn't happening:
- Sonar's 2026 survey of 1,100+ developers found roughly 42% of committed code is now AI-generated — projected to hit 65% by 2027.
- The same survey: 96% of developers don't fully trust AI-generated code to be correct, yet only about half always check it before committing. That spread between distrust and verification is diff debt accruing in real time.
- Since AI tool adoption, average PR sizes have roughly tripled in many orgs — diffs that used to be 100–200 lines now arrive at 400–600. A 400-line diff can be read. A 4,000-line diff can only be skimmed.
How the interest compounds
Like financial debt, diff debt charges interest. Unread code becomes the foundation for the next unread diff. Six months later a production incident lands at 2 a.m. in a module that "someone" reviewed, and the debugging session costs more than writing the feature from scratch would have. Refactors stall because nobody can predict what breaks. Onboarding slows because there's no one to ask — the author was a model, and the reviewer was a glance.
Paying it down
You can't read everything; the volume math doesn't allow it anymore. Paying down diff debt means spending review attention where wrongness is expensive:
- Risk-tier your reviews. Anything touching money, auth, data deletion, or external side effects gets a real human read. Boilerplate can pass on green checks.
- Cap diff size. If the agent hands you 4,000 lines, make it deliver in reviewable increments. Reviewability is a feature; demand it.
- Demand tests that encode intent — not tests the model wrote to flatter its own implementation.
- Track comprehension like a metric. If nobody on the team can explain a module, treat it as an outage waiting for a date.
The teams that win the next few years won't be the ones that generate the most code. They'll be the ones that know, with confidence, what's actually in theirs.
I documented the full definition at diffdebt.com. If your team has its own name for this, I'd genuinely like to hear it.
Top comments (12)
Thanks Erdi! Exactly that moment when you realize you've been approving PRs on autopilot — it's such an easy trap to fall into when you're moving fast. The framing helps because it makes the cost visible: every unread diff is basically borrowing against your future understanding of the codebase. @erdibay what strategies have you found helpful for actually paying that down without killing velocity?
The "10-15% premium" framing is honest and I think underrated. Most people think of review as pure overhead, but the comparison should be against the cost of a 2 a.m. debugging session — not against zero.
Your point about breaking diffs into reviewable pieces maps to something I have seen elsewhere: the best code review workflows are the ones where each unit is small enough that "does this do what I expect?" can be answered in under 30 seconds. Anything larger and the reviewer starts pattern-matching instead of actually reading. Same instinct, different context.
Honest answer: I'm a team of one working with an AI, so my version is small. Three things that actually stuck: (1) I stopped accepting big diffs — if the AI hands me a wall of code, I make it re-deliver in pieces I can actually follow. Smaller diffs cost a little speed upfront, way less than a 2 a.m. debugging session later. (2) Anything touching data or money gets a real read; boilerplate gets a skim, and I've made peace with that. (3) When something breaks, I don't just fix it — I make the AI explain the module to me and I keep those notes. That's the "document forward" part: the debt gets paid at the moment it hurts, with interest, but at least it gets paid.
Velocity-wise: I probably move 10-15% slower than pure autopilot. That's the premium on the insurance.
Compared against the 2 a.m. session, not against zero — that's the whole argument in one line. This thread is turning into a better definition page than my definition page 😄
Ha! If this thread ends up being the canonical reference, that's the best outcome. The definition page explains what it is; this thread explains why the "2am session" comparison is the right mental model. Two different jobs, both useful.
This is such a clean framing. I've been noticing the same thing — when a PR is 80% AI-generated, the review instinct shifts from "does this work?" to "do I even understand what this does?" and that gap is where the debt accumulates.\n\nThe loan metaphor is spot on. The interest rate is basically how much context you lose every time you skip the diff.
The interest rate is how much context you lose every time you skip the diff" — that's a sharper way to put it than mine, honestly. And the shift you describe from "does this work?" to "do I even understand this?" is exactly the moment the debt becomes visible. Might borrow that framing (with credit) if I expand the definition page.
This "diff debt" framing hits — especially the part about code that technically runs but nobody actually understands. I write about AI testing and this is the exact gap I keep running into: the code passes, the tests pass, but what's actually happening inside is a black box. The scary part isn't when it breaks — it's when it doesn't, and you have no idea why.
What's your strategy for catching up on that code you've never read? Rewind and audit, or just document forward?
Honestly? Document forward, audit on failure. A full rewind-audit of thousands of lines I didn't write was never realistic for me — so when something breaks, that module gets its real first read, and I write down what I learned so it doesn't stay a black box. Not proud of it, but it's the honest version of paying diff debt: you pay interest on the parts that hurt first.
Your point about "the scary part is when it doesn't break" is exactly right though — that's the debt you don't even know you're carrying.
Hahah i agree.. i use a lot of AI and 40-50% of times i dont even read th ecode back... but yes i make sure to use few tools to make it check security debug save tokens etc... but your so right!
The 40-50% number is the honest one — most people won't say it out loud, so respect for that. And the tooling you mention is exactly the right instinct: you can't read everything, so you make the machine check what you can't. That's not laziness, that's paying down diff debt with automation instead of attention.
Curious: what's the biggest diff you've merged without reading?