Review Debt: The Cognitive Cost of AI-Assisted Coding

A few months back, I shipped four features in two days.

By Friday of that week, I couldn't explain two of them without opening the code.

By every surface metric, it was one of the most productive stretches of my career. Pull requests merged, tickets closed, features went live, and the velocity numbers looked beautiful. I should have felt good.

Instead, I closed my laptop on Friday with a hollow kind of tired I hadn't felt in a decade of shipping software, and one thought:

I don't quite own what I just built.

That feeling nagged at me for weeks before I finally put a name on it.

I've started calling it review debt, the accumulated cognitive cost of shipping code you didn't fully internalize while it was being written. It works a lot like technical debt and compounds the same way, but it sits in your head instead of your codebase, so it can build up for a long time before you notice.

Something shifted, and nobody put it into words

AI hasn't made senior engineers faster. I want to be precise about that claim, because it's easy to misread. I'm not saying AI doesn't work, or that the code it produces is bad. Neither is true, at least not in the simple version.

AI has changed where our work happens, and the new location of the work is more expensive for humans than the old one.

Before AI-assisted coding, a typical day as a senior engineer looked roughly like this. Maybe 80% of my active hours were spent writing (designing, typing, debugging small pieces, looking things up, writing again). The other 20% or so was reviewing, which meant reading teammates' PRs, auditing my own diff before commit, and scanning logs. The writing was slow. That was the cost. But the writing also built my mental model of the codebase, for free, as a byproduct of the act itself. By the time a feature shipped, I knew the code, because I had lived inside it for days. Review at the end was a light final tax.

Post-AI, that ratio has flipped. I'd estimate my current split is closer to 20% prompting and 80% reviewing. And the writing, the part that used to build comprehension as a byproduct, has been largely automated away. What remains is the reviewing, but now it's reviewing code I didn't write, often spanning twenty files I've never seen, faster than anyone was ever designed to read code.

From the outside, the output looks the same.

Why reading code is harder than writing it

Engineers often say they spend far more time reading code than writing it. In Clean Code (2008), Robert C. Martin put the ratio of time spent reading versus writing at "well over 10 to 1." That number is approximate, but every working engineer feels it.

Why is reading harder than writing? Because working memory is small.

The average human can hold roughly four distinct chunks of information in working memory at once, a lower estimate than George Miller's older "seven, plus or minus two." Cognitive load researchers, building on the foundational work of John Sweller in the late 1980s, have established that when the cognitive demand of a task exceeds available working memory, comprehension collapses. You can still scan the words. You just stop building an accurate model of what they mean.

When you write code, you construct the mental model yourself, piece by piece, and each new piece slots into a model you've already built. The cognitive load is distributed over time, and every line you type is also a rehearsal of the structure you're building. When you read unfamiliar code, you have to construct that same mental model from scratch, in reverse, while simultaneously absorbing the next few lines that depend on what you haven't yet fully processed. Reading unfamiliar code requires active reconstruction under working-memory pressure.

This is exactly the mode AI-assisted coding forces us into, at volumes we weren't designed to handle. And it's why the fatigue feels different from the fatigue of the pre-AI era, because it is different. It's the tired of working memory thrashing for eight hours, which is a different thing from having worked too hard.

The data is starting to catch up

If this were only subjective, I'd hesitate to make the argument. But the evidence is starting to accumulate, and the numbers are sharper than most people realize.

In July 2025, METR, a research group studying AI's real-world impact on work, published a randomized controlled trial that should have landed louder than it did. They recruited sixteen experienced open-source developers, each with multiple years of contribution history on large, mature repositories. Each developer brought real issues from their own projects. Tasks were randomly assigned to "AI allowed" or "AI not allowed." The developers used the frontier tools of the time, primarily Cursor Pro with Claude 3.5/3.7 Sonnet.

Before starting, the developers predicted AI would make them roughly 24% faster. Machine learning and economics researchers surveyed ahead of the study forecast even larger speedups.

The actual result: developers were 19% slower when using AI.

The more unsettling finding is what they believed after the study ended. Even having lived through the slowdown, the developers still reported that AI had made them about 20% faster. In this study, the gap between perceived and measured speed was roughly forty percentage points. We are systematically wrong about our own productivity, and wrong in the direction that hides the cost from ourselves.

A separate line of evidence comes from GitClear, which analyzed over 211 million lines of changed code between 2020 and 2024. Their findings track the same trend from a different angle. Copy-pasted lines climbed from roughly 8% of all changes in 2020 to 12% in 2024. The share of refactored ("moved") code, traditionally a marker of thoughtful reuse and good architecture, collapsed from around 24% to under 10% in the same period. Code churn, the percentage of lines rewritten within two weeks of shipping, nearly doubled.

Read together, those numbers point one way. We're producing more code, reusing less of it, rewriting it sooner, and misjudging whether it saves us time. The review surface has ballooned while the cognitive budget stayed the same. That gap is where the new exhaustion comes from.

Owning the Diff: a four-practice system

None of this is an argument for using less AI. I use AI daily. I'd fight anyone who tried to take it away. The productivity is real, just not in the shape we thought, and not without new disciplines to match the new mode of work.

