Cognitive debt: The hidden risk in AI-driven software development
How cognitive debt shows up in practice and early mitigation strategies.
Welcome to the latest issue of Engineering Enablement, a weekly newsletter sharing research and perspectives on developer productivity.
Last week we held our first-ever DX Annual event in San Francisco, bringing together nearly 500 engineering and platform leaders for a full day focused on developer productivity and AI. Thank you to everyone who joined us. Session recordings will be available in the coming weeks.
Abi: This week we have a guest post from Dr. Margaret-Anne Storey, a Professor of Computer Science and a Canada Research Chair in Human and Social Aspects of Software Engineering. Margaret-Anne is one of the most widely published researchers on developer productivity, having co-authored the SPACE and DevEx frameworks amongst many other works.
Margaret-Anne: Earlier this year I published two posts exploring how generative and agentic AI may be quietly shifting where the most significant risks in software development lie, away from technical debt and code quality, and toward something harder to see and measure: the erosion of shared understanding across teams. This is what I refer to as cognitive debt. The response to these posts surprised me, as practitioners confirmed that cognitive debt was a significant challenge they were facing. They also proposed concrete suggestions for recognizing and mitigating cognitive debt. I’m combining both posts below, with light edits, as they tell a connected story.
For readers who want to go deeper, two papers extend these ideas. In Theory of Troubleshooting, co-authored with Arty Starr, we ground the cognitive debt concerns in cognitive science, showing how making sense of unexpected system behavior places considerable demands on working memory and attention, and how prolonged troubleshooting leads to cognitive fatigue with real implications for developer well-being. In From Technical Debt to Cognitive and Intent Debt I propose a Triple Debt Model that adds a third dimension to this framework: intent debt, the erosion of externalized rationale that both developers and AI agents need to work with to safely maintain and evolve a codebase.
How generative and agentic AI shift concern from technical debt to cognitive debt
The term technical debt is often used to refer to the accumulation of design or implementation choices that later make the software harder and more costly to understand, modify, or extend over time. Technical debt nicely captures that “human understanding” also matters, but the words “technical debt” conjure up the notion that the accrued debt is a property of the code and effort needs to be spent on removing that debt from code.
Cognitive debt, a term gaining traction recently, instead communicates the notion that the debt compounded from going fast lives in the brains of the developers and affects their lived experiences and abilities to “go fast” or to make changes. Even if AI agents produce code that could be easy to understand, the humans involved may have simply lost the plot and may not understand what the program is supposed to do, how their intentions were implemented, or how to possibly change it. Where cognitive load is what developers experience in the moment, cognitive debt is a project-level property, capturing how a team loses understanding over time.
Cognitive debt is likely a much bigger threat than technical debt, as AI and agents are adopted. Peter Naur reminded us some decades ago that a program is more than its source code. Rather a program is a theory that lives in the minds of the developer(s) capturing what the program does, how developer intentions are implemented, and how the program can be changed over time. Usually this theory is not just in the minds of one developer but fragments of this theory are distributed across the minds of many, if not thousands, of other developers.
I saw this dynamic play out vividly in an entrepreneurship course I taught recently. Student teams were building software products over the semester, moving quickly to ship features and meet milestones. But by weeks 7 or 8, one team hit a wall. They could no longer make even simple changes without breaking something unexpected. When I met with them, the team initially blamed technical debt: messy code, poor architecture, hurried implementations. But as we dug deeper, the real problem emerged: 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. The code might have been messy, but the bigger issue was that the theory of the system, their shared understanding, had fragmented or disappeared entirely. They had accumulated cognitive debt across their team faster than technical debt, and it paralyzed them.
This dynamic echoes a classic lesson from Fred Brooks’ Mythical Man-Month. Adding more agents to a project may add more coordination overhead, invisible decisions, and thus cognitive load. Of course, agents can also be used to manage cognitive load by summarizing what changes have been made and how, but the core constraints of human memory and working capacity will be stretched with the push for speed at all costs. The reluctance to slow down and to do the work that Kent Beck calls “make the hard change easy” is what will lead to cognitive debt and cognitive load in the future.
In a breakout session at a recent Future of Software Engineering Retreat (arranged by Martin Fowler and Thoughtworks) we discussed how developers need to slow down and use practices such as pair programming, refactoring, and test-driven development to address technical debt AND cognitive debt. By slowing down and following these practices, cognitive debt can also be reduced and shared understanding across developers and teams rebuilt.
But what can teams do concretely as AI and agents become more prevalent? First, they may need to recognize that velocity without understanding is not sustainable. Teams should establish cognitive debt mitigation strategies. For example, they may wish to require that at least one human on the team fully understands each AI-generated change before it ships, document not just what changed but why, and create regular checkpoints where the team rebuilds shared understanding through code reviews, retrospectives, or knowledge-sharing sessions.
Second, we need better ways to detect cognitive debt before it becomes crippling. Warning signs include: team members hesitating to make changes for fear of unintended consequences, increased reliance on “tribal knowledge” held by just one or two people, or a growing sense that the system is becoming a black box. These may be signals that the shared theory is eroding.
Finally, this phenomenon demands serious research attention. How do we measure cognitive debt? What practices are most effective at preventing or reducing it in AI-augmented development environments? How does cognitive debt scale across distributed teams or open-source projects where the “theory” must be reconstructed by newcomers? As generative and agentic AI reshape how software is built, understanding and managing cognitive debt may be one of the most important challenges our field faces.
I explored these questions further in a recent keynote at the ICSE Technical Debt Conference and Panel. Cognitive debt tends not to announce itself through failing builds or subtle bugs after deployment, but rather shows up through a silent loss of shared theory. As generative and agentic AI accelerate development, protecting that shared theory of what the software does and how it can change may matter more for long-term software health than any single metric of speed or output.
Discussion: What I’m hearing about cognitive debt (so far)
After publishing the original post (above) on cognitive debt, it sparked thoughtful discussion across different communities. I’ve synthesized what I’m hearing below, and am connecting it to other reflections I’ve been reading.
There’s a growing concern about shared understanding
Several practitioners, including Simon Willison and others on a Hacker News discussion of a Martin Fowler article, describe experiencing cognitive debt directly. They talk about getting lost in their own projects and finding it harder to confidently add new features. They can move faster, but they lose the deeper sensemaking that connects decisions to intent, and intent to code.
This is not just about code quality. It is about whether individual developers and product teams can maintain a coherent mental model of what the system is doing and why.
Across these discussions, one theme is consistent: velocity can outpace understanding.
Cognitive debt hurts developers, not just the software
Technical debt lives in the code. Cognitive debt lives in people.
When shared understanding erodes, the pain shows up in:
Loss of confidence when making changes
Heavier review burden
Debugging friction
Slower onboarding
Stress and fatigue
The software may be “working”, but the theory of the system becomes harder to access and keep track of. The cost is not only structural. It is experiential.
Siddhant Khare has written about AI fatigue. Steve Yegge reflects on burnout emerging from AI-accelerated development. Annie Vella eloquently writes about the emotional and cognitive experience of uncertainty when systems become harder to reason about. These perspectives reinforce that this is not just an engineering discipline issue, but one that affects how developers feel and function.
Cognitive debt, like technical debt, must be repaid
Martin Fowler notes that, like technical debt, cognitive debt must eventually be repaid. I agree.
But rebuilding lost knowledge requires restoring the distributed theory of the system. That includes capturing intent, the rationale behind decisions, key constraints, and how the architecture supports change. That theory is not stored in code alone. It is distributed across people, documentation, tests, conversations, tooling, and increasingly, AI agents.
Repayment means maintaining all of these, not just refactoring code or updating architecture documents. Under pressure to move quickly, whether in startups racing to learn or in large organizations pushing AI adoption, that repayment can feel expensive and easy to defer.
“This is just engineering”, but incentives are changing
Several commenters, including Michael Würsch, argue that cognitive debt reflects a failure of good engineering discipline. Clear specifications, rigorous reviews, extensive testing, and explicit architecture documentation should prevent knowledge loss.
In principle, I agree. But in practice, the incentives are shifting. AI lowers the cost of producing structure. It becomes easier for structure to evolve faster than shared understanding can stabilize. Even disciplined teams must consciously throttle or shape their practices to keep understanding aligned with change.
Specifications and documents are not sufficient if they are not living artifacts that teams actively engage with.
Emerging mitigation strategies
Encouragingly, many readers shared how they are mitigating cognitive debt.
They describe:
More rigorous review practices
Writing tests that capture intent
Updating design documents continuously
Treating prototypes as disposable
Some also describe using AI to reduce the cost of these practices, and even to support cognitive tracking, dependency management, and explanation.
Used deliberately, AI may help make cognitive work more visible rather than obscuring it.
The open question: How will high-performing teams adapt?
High-performing teams have always managed technical debt intentionally. As AI is adopted by startups and large companies, the question becomes how teams will manage cognitive debt.
How will they shape socio-technical practices and tools to externalize intent and sustain shared understanding? How will they use Generative and Agentic AI not only to accelerate code production, but to maintain their collective theory?
As AI reduces technical friction, shared understanding may become the bottleneck on performance.
I am continuing to watch how this evolves. If you are seeing mitigation practices that work in real teams, I would love to learn from them. As mentioned above, check out the article that goes deeper into how to recognize and mitigate cognitive debt and also proposes using the concept of intent debt to capture when decisions and the why behind a system are not captured for future humans and agents to refer to.
This week’s featured DevProd job openings. See more open roles here.
Cashea is hiring an Infrastructure & Developer Productivity Platform Engineering Manager | Remote
BNY is hiring an SVP, Application Development Manager | Pittsburgh, PA
Figma is hiring a Staff Software Engineer, Developer Experience | Remote; US
Leidos is hiring a Platform Engineer | Remote; US
Reddit is hiring a Staff Software Engineer, Developer Experience | Remote; US
Weave is hiring a Senior Platform Engineer, Data Infrastructure | Remote; US
That’s it for this week. Thanks for reading.
 | A guest post by
