Cognitive Debt - The Hidden Cost of Letting Agents Do All the Building

Everyone at AI Engineer World’s Fair 2026 was celebrating productivity gains. Code volume up 861%. Agents handling entire feature branches. Engineers shipping in hours what used to take weeks. But the most interesting conversations happened in the hallways, where experienced practitioners were asking a quieter question: what are we losing?

Not code quality - agents are getting better at that. Not velocity - obviously. What we’re losing is the thing that makes senior engineers valuable in the first place: deep, fluid understanding of the systems they build. The kind of understanding that lets you see a creative opportunity three abstractions away, or spot an architectural dead-end before your team spends a quarter walking into it.

Margaret Storey coined a term for this that I think will stick: cognitive debt.

What Cognitive Debt Actually Is

Technical debt is well understood - shortcuts in code that compound over time. Cognitive debt is analogous but lives in your head. It’s the gap between what your system does and what you understand about how and why it does it. Every time an agent writes code you don’t deeply comprehend, that gap widens slightly. Let it compound long enough and you lose the ability to contribute meaningfully to the system’s evolution.

This isn’t hypothetical. I’ve seen it happen in my own workflow. An agent scaffolds a service, handles the edge cases, writes the tests. I review it, confirm it works, ship it. Three weeks later I need to extend that service and I’m starting from scratch - reading my own codebase like it belongs to someone else. The agent built it correctly. But I never built the mental model.

The key insight from Storey’s framing is distinguishing two types of understanding:

Understanding to verify - can I confirm this code is correct, handles edge cases, meets requirements? Agents are increasingly capable of doing this themselves through automated testing, formal verification, and self-review loops. The shrinking human role here is probably fine.

Understanding to participate - do I have rich enough conceptual models in my head to fluidly recombine ideas, spot patterns across subsystems, and generate the next creative direction without going back to an agent for every decision? This is where cognitive debt becomes dangerous.

The second type of understanding is what separates a senior engineer from someone who happens to have access to powerful tools. It’s what lets you walk into a design discussion and say “actually, if we restructure the event model this way, we get three features for free.” No agent prompts you to have that insight. It emerges from deep familiarity with the system’s shape.

Why This Matters More Than It Seems

Here’s the compounding problem. If you stop understanding your systems deeply enough to participate creatively:

• You can’t make good architectural decisions, because architecture is about trade-offs between concerns you need to hold in your head simultaneously
• You can’t mentor effectively, because you can’t explain the why behind decisions you didn’t fully internalize
• You can’t spot the creative opportunities - the novel recombinations that create outsized value
• You can’t lead technical teams, because leadership requires the judgment that comes from deep understanding

In short, you become a manager of agents rather than a technical leader. And while “manager of agents” might be a valid role, it’s not the role most of us signed up for - and it’s certainly not where the highest-leverage contributions come from.

The 861% increase in code volume makes this worse, not better. More code means more surface area you don’t understand. More subsystems whose interactions you can’t predict. More places where an architectural insight could save months of work - if only someone had the mental model to see it.

Three Countermeasures Worth Adopting

The good news: the conference surfaced practical countermeasures that teams are already using. These aren’t theoretical - they’re patterns emerging from practitioners who noticed the problem and built solutions.

1. Explanations as a Byproduct of Building

The simplest countermeasure: make your agents teach you as they work. After every coding session, have the agent produce explainer documents - not just what it built, but why it made certain choices, what alternatives it considered, and where the tricky parts live.

Anthropic’s Tariq demonstrated this with their internal tooling. His practice: after an agent completes a task, he asks it to quiz him about what happened. “Make sure I understand what I’m doing and can represent this work when creating a PR.” Not as a checkbox exercise, but as genuine learning - building the mental model that would have formed naturally if he’d written the code himself.

This flips the default. Instead of agents producing code and humans reviewing it (verification), agents produce code plus explanations and humans learn from them (participation). The cost is minimal - a few extra seconds of generation time. The payoff is maintaining the cognitive foundation that makes you useful beyond the current sprint.