Over the past eighteen months, I've built a system for keeping review debt manageable while still getting a lot out of AI. I call it Owning the Diff. It's four practices. Each one is a direct response to a specific failure mode I kept falling into.

1. The Out-Loud Rule

Before I accept any AI-generated block, I explain what it does, out loud or in a short comment. Sometimes it's a message I send to myself in Slack. If I can't explain it, I don't count it as reviewed.

This is the most important practice of the four, because it attacks the core illusion of AI-assisted work, the idea that reading equals understanding. Reading is a visual activity, and understanding requires active reconstruction. When we typed every character ourselves, that reconstruction happened automatically, and now it's a separate step I have to remember.

Say AI generates a function. I glance at it, it looks reasonable, and then I stop. I write a one-line comment above it explaining what it does in my own words. If writing that comment feels effortful, that's diagnostic information. My understanding was thinner than I assumed. Time to actually read the function.

If I catch myself about to accept a diff with the thought "I'll understand it when I need to," that thought is always a lie. I'll need to understand it when something breaks at 11pm on a Friday, and it's easier to build the model now, while the code is fresh and the stakes are low.

2. Review as Stranger

I treat every AI diff as if a contractor wrote it. That puts me in a different frame of mind, and I scrutinize it differently.

The trap here is subtle. Your name ends up on the commit. And because the tool is integrated into your IDE, the workflow feels continuous with your own typing. So your brain, reasonably, tags the output as "mine" and skips the rigor you'd apply to a teammate's PR.

But your brain didn't build it. You didn't struggle against the type system until it made sense, and you didn't choose between three implementations and pick one for a reason. As far as your comprehension goes, the code is someone else's, so review it that way. Look for the things you'd call out if your junior teammate had submitted it. You'll find them: the off-by-ones, the swallowed exceptions, the import that pulls in a 400KB dependency for a one-liner. AI makes all of those mistakes. You just stop seeing them because your brain has filed the code under "mine, already approved."

3. Bounded Sessions

I cap any single AI-assisted push at roughly three files or two hundred lines. Then I stop. I run the code. I read what was produced. I make sure I understand it. Only then do I continue.

This is the hardest practice to actually follow, because unbounded generation is fun. You can feel yourself making progress as the code piles up and features appear on screen. It's only on Thursday afternoon, when you're staring at a change set you can't reconstruct, that the cost becomes visible.

The pre-AI workflow had natural rhythm built in for free. Typing is slow. Compiling forces pauses. Debugging imposes breaks. You couldn't generate 500 lines in 15 minutes even if you wanted to. AI removed that rhythm entirely. If you want it back, you have to put it there deliberately: a hard stop, a rerun, a moment of comprehension, and only then permission to continue.

4. The Slow Lane

One day a week, or one project, or one particular module, I write without AI at all, because I need at least one part of my codebase where my mental model is complete.

That part of the codebase becomes my reference point. When something feels off elsewhere, like a weird bug or a behavior that surprises me, I can trust my instincts because I have a calibrated baseline. Without the Slow Lane, you eventually lose the ability to tell good from off. You stop being able to smell bugs before they bite. Your judgment goes soft, and you can't detect it from the inside, because you'd need those same skills to notice.

This practice is maintenance work, even if it sounds precious. It keeps you from slowly becoming dependent on tools you can't audit, and by extension, from becoming an engineer whose judgment can't be trusted on the things that matter most.

The skill that compounds

Prompting is getting easier every month, and so is picking a model or learning the latest AI-native framework, because the tools keep getting cheaper and more standardized. I expect those skills to commoditize within a year or two.

The scarce skill, going forward, is reviewing with judgment, at the speed AI now ships things to you. It has to be built inside a human brain the slow way, through thousands of hours of paying attention.

Looking back, the tired I felt that Friday was a sign of a real mismatch between how much AI can produce in a morning and how much a human can meaningfully absorb in one.

References & further reading

On AI's measured impact on developer productivity

• Becker, J., Rush, N., Barnes, E., & Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR. Randomized controlled trial with sixteen experienced open-source developers showing a 19% slowdown while participants still felt faster. METR summary and arXiv paper.
• GitClear. (2025). AI Copilot Code Quality: 2025 Look Back at 12 Months of Data. Analysis of 211 million changed lines showing rising copy-paste, falling code movement, and higher churn. Read the report.

On cognitive load and working memory

• Sweller, J. (1988). Cognitive load during problem solving: Effects on learning. Cognitive Science, 12(2), 257-285. Foundational paper on cognitive load theory and working-memory limits. Wiley abstract.
• Miller, G. A. (1956). The magical number seven, plus or minus two: Some limits on our capacity for processing information. Psychological Review, 63(2), 81-97.
• Cowan, N. (2001). The magical number 4 in short-term memory: A reconsideration of mental storage capacity. Behavioral and Brain Sciences, 24(1), 87-114.

On reading vs. writing code

• Martin, R. C. (2008). Clean Code: A Handbook of Agile Software Craftsmanship. Source of the "well over 10 to 1" reading-to-writing ratio commonly cited by engineers.