Cognitive debt isn’t something AI invented. Software has always depended on reasoning that code alone can’t preserve, and for years we stored that missing theory in the heads of senior engineers. What AI changed is the economics: it lets us delegate work faster and deeper, which makes one question urgent. Where does the reasoning land once the work moves? Cognitive debt is what happens when that load leaves someone’s head and ends up nowhere traceable, checkable, or owned.
1. One word, two meanings, one old mechanism
“Cognitive debt” is being used for two related, but different, problems.
Kosmyna et al.’s MIT study looked at the individual. In an essay-writing experiment, participants using an LLM showed weaker neural connectivity, lower ownership of what they wrote, and more difficulty quoting their own work. The study is narrow, and the authors are careful about generalizing beyond that setting. But the failure mode is useful: hand off cognitive work without picking up something above it, and your own engagement can drop.
Margaret-Anne Storey uses the term at the software-system level. Her concern is shared understanding. A team can keep shipping while fewer people can explain why the system has its current shape, what assumptions are buried inside it, or what a change might break.
She has sharpened that idea since I first wrote this article. Her newer model separates technical debt in the code, cognitive debt in what people understand, and intent debt in what we captured outside their heads. That last distinction matters for AI-enabled engineering. Humans are no longer the only consumers of that captured intent. Agents need it too.
The mechanism underneath all of this is much older than AI.
Peter Naur described programming as theory building in 1985. The code is only part of what programmers create. They also build a theory of the problem, the decisions behind the solution, and the boundaries of safe change. Code can survive after that theory is gone. Anyone who has inherited a system from the one engineer who “knew how everything worked” has seen the result.
AI changes the economics of that old problem. We can delegate more work, much faster, and at a greater depth than before. That makes the destination of the theory more important.
With shallow AI use, much of that theory can stay in the engineer’s head. When the work happens inside a live AI session, reasoning can accumulate there and disappear when the session ends. Disciplined agentic delivery has a different goal: make enough of that theory survive in artifacts that the next human or agent can recover, question, and verify.
So AI can absolutely contribute to cognitive debt. What it did not invent is the mechanism.
The question I care about is where the theory lands after the work moves.
2. Individual scale: the load moves up a layer
Delegating implementation does not automatically reduce the cognitive work. It can change the level where that work happens.
Think about how a Ford mechanic relates to a Mustang. He did not wind the alternator coils, stamp the chassis, or assemble the transmission. He still needs to understand the car. Give him a symptom and he knows which systems might be involved, what to inspect, what a change could affect, and when something is wrong. He has technical command without manufacturing every part.
I think engineering is moving in that direction.
I do not need to be the author of every generated line inside a service. I do need to understand the service well enough to define what it should do, constrain the solution, challenge its design, and decide whether the result is safe to accept.
Runtime, payloads, business rules, dependencies, failure modes, cost, security boundaries. The unit of attention gets bigger. In my experience, that is harder work than writing the next class.
But the move is not automatic. An engineer can hand implementation to an agent and simply become a faster approver of generated code. Very little moved up in that case. The implementation work disappeared, and nothing substantial replaced it.
The alternative is to take responsibility for a larger piece of the system: its intent, behavior, trade-offs, boundaries, and acceptance.
The load did not disappear. It moved up a layer.
3. For decades, the theory lived in the senior engineer
Software teams have lived with Naur’s problem for decades. We just had a very human place to store the missing theory: the people who had been around long enough.
The senior engineer remembered why the obvious solution had failed three years earlier. The SME knew which business rule looked wrong in the code but was there for a reason. They remembered the rejected alternatives, the strange integration, and the warning that never made it into the diagram.
As long as those people stayed, the system worked. When they left, we discovered how much of the architecture had never been in the architecture documents.
We have always tried to capture more of it. Design documents, architecture views, C4 diagrams, ADRs, runbooks, comments. Some of those artifacts are excellent, and I still use them. The problem was never that documentation had no value. The problem was that delivery did not depend on it.
Code could ship while the ADR was stale. A design could change during implementation without anyone going back to the diagram. A decision made in a meeting could live for years in somebody’s memory because nothing in the build needed the rationale behind it.
So code became the durable record almost by default. It told the next engineer what the system does, but often very little about why it ended up that way.
AI makes another old habit more visible: document volume is almost free now. I can generate twenty pages of architecture documentation in minutes. That tells me nothing about whether those twenty pages contain the theory I will need six months from now.
The useful test is harder: can someone who was not in the room use what we captured to understand a decision, challenge it, and make a safe change? That test changes what documentation is for.
If an artifact only describes the work after the fact, it can still drift quietly. If the next step has to consume it, stale intent starts breaking the process itself.
Cognitive debt is what happens when the load moves out of someone’s head and lands nowhere traceable, checkable, or owned.
That is the opportunity AI created.
4. Disciplined agentic delivery pays the debt forward
4.1 Vibe coding loses the reasoning you needed to keep
Vibe coding is useful shorthand for a specific failure. I can work with an AI for hours, steer it through implementation, make good decisions along the way, and end with working code. Then I close the session.
The diff survives. A lot of the reasoning may not.
For disposable work, I do not care. For a system somebody has to understand and change a year from now, I do.
Disciplined agentic delivery changes where that reasoning lives. If I hand off a whole process, the decisions behind the work have to survive the handoff too. Plans, design decisions, and constraints become part of the work itself because another agent or human has to consume them later.
This is where that distinction becomes practical. Documentation that delivery does not depend on can drift silently. Artifacts the workflow has to consume can drift too, but now something downstream depends on them.
The difference is what survives after the session is gone. That is where the intent graph comes in.
4.2 The intent graph gives the reasoning somewhere to live
Once the reasoning has to survive the session, it does not have to live in one place.
Some of it belongs in the agent definition itself: the role, standing constraints, examples, and rules that should survive every run. Some belongs in the handoff between phases: the decisions, assumptions, constraints, and implementation details that are specific to this piece of work. Other parts may live in persistent memory or shared project context.
The important change is that code is no longer the only durable artifact left behind.
Before AI, much of the reasoning stayed in the engineer’s head while the code was being written. Documentation usually captured some of it later. In a disciplined agentic workflow, that reasoning has to become input again. The next agent needs it to continue the work.
One of my early implementations of this pattern was intentionally simple. I used files.
A human started with the Theme or Epic. A PO Agent turned that into plan.yml. An Architect Agent consumed the plan and wrote design.yml. A Developer Agent consumed the design, wrote the code, and added implementation decisions back into design.yml when implementation forced a change.
The sequence looked roughly like this:
Those YAML files were not meant to be a new documentation standard. They were simply the durable handoff mechanism available in that implementation.
They worked because they were structured and queryable. Categories, topics, decisions, and implementation notes could be pulled with yq for one module, one sprint, or one problem without putting the entire project history into the agent’s context.
More important, the agents consumed them.
The Architect Agent started from plan.yml. The Developer Agent started from design.yml. When implementation changed a design decision, the change went back into an artifact another run could consume.
After thirty-seven sprints, the repository contained thirty-seven pairs of plan and design artifacts:
sprints/
├── sprint-01/
│ ├── plan.yml
│ └── design.yml
├── sprint-02/
│ ├── plan.yml
│ └── design.yml
├── …
└── sprint-37/
├── plan.yml
└── design.yml
I called that chain a layered intent graph. The files were one implementation of the idea, not the idea itself. A different system could use a memory layer, a knowledge graph, a database, richer handoff contracts, or something that does not exist yet.
What matters is what survives and can be brought back into context.
In that implementation, the design stopped being something we hoped somebody would update after the code changed. It became part of what conditioned the next piece of work. The Developer Agent read it before writing code, and a reviewer could compare the implementation against the same intent.
The load had somewhere to land.
4.3 Captured intent can help rebuild the theory
Putting more reasoning on disk does not mean we captured everything that was in someone’s head.
Naur’s point still holds. A developer carries things that are difficult to externalize completely: domain intuition, rejected paths that never became formal decisions, warnings learned from production, and connections that only became obvious after living with the system for a while.
What changes is how much the next person has to reconstruct from code alone.
I saw this myself when I came back to the pipeline after time away. My first question to the agent was, “Where am I?”
The graph gave it the pieces that mattered for the current state: project instructions, backlog, recent plans and designs, and board state. Some of that intent was in the handoffs, some in the durable instructions around the agents, and some in the implementation history.
That was enough to rebuild a useful picture of the system and continue working.
Useful is not complete.
Some things still leak through: why an alternative was rejected before anyone wrote it down, the domain mapping somebody carried implicitly, or the small warning mentioned once during implementation. Worse, a reconstruction can sound complete even when one of those pieces is missing. That gap is the residual debt.
The best defense I found was to write discoveries from implementation back into the durable state. When the Developer Agent found that the obvious approach did not work, changed a design assumption, or discovered a constraint while coding, that information went back into design.yml instead of dying in the coding session.
Today I would not prescribe design.yml as the mechanism. The storage can change. The important part is the feedback loop: implementation produces new intent too, and that intent has to survive for the next reconstruction.
You cannot preserve the whole theory. You can leave much better material for rebuilding it.
4.4 Captured intent has to stay trustworthy
Reconstruction only helps if what you reconstruct is still true.
In my early file-based implementation, the current state of a module did not live in the latest design.yml. A module might have been touched in six different sprints, with later decisions replacing earlier ones. The history was useful, but the system also needed to know which decisions still applied.
That is a different problem from storing more information.
Whatever carries the intent needs some way to distinguish history from current state: what changed, what it replaced, what it depends on, and whether it still applies. Otherwise you can build an excellent memory of everything the project ever decided and still give the next engineer the wrong answer.
Ownership becomes part of the problem too. In Solo Mode, one operator owns the state, so that ownership is mostly implicit. In Scaled Mode, several operators can change the same state, and somebody has to own how conflicting decisions are reconciled, which constraints are authoritative, and when old intent is retired.
And some intent can go one step further. It can become checkable.
In one agentic pipeline I built, we had a simple architectural rule: money uses a decimal type, never a float. That decision did not live only in prose. The reviewer agent checked it on every sprint, and the pipeline failed when the implementation violated the rule.
Most architectural decisions cannot be reduced to a lint rule, and most of mine were still prose. But whenever a decision can become a type, schema, test, lint rule, or gate, a disagreement between intent and implementation becomes visible during the work instead of months later.
The storage mechanism will keep changing. The requirement does not: important intent has to remain current, owned, and checkable.
5. The engineering question is where the load lands
AI does not decide what has to move with the work. That is still our job.
So the practical question I would ask at the end of a sprint is simple: where did the load land?
If the reasoning lives only in a session that will disappear, or in generated documentation that nothing downstream consumes, we are accumulating debt. If enough of it survives in durable instructions, handoffs, current project state, constraints that can be checked, and something with a named owner, the next human or agent has something they can recover, question, and verify.
In that early pipeline, the test was very concrete. If I left the project for six months, an agent could help me resume by reading the current project state and walking the relevant chain of plan and design entries. The YAML was not the point. Being able to recover enough of the reasoning to continue was.
There will still be residual debt. We cannot preserve the whole theory, and no memory framework or intent graph changes that. The goal is to stop leaving the important parts nowhere.
AI makes it cheap to move the work. Engineering is deciding what must move with it.
