If you’re building software today, you’ve undoubtedly seen the conversations about “cognitive debt”. It’s the idea that, similar to tech debt, as we build with agents, our team is losing an in-depth understanding of our codebase.

The more conversations I have with builders, especially at startups, the more I’m convinced that the conversation is missing a huge piece: cognitive debt affects our coding agents too.

We spent twenty years putting processes in place to manage technical debt. We built frameworks for it, hired consultants around it, developed entire vocabularies to keep it from swallowing our codebases, and even rallied together to advocate for time/spend on it within our companies.

But when AI can generate code basically instantly (at least compared to before…), a new kind of debt is emerging: cognitive debt. The kind of debt that shows up when so much code is written that we don’t fully internalize all of its nuances anymore. We’re shipping code we don’t intimately understand.

However, we aren’t writing all the code or even doing the debugging when issues arise… our agents are. We’re providing input and direction on the design, architecture, and decisions that matter. When the code is a mess and nuances aren’t clearly communicated, the agents’ performance degrades too.

The two doom-scroll-worthy things that keep me up at night:

1. Unlike technical debt, cognitive debt is almost completely invisible to every metric you’re tracking.
2. Cognitive debt isn’t replacing technical debt. It’s happening in conjunction with it. Now we have more tech debt and less understanding… exponentially worse!

The Numbers

GitClear’s latest analysis found an 8x increase in duplicated code blocks across AI-assisted repositories. CodeRabbit reports that AI co-authored pull requests carry 1.7x more major issues and up to 2.7x more security vulnerabilities than their human-authored counterparts. Meanwhile, 75% of technology leaders are projected to face moderate-to-severe debt problems this year.

I don’t think this is a surprise to most of us, we’ve seen these metrics before. But it still feels a bit weird… we do feel like we’re shipping faster. The slow down is happening because the shipped code has more bugs. Then, when we go to fix the bug, we don’t have the deep understanding we used to have. So it either takes us longer, or we ship a fix that was also not a sustainable fix… and then the snowball starts to roll down the hill.

If you’re cautiously optimistic about AI use in software development (I am), then its also helpful to consider what this means in more autonomous coding workflows. The messier a codebase is, the more risk of confusion for the coding agent. If the agent gets confused, it will either be unable to fix the problem, or spin its wheels wasting time and tokens trying. Once it fixes it, now there’s even more messiness and things get more expensive and brittle over time.

If you have a complex system where agents are looking at more than just one codebase, this compounds because confusion in one domain will seep into others.

It’s the combo of tech debt and cognitive debt that should really scare us.

Technical Debt Lives in the Code. Cognitive Debt Lives… Everywhere?

Technical debt was historically a conscious tradeoff… you chose the shortcut, you know roughly where it lives, and you can schedule the paydown. Tests still pass, but the tradeoffs were discussed in your team meeting and everyone is on board during code review.

Cognitive debt is different. As Google’s Addy Osmani wrote in his influential post on “comprehension debt,” it’s the growing gap between how much code exists in your system and how much of it any human genuinely understands. I’d argue that cognitive debt actually affects the agents too. Either way, this isn’t something we choose. Most of us would choose to have a deep understanding of how our code works. We’d choose to be able to seamlessly explore the code, making sense of code blocks with ease, being able to tie different pieces together.

Professor Margaret-Anne Storey, who coined the term “cognitive debt” in her widely-cited February 2026 blog post, described a student team she coached that could no longer make even simple changes without breaking something unexpected. They initially blamed technical debt, but the real problem was that no one on the team could explain why certain design decisions had been made or how different parts of the system were supposed to work together.

I think this is a good example to picture as if those students were agent acting autonomously… if the students can’t sort through things even with enough time, it’s going to be confusing for agents to do it too.

Again… the mix of tech debt and cognitive debt starts with seemingly silly issues and just snowballs from there.

Why Your Metrics Can’t See It

Simon Willison, one of the most respected voices in the developer community, described the problem from personal experience: he’d been prompting entire new features into existence without deeply reviewing their implementations, and found himself getting lost in his own projects… no longer holding a firm mental model of what they could do or how they worked.

If one of the most capable developers in the world is losing track of his own AI-assisted codebases, what’s happening inside your enterprise engineering organization? And if he’s the one orchestrating the agents who are getting confused… who comes to save the day?

Part of what’s dangerous here is that it’s not just about the degradation of maintainability and legibility… but that nothing in your current measurement system captures it.

I will note that DORA is catching up. The 2025 DORA report — rebranded as the “State of AI-Assisted Software Development” — added a fifth metric: rework rate, measuring how often teams push unplanned fixes to production. The report also surfaced a troubling finding they called the “AI Productivity Paradox”: AI assistants boost individual output (21% more tasks, 98% more PRs merged) but organizational delivery metrics stay flat. That paradox is cognitive debt in disguise. Individual velocity goes up. System-level comprehension goes down. The net effect on delivery? Zero.

Part of me wants to say “we can’t let this happen! ahh!” but a bunch of teams I’ve talked to, and even my own team… we’re ok with keeping a deep understanding of the system and building process to make sure that the agents stay within those defined boundaries.

So… what now?

The teams winning in 2026 aren’t just the ones generating the most code, but the ones that have reworked their entire workflow to account for the fact that agent-based code generation is basically instant.

We need to measure things like change failure rate broken down by AI-authored vs. human-authored changes, time spent reviewing and rewriting AI-generated code, system-level change traceability, and formalization and accessibility of context, architecture, and intent. Once you have this, you can identify the root cause of these failures and instead of playing whack-a-mole to fix the symptoms, you can apply a fix to the workflow so it doesn’t happen again.

Not only does this help combat cognitive debt by making the invisible context into first-class citizens, but it helps to prevent tech debt, build trust, and actually measure the ROI from your adoption of coding agents.

Cognitive debt is not the new technical debt. But it does compound with technical debt. And contrary to much of the conversation, we need to be worried about how these two things affect the agents too.