diff debt (n.) — the accumulated risk of merging AI-generated diffs that no human has actually read.
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.
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.
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:
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.
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:
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.