Cognitive debt: when AI writes faster than we can understand

Daily standup. A colleague says: "My pull request is done, ready for review." When asked "How did you solve the problem?", the answer is noticeably hesitant. This is not because the developer lacks competence, but because a good part of the code was produced by an AI agent. The developer has not traced in detail how the feature was actually implemented and how the problem was solved.

There is a technical term for this phenomenon: cognitive debt. It refers to the growing gap between how a software system is actually implemented and how well the engineer who built it still understands that implementation. This gap is not new. It existed long before generative AI, whenever knowledge went undocumented or ownership of the code was unclear. What is new in the age of AI is the pace: cognitive debt now accumulates faster and in larger quantities.

The reason is banal but powerful: historically, writing code automatically meant understanding it. You had to type every line yourself, think through every edge case yourself, find every bug yourself. That built-in forcing function disappears when an agent produces the code. You get the result: fast, often syntactically flawless, and even complete with matching tests. Only the thought process is missing, the one that used to come along for free.

The scenario described at the beginning is not an isolated case. It is the norm whenever code is adopted without being questioned. And it is by no means limited to junior developers. Experienced engineers fall into the same trap, just one level up: they still understand the architecture, but no longer every single decision the AI has made over the past few weeks.

One effective method is spec-driven development. Here, the specification is worked out in dialogue with the AI before implementation begins: the engineer sets the constraints and resolves ambiguities, the AI asks clarifying questions, and the engineer challenges the proposed solution before any code is generated. This helps in understanding the essential requirements and decisions. Some of our teams share the resulting specification with the whole team; colleagues review it or discuss the implementation plan together. It is not a cure-all, however: you can write and understand a specification carefully and still, in the end, no longer grasp the implementation in detail.

What matters most is therefore not the tool but the dialogue with the AI itself, throughout the entire development process, not just at the start. Spec-driven development is a good way to clarify requirements and edge cases up front and to align on the implementation plan. But it is just as important to keep asking pointed questions during implementation: Why this approach and not another? Which alternatives were discarded, and why? What happens in this edge case?

This is where the team's experience comes into play. A senior engineer recognizes that a solution proposed by the AI may be functionally correct yet often still leaves room for improvement: in architecture, efficiency, best practices, or adherence to project-specific conventions. And then challenges it deliberately. This presupposes that the engineer has genuinely understood the implementation in the context of the project, at least in its essential decisions. Forgo that understanding, and a spiral begins: at some point, even the experienced developer no longer understands how the software was actually built. The AI can then no longer be meaningfully steered; its output is merely rubber-stamped.

This is exactly why I see lead and senior engineers in a special role. They should actively encourage their teammates to truly understand AI-generated code, if necessary by asking explicit questions in reviews or while pairing. It is not enough to wave results through because they look plausible, or to simply hand the checking off to yet another AI agent.

One point I keep emphasizing in conversations with my team: whoever checks in the code is responsible for it, regardless of who wrote it. An agent cannot take responsibility for a production incident, cannot defend a design decision in a review, and cannot be held liable for a flawed architectural choice. That remains with the human.

In practical terms: before a pull request is approved, the engineer must be able to explain what the code does and why this solution was chosen. Passing the tests is not enough. In reviews, we now deliberately ask more often: "How did you implement this?" One thing stands out: reviews of AI-generated code tend to take longer, not shorter, even though more code is produced in less time. Ignoring this and waving reviews through at the pace of code generation only pushes the problem downstream.

That is why we increasingly rely on tiered reviews:

• Automate the mechanical: formatting, known security patterns
• Focus human attention where it counts: intent, architecture, functional correctness

For important decisions, such as an architectural proposal, a second human opinion is also worthwhile: not just an AI proposal and one reviewer, but deliberately two sets of eyes.

Equally important to us is what we are not saying: we do not believe in blanket bans such as "no AI-generated tests" or "no reviews by AI agents." Rules like these are too crude and usually hard to enforce. Differentiated, practical guardrails are more useful. Because the goal is neither speed nor a maximum of tokens burned: producing code ten times faster that nobody on the team understands anymore does not solve a problem. It merely postpones it.
 

Cognitive debt is no reason to ban generative AI from software development; the productivity gains are too real for that. It is, however, a reason to work more deliberately: specifications before implementation, questions instead of blind trust, and the clear stance that responsibility for code can never be delegated to a tool. We keep exchanging views on this within the team. The discussion is far from over.