|
How is DX thinking about introducing new metrics, snapshot questions, or other methods of monitoring and assessing cognitive debt given how subjective it seems to be, and how many different (and potentially disparate) aspects of the developer experience it touches?
I like this concept a lot. It resonates with Carl Bereiter's extensive literature on knowledge building which is influential in educational psychology https://en.wikipedia.org/wiki/Knowledge_building.
It also resonates with Keith Stanovich's work on thinking dispositions and mindware https://www.keithstanovich.com/Site/Books.html
It also resonates with my Cognitive Productivity framework. As AI makes knowledge generation increasingly cheap, the bottleneck shifts toward organizing, evaluating, retrieving, and ultimately applying knowledge effectively. The article focuses on preserving shared understanding within software teams, but I think the underlying challenge is broader: cognitive productivity depends not simply on creating knowledge, but on ensuring that people can reliably use it when it matters.
One aspect this article touches on but doesn't fully explore is what I call the meta-access problem: knowing that relevant information exists but being unable to access it quickly enough, or in the right context, to make use of it. Documentation, design rationale, meeting notes, issue tracker entries, AI chats, and conversations only reduce cognitive debt if they remain readily accessible at the moment of need. That's the motivation behind my Surf Strategically principle and behind our Hookmark app, which supports contextual information retrieval by maintaining links among the diverse information resources that knowledge workers rely on. I discuss this in more detail here: https://luccogzest.substack.com/p/contextual-information-retrieval.