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 d...
For further actions, you may consider blocking this person and/or reporting abuse
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?