IN BRIEF
Agentic delivery is widening the gap between what AI systems produce and what people in the organization understand. Almost nothing we report today, from token consumption to adoption rates, shows it, so it tends to surface during budget reviews, when no one can say what the money bought, or during incidents, when the people on call can’t explain what went live.
To keep it under control, record the intent behind the work before an agent starts, so reviewers have something to check against, and spend can be tied to an outcome.
From technical debt to cognitive debt
Every IT leader understands technical debt.
You take a shortcut today on a software fix you don’t want to do because it will delay the project, or you keep legacy infrastructure that is expensive to replace. Still, you know you pay interest later in maintenance, security, and compliance issues, or in a larger bill to refresh the whole system. It lives beyond custom code, in packaged software and infrastructure kept past the point of safe upgrades, and in the integrations nobody wants to touch. The concept is well understood because the cost eventually shows up somewhere you can measure.
We are now facing a new kind of debt generated by agentic AI and the speed at which we are introducing and developing new systems through it.
Cognitive debt is the growing disconnect between what AI systems produce and what the organization understands. Technical debt concerns a system’s condition, while cognitive debt concerns organizational understanding, and they can move in opposite directions.
The irony is that AI may help you reduce technical debt by refactoring, but if fewer people understand how it was done and just see the result, cognitive debt grows.
That is what makes cognitive debt more dangerous. Technical debt lives in the system, where you can eventually find and measure it. Cognitive debt lives in the gap between a working system and the people who know what it does but not how, which is exactly where nobody is currently looking.
Cognitive debt takes four forms
I have been categorizing cognitive debt in four forms. Most of the time, I have seen teams that use agents seriously are accruing all four at once.
The first is opaque output.
An agent generates something that works, passes its tests, and deploys cleanly. A reviewer reads it, or doesn’t, and the logic seems right, so it gets approved. All seems fine. But if you look into what is really happening, you will find a much different picture. Veracode’s 2026 GenAI Code Security Report measured the risk in exactly this situation. Across more than 100 models, generated code is now syntactically correct almost every time. Still, the average security pass rate is 56%, barely up from 55% in their first report, and about 44% of the generation tasks in their tests produced a known vulnerability.
The gap between code that works and code that is safe is not closing. Here, the debt isn’t the flaw itself, but the fact that we don’t understand the output well enough to catch it. For example, after a run of incidents this year that internal documents linked in part to AI coding tools, which Amazon attributes to user error, the company now requires a senior engineer to sign off on AI-assisted changes. In effect, it is paying down this form of debt by hand.
The second is intent that was never recorded.
When a feature can be described in a sentence, often drafted with an AI assistant, and another agent builds it, the reasoning behind it is usually never captured. We can state what the idea was and ground it in an ADR or Spec, but the agents will understand only what is written, not the in-between lines of discussion that the developers had during sprint planning, or the request sent by the product manager through a Slack or Teams chat that never made it into the spec. If the developer wasn’t good at documenting in the pre-AI era, are you sure the spec they write, or pass to the AI, captures everything needed for the build?
Months later, when something must change, no one remembers what a function, or perhaps the system, was meant to do or why it was built this way. That understanding lasted only as long as one prompt, then evaporated.
The third is judgment that atrophies from disuse.
This is the quietest and most serious form, and the one companies’ standards and tooling have barely begun to address.
If you no longer use a skill, it goes unexercised and declines. As engineers shift from writing the hard parts of the software to inspecting what an agent has written, the insight that comes from building things erodes.
In January, Anthropic published a small randomized trial in which developers learning a new library with AI help scored 17% lower on a follow-up test than those who coded by hand, with the widest gap in debugging. Just a reminder: this is a study from a company that sells AI, but it points to the same issue.
The erosion is invisible on a normal day, when we are rushing to meet timelines, and it will surface during a production incident, when the on-call person opens a file they have owned for months and realizes they never really understood it.
The fourth is spending that cannot be connected to outcomes.
Uber spent its entire 2026 budget for AI coding tools in four months, after an internal leaderboard ranked teams by how much AI they used. The organization got exactly what it rewarded, and its COO later said he still couldn’t draw a line from that spending to features customers found useful.
Uber is not alone. In Pigment’s survey of 2,000 finance leaders this autumn, 83% said consumption-based AI costs had gone over budget. The economics underneath are interesting, because the price of equivalent model capability has collapsed.
The Stanford AI Index measured a fall of more than 280x in the price of GPT-3.5-level performance between late 2022 and late 2024. Meanwhile, US enterprise spending on generative AI more than tripled to $37 billion in 2025, according to Menlo Ventures, because consumption grew far faster than unit prices fell.
The cost story is real, but it is just a symptom. We measured the activity properly, but we barely understood the value it delivered.
Cognitive debt stays invisible because we measure activity
Cognitive debt accumulates without detection because almost every commonly used metric points to the wrong thing. Token consumption, deployment frequency, adoption rates, and code volume all measure activity. None of them measures understanding or value. So a team can post record numbers on all metrics while the comprehension of its own systems quietly declines.
The failure mode worsens when the metric becomes a target tied to a bonus package, as happened at the companies now capping their AI spend. When burning tokens becomes a proxy for working hard or an indicator of modernity, the organization optimizes for what has almost nothing to do with whether anyone understands what it’s building.
Technical debt at least has a feedback loop. The system eventually slows or breaks, and the risk or pain forces attention. Cognitive debt has no such loop because its symptom is confidence. Everything looks fine until the moment it doesn’t.
The industry developed protocols and reference architectures to put agents into production reliably, or at least in a managed harness so that they can set some controls. System reliability is necessary but not sufficient, because a perfectly reliable agent can still produce output no human understands, and an ecosystem of interoperable agents can spread that gap faster than any single team can close it.
For example, we’ve seen extreme cases making the news. In July, agents running an internal OpenAI security evaluation escaped their sandbox and broke into Hugging Face’s production systems to find the benchmark’s answers. They had a sandbox and a defined task, and Hugging Face noticed the intrusion before OpenAI did.
Intent-driven engineering
The response I want to argue for is a discipline I call intent-driven engineering. To explain it, it helps to compare it with three approaches it is often confused with, because the differences come down to where the essence lives.
Prompt-driven development is where most teams start. The human writes a prompt, the agent produces output, and the result’s quality depends almost entirely on the request’s phrasing. The intent exists only in the prompt and disappears with it. Nothing is recorded, nothing is reusable, and understanding lives with whoever typed the request.
Context-driven development improves on this by giving the agent relevant material, such as the codebase, documentation, prior decisions, or retrieved knowledge. This is much of what current tooling and protocols optimize, and it really produces better output. But better context improves what the agent receives, not what the human retains. You can have rich, well-structured context flowing into an agent and still have no human who understands the result.
Spec-driven development goes further by writing down what the system should do before building it. This is a real improvement, and it is where much current thinking stops. But specifications have a long history of describing behavior while leaving out the reasoning behind it. Waterfall projects had exhaustive specifications, and anyone who worked on them knows why we avoid them, unless there is no other way around it. A spec can tell you what the output should be while leaving unsaid why it should be in that way, what it must never be, or how anyone will know that it actually worked under conditions the author did not anticipate.
Intent-driven engineering makes human reasoning a persistent input rather than a disposable one. Before generation, the owner of the work sets out four layers and keeps them attached to the work afterward.
Context: what system the work belongs to and what constraints it already holds.
Intent: the business outcome the work is meant to achieve, stated precisely enough that output which merely looks plausible cannot satisfy it.
Desired outcomes: how anyone reviewing it will know it worked, including behavior under adverse conditions and not just the happy path.
Unit of measurement: a clear way to check whether the outcomes meet the quantitative or qualitative measures tied to a cost unit.
This shift asks for clarification rather than reinvention. The work is the same, but defining and carrying intent becomes explicit rather than assumed and then lost.
Each layer maps to a form of cognitive debt. Persistent context makes output interpretable, because it was generated against a known frame. Recorded intent makes the reasoning survive past the prompt. Explicit desired outcomes give reviewers something concrete to validate against, which keeps their judgment engaged, and one rule for judgment complements it, requiring the person who owns the work to write the test for success before seeing the agent’s output. The unit of measurement is what connects spend to an outcome.
This also addresses the most common objection I found: that intent-driven engineering cannot make opaque generated code transparent. It cannot, and it does not claim to. What it changes is what the review validates against. In prompt-driven work, the reviewer reads output with no stated reference for what “correct” and “safe” would even mean. Stated intent and desired outcomes, including explicit constraints on what the code must never do, give both the agent and the human a contract to verify against. The generated code does not become self-explanatory. It becomes checkable because it finally has a definition of expected behavior to test against.
The connection to technical debt is worth stating precisely, because the two debts are easy to blur. Intent-driven engineering does not remediate the legacy systems an organization already carries. What it prevents is the silent creation of new technical debt, because constraints that would otherwise be discovered after the fact, such as “must integrate with this”, “must not duplicate that,” or “must follow this standard”, are stated before generation rather than found in an incident review six months later.
The bigger change is in what gets measured. When intent is expressed as the business outcome the work exists to produce, and that outcome is carried through to validation, the measured result is no longer the number of tokens consumed. It is whether the outcome was achieved. That is what finally makes the spend legible. An organization that can connect a unit of AI consumption to a defined and validated outcome can answer the question every organization’s leadership wants answered: what did the tokens actually produce?
Intent has to live where agents can reach it
Even if intent-driven engineering stays a discipline that good teams practice, it will not survive an ecosystem of interoperable agents calling each other across tools and organizations without proper automated controls. The moment an agent invokes another agent, or output crosses multiple tools owned by different teams or spans identity boundaries, hand-maintained intent will fall away, and the cognitive gap reopens. The question is where intent, context, and desired outcomes should live so they travel with the work rather than being reconstructed at each step.
Today’s architecture is mostly a static artifact in any enterprise. It is written down, reviewed, approved in an ARB, and then forgotten, aging while the system it describes moves on.
The version I support treats architectural intent as something an agent continuously evaluates as part of intent-driven engineering. Regulatory constraints such as DORA or the EU AI Act, security baselines, and target-state architecture guidelines become an active layer where generation is checked as it happens, rather than criteria a human applies in a review weeks later, if at all. Architectural drift becomes detectable as it happens, and the architect’s role moves upstream, from periodic auditor to the person who authors the policy that governs generation and is accountable for it.
You can incorporate the four layers of intent-driven engineering in multiple ways; no hard rule mandates a specific approach. It must be tailored to your needs and software engineering or infrastructure-as-code practices. It doesn’t have to be disruptive, but it does require a mindset shift.
For example, I had teams integrating each layer as skills in their AI coding tools, using hooks to trigger validation as control gates before committing any code. Other teams leveraged specifically designed agents with MCP and other connector integrations to update them over time and guarantee the latest policies and security controls are being used.
One important learning to follow is that for intent expressed as a policy to travel between agents across tools and organizational boundaries, it has to live somewhere durable, preferably reachable by the platforms teams build on.
Closing
Understanding is becoming a scarce resource in agentic delivery, and cognitive debt measures how much of it we give away. I believe intent-driven engineering, together with moving architecture from a static document to living policy, is how we keep it under control.
Where intent will live across your whole estate is a decision for later. The first step is small. Pick one workstream, write down its context, intent, desired outcomes, and unit of measurement before the next coding agent touches it, and review what comes back against them. After a quarter, you will know whether you got the outcome you paid for, and whether your team can still explain what was built.
If you want a quick check, I published a scorecard you can use for free when you subscribe to The Architect’s Ledger newsletter.
Sources
Fortune, Uber’s COO on AI spend, 26 May 2026
FM Magazine, Pigment Q3 CFO Index on AI overspending, 21 Oct 2026
Digital Trends, summary of Financial Times and Business Insider reporting on Amazon’s outages, 11 Mar 2026
Veracode, 2026 GenAI Code Security Report, 28 Jul 2026
Anthropic, How AI assistance impacts the formation of coding skills, 29 Jan 2026
Stanford HAI, AI Index 2025
Menlo Ventures, 2025: The State of Generative AI in the Enterprise, 9 Dec 2025
Adversa AI, the AI agent sandbox escape that breached Hugging Face