Practical implementation: add a post-session prompt to your agent workflow. Something like “explain the key architectural decisions you made, what surprised you about this codebase, and what I’d need to understand to extend this work confidently.” Store these alongside your code. Review them before your next session in that area.

2. Micro-Worlds - Ephemeral Tools for Building Intuition

This was the most exciting pattern I saw at the conference, inspired by Seymour Papert’s Logo turtle from the 1970s. The core idea: agents can write code whose purpose is to help you understand code, not to ship.

Think about that for a moment. Code used to be expensive, so every line needed to earn its place in production. AI makes code cheap. Suddenly you can build throwaway visualizers, step-through tools, interactive simulations - all designed to build your intuition about a system, then be discarded.

Examples from the conference:

• An engineer built an ephemeral UI to scrub through an interpreter’s execution step by step, like a video timeline. Not shipped anywhere - just used to build understanding of how the interpreter handled edge cases.
• Instead of running a database migration blindly, another team had Claude build a game-like tool showing migration steps visually - what data moves where, what constraints apply when, what breaks if you interrupt at each stage.
• Custom debuggers generated on the fly for specific subsystems, showing the exact state transitions relevant to the bug you’re investigating.

These are micro-worlds - small, interactive environments where you can play with concepts and build intuition through exploration rather than passive reading. Papert showed in the 1970s that this kind of active exploration builds deeper understanding than instruction. Now we have the tools to generate these environments on demand, specific to whatever system we need to understand.

The connection to Alan Kay’s original vision is worth noting. Kay imagined computers as “Dynabooks” - tools that level up human understanding. For decades, the cost of building custom learning tools meant this vision stayed aspirational. AI-generated ephemeral code finally makes it practical. Your agent can build you a custom teaching tool for any concept, in seconds, tailored to your specific codebase.

3. Shared Spaces - From Solo Agent Sessions to Team Understanding

The third countermeasure addresses a social problem. When everyone has their own private agent sessions, understanding becomes siloed. You understand your agent-built components; your colleague understands theirs; nobody has the cross-cutting view that enables architectural thinking.

Notion showed early work on multiplayer agent collaboration - shared documents where teams and agents work together, building collective context rather than individual context. The idea is moving from 1:1 human-agent sessions to team-wide shared spaces where the conversation, reasoning, and decisions are visible to everyone.

This matters because understanding isn’t just an individual asset. It’s a team asset. The best architectural decisions come from people who understand multiple subsystems and can see connections between them. If agents fragment understanding into private sessions, you lose the collisions and cross-pollination that generate creative insights.

Practical implementation even without fancy tooling: share your agent session summaries in team channels. Do regular “show and teach” sessions where you walk through agent-built work with your team - not code review (verification), but knowledge sharing (participation). Make the learning visible and collective.

The Practitioner’s Responsibility

None of this means slowing down. The productivity gains from agents are real and refusing them is not a viable strategy. The point is that speed without understanding is a loan against your future effectiveness, and like all loans, it compounds.

The best practitioners I talked to at the conference had a specific discipline: they treated understanding as a non-negotiable output of every building session. Not just working code, but updated mental models. Not just shipped features, but deepened intuition about their systems.

This is a leadership issue as much as an individual one. If your team’s velocity metrics reward pure output without measuring understanding, you’re incentivizing cognitive debt accumulation. Eventually someone needs to make an architectural call, and nobody in the room has the mental models to make it well.

My takeaway: add “do I understand this well enough to extend it creatively without asking an agent?” as a personal checkpoint after every session. If the answer is no, that’s your signal to invest - build a micro-world, request an explanation, quiz yourself. The ten minutes you spend now saves you from becoming a stranger in your own codebase.

The agents aren’t going to slow down. But understanding still compounds too - if you invest in it deliberately. The engineers who maintain deep system understanding while leveraging agent productivity will be the ones making the decisions that matter. Everyone else will be reviewing PRs they can’t meaningfully improve.