Psychology
AI Makes You Faster. It Also Makes You Owe.
Everyone assumed AI would make engineers smarter. CTOs meeting in roundtables this summer are reporting something more unsettling: it is making engineers faster, and fast is not the same thing as smart. Ninety percent of engineers on these teams want to use AI — but nobody has updated the promotion criteria or the performance matrix to account for what that actually means. Meanwhile, the code ships at speeds no human reviewer can match, and sitting inside those pull requests — sometimes 15,000 lines of them — are perhaps three lines that actually require a human judgment call. Nobody knows which three.
- AI generates code at System 1 speed. Code review still needs System 2. The bottleneck has shifted from output to judgment.
- Cognitive debt: AI-generated code that nobody can explain. It accumulates exactly like technical debt — invisibly, until it costs you.
- Cognitive ease makes fluent-looking output feel correct. It isn't. Kahneman called this the most dangerous moment for System 2.
- Overconfidence scales with narrative coherence, not accuracy. A 15,000-line PR tells a coherent story. That makes it feel safe.
- The question that exposes the debt: can you explain every line of that code? If you can't, you owe.
1. The Speed Asymmetry
AI generates. Humans judge. These two operations do not run at the same clock speed — and that gap is where the debt accumulates.
When a CTO roundtable puts the number at 90% of engineers wanting AI tools, that's not a survey about enthusiasm. It's a description of a workflow transformation that outpaced the organizational frameworks meant to govern it. The engineers are faster. The code volume is higher. And the review queue — the one place in the pipeline where a human being is supposed to exercise judgment — has become a bottleneck not because reviewers are slow, but because the thing being reviewed has changed in kind, not just in scale.
Here is the structural asymmetry at the heart of it. Writing code has always been System 1 territory for experienced engineers — pattern recognition, fluent production, the kind of fast output that feels automatic. AI supercharges this, pushing generation speeds far past what any individual could achieve. But understanding code — tracing the logic, verifying the assumptions, catching the edge case three layers deep — has always required System 2: slow, deliberate, effortful, and by its nature reluctant to engage. Kahneman's central finding in Thinking, Fast and Slow is that System 2 is lazy. It outsources to System 1 whenever it can. When AI provides fast, fluent code, it gives System 2 the perfect excuse to stand down.
2. What Cognitive Ease Does to a Code Review
When the output looks fluent, System 2 doesn't just relax. It actively misreads confidence as comprehension.
Kahneman describes cognitive ease as a signal your brain sends when processing is going smoothly: the words flow, the logic seems to track, nothing snags. That signal evolved to tell you something like "familiar, safe, probably true." It is extremely useful when you're reading a sentence you've seen a thousand times. It is a trap when you're reviewing 15,000 lines of AI-generated code, because AI is very good at producing output that triggers cognitive ease — grammatically correct, idiomatically styled, internally consistent-looking — regardless of whether the logic underneath is sound.
The result is what CTOs have started calling cognitive debt: a gap between what the code does and what anyone on the team can explain it doing. "It works" and "we understand it" are different claims. Technical debt is when you ship code you know isn't ideal and promise to fix it later. Cognitive debt is when you ship code you can't interrogate at all, and you don't even know what "fix it later" would mean. One CTO in the Shift Magazine roundtable put it plainly: the team can add features faster than ever, and then has to deal with the maintenance overhead. "The processes we skipped when we built it — they were there for a reason. The trouble comes later."
Technical debt is code you know is imperfect. Cognitive debt is code you can't evaluate at all.
The first kind, you at least know you owe. The second kind, you don't know what you owe until the interest compounds.
3. The Overconfidence Trap: When Stories Feel Like Facts
A 15,000-line pull request tells a coherent story. That's the problem.
Another strand of Kahneman's work is directly relevant here. He showed that we calibrate confidence to narrative coherence, not to accuracy. The more complete and consistent a story is, the more confident we feel — even when the story is missing critical information. This is why people are overconfident about predictions based on thin evidence: not because they didn't notice the evidence was thin, but because they had assembled the evidence into a satisfying narrative.
AI-generated code is extraordinarily good at narrative coherence. It has variable names that make sense, comments that explain intent, functions that are cleanly scoped. It reads as if it was written by someone who understood what they were doing. And because it reads that way, the reviewer's confidence goes up — not because the reviewer has understood the code better, but because the code has triggered the neural machinery that produces confidence. "This looks right" is a feeling produced by cognitive ease. It is not the same as "I have verified this is right."
"Someone is very good at using AI, very efficient. But they're extremely sensitive about any AI output: 'This was written by AI.' 'Sure, but does it work?' 'It works. But it was written by AI.'" — CTO roundtable, Shift Magazine, June 2026
There's something psychologically interesting in that exchange. The engineer who wrote the code can't explain it and doesn't quite trust it. The reviewer finds it hard to interrogate because it reads fluently. Both parties know something is off. Nobody has a framework for naming what's off. That's cognitive debt in real time — an anxiety without a vocabulary, a debt without a balance sheet.
4. What Leadership Owes the Team (and What the Team Owes Itself)
The tools make laziness easy. Leadership's job is to make laziness not worth it.
The CTO roundtable didn't bury its conclusion. Ninety percent of engineers want AI. Nobody updated the promotion criteria. Those two facts, together, are a policy choice — even if nobody made it consciously. When speed is the visible metric and comprehension is invisible, the incentive structure rewards the former and ignores the latter. What gets measured gets managed. What doesn't get measured gets outsourced to the AI and forgotten.
What would it look like to measure the right thing? One answer is simple and uncomfortable: require engineers to be able to explain, in plain language, what any code they ship does. Not the intent — the code itself. This isn't a punishment for using AI. It's a definition of what "shipped" means. If you can't explain it, it isn't shipped; it's merely deployed. Another answer is structural: cap PR size at a level a human can genuinely review, so that the 15,000-line pull request ceases to be possible. A third is cultural: create explicit space for the slow, deliberate, unglamorous work of sitting with code until you understand it — what Kahneman would call the rehabilitation of System 2 in an environment that has systematically rewarded System 1.
And here is the question worth sitting with: what happens to engineering judgment as a skill when it goes years without being exercised? Technical skills atrophy. Judgment skills atrophy faster, because they're harder to notice atrophying. An engineer who has shipped a hundred features with AI assistance and understood the internals of none of them is not a senior engineer who uses AI tools. They're an AI operator with a senior title. Those are different things — and eventually, the difference matters.
What This Means for You
Kahneman's framework doesn't tell you not to use AI. It tells you to notice what AI's fluency does to your thinking, so you can compensate deliberately. Here's the practical version. When AI generates code that looks obviously right, treat that feeling as a warning, not a confirmation — it's cognitive ease talking, not comprehension. Pick one mechanism, per project, that forces System 2 to engage: a rubber-duck explanation of every function before it ships, a cap on PR size that makes review humanly possible, or a standing question in every review: "Can you show me the worst case this code doesn't handle?" Use AI to go fast. Insist on understanding to make that speed safe. The debt you run up silently is always the most expensive kind.
And here is the question that will stay with you if you let it: if you woke up tomorrow without access to any AI tool and had to maintain the codebase you've been shipping, would you know where to start?
Sources: Shift Magazine (shiftmag.dev), "CTOs Agree: Cognitive Debt Is the New Technical Debt," June 19, 2026; Hacker News discussion, ~75 points, ~72 comments. Framework: Daniel Kahneman, Thinking, Fast and Slow (cognitive ease, System 1/2, overconfidence and narrative coherence). This is a popular-science interpretation applying Kahneman's framework to a reported trend; it is a conceptual argument, not a measured causal claim. Not professional engineering or psychological advice.