Engineering leaders gathered in Toronto this month for a no-slides dinner. The topic was AI in engineering teams. Within minutes the conversation settled on one point. The era of unchecked experimentation has ended. Now comes the bill.
At the Shift CTO Craft Dinner, hosted on the edge of the CTO Craft conference, more than a dozen senior engineering executives traded stories. Ivan Brezak Brkan, who organized the event and wrote up the findings for Shift Magazine, captured the mood. Nobody has truly figured AI out. Two years after the initial rush, the questions have changed. They no longer ask if teams use AI. They ask what return it delivers. And the answers prove harder than expected.
Costs have escaped control. One attendee described the problem bluntly. The CFO approves a contract but then loses sight of actual spend. Tokens replace headcount as the unit of engineering capacity. No one tracks how many any individual burns daily. Finance models break. Projected returns lose meaning when investment itself stays undefined. Several participants compared the moment to early cloud adoption before FinOps matured. Usage runs wild. Metrics lag. The free-for-all is over.
Yet speed keeps climbing. AI lets teams ship features at paces once unthinkable. That velocity creates its own trap. One leader at the dinner put it plainly. Cognitive debt is the new technical debt. The phrase stuck. It has since echoed across blogs, academic papers and conference keynotes. The idea is simple. Technical debt lives in the code. It shows up as shortcuts that complicate future changes. Cognitive debt lives in people. It grows when shared understanding erodes faster than teams can replenish it.
Margaret-Anne Storey, professor of computer science at the University of Victoria, has shaped much of the current discussion. In her February 2026 blog post on margaretstorey.com, she explained the distinction. Cognitive debt captures the accumulated gap between a system’s structure and a team’s collective grasp of how and why it works. Developers move faster. They lose the deeper sensemaking that once connected decisions to intent. Even clean AI-generated code can leave humans unable to explain it or safely modify it.
Storey expanded the concept in a later paper. With co-authors she proposed a triple debt model. Technical debt sits in the code. Cognitive debt sits in people. Intent debt sits in missing externalized rationale. The arXiv preprint titled From Technical Debt to Cognitive and Intent Debt argues that AI accelerates all three but shifts the balance. Code arrives quicker than understanding can follow. When shared mental models weaken, teams hesitate on changes. Bugs hide. Onboarding slows. Production incidents turn frightening because no one fully owns the system anymore.
Simon Willison, known for his work on LLMs, read Storey’s post and agreed. In his February 15, 2026 entry on simonwillison.net, he recounted personal experience. On ambitious projects he had accumulated cognitive debt faster than technical debt. The result paralyzed progress. He could generate output but struggled to reason about the whole. The pattern matches reports from practitioners on Hacker News and in conference sessions. Teams report getting lost in their own codebases. Features ship. Confidence drops.
Martin Fowler picked up the thread. In an April 2026 fragment on martinfowler.com, he distilled the definitions. Technical debt limits how systems change. Cognitive debt limits how teams reason about change. Intent debt leaves goals and constraints undocumented. The three interact. AI that writes code without capturing why decisions were made compounds intent debt. That in turn deepens cognitive debt. Fowler noted the metaphor has gained traction precisely because it describes a felt pain.
Recent coverage shows the idea spreading. A June 2026 article on LeadDev titled AI coding creates two kinds of debt. You’re only measuring one quotes Storey and frames cognitive debt as the technical debt nobody tracks. Author Antonija Bilić Arar highlights performance management questions that arise when AI inflates output. How do promotions work when anyone can generate code? What counts as individual contribution? The piece appeared just days ago and echoes the Toronto dinner discussion almost exactly.
Back at that dinner, participants described real recalibration moments. Engineers who once took days for tasks now finish in hours. Schedules break. Late adopters suddenly grasp the shift and must rethink their pace. One leader mentioned an anonymous survey. Ninety percent of engineers wanted to use AI. Yet the same group asked hard questions about career paths and competency matrices that had not been updated. Adoption raced ahead of enablement.
Code review emerged as the new bottleneck. AI generates fifteen-thousand-line pull requests. Humans cannot read them all. One attendee proposed confidence scoring. Let AI flag the three lines that truly need eyes. The rest could pass with automated validation, feature flags, strong observability and mutation tests. The room liked the direction but admitted no one had solved it yet. Invest in evals early, several urged. When models change or vendors raise prices, a solid evaluation suite protects the investment.
Vendor lock-in worries surfaced too. One company depended almost entirely on a single provider. Marketing and finance teams built workflows on top without grasping the fragility. If inference disappears, they call engineering. Competition and open-source progress may limit price hikes. Still, the harder migration involves skills, internal tools and tribal knowledge. Those resist change more than API endpoints do.
Hiring practices are shifting. The dinner revealed a split. Some still test fundamentals and systematic thinking. Others have moved interviews toward code review because that now dominates daily work. Implementation is AI-assisted. Judgment is not. The new software engineer often acts as product leader, one participant observed, focused on what the product should be rather than only how it works. System design still needs humans who weigh availability, cost and architecture.
Product managers shipping PRs sparked debate. Technically feasible. Philosophically divisive. One voice warned that turning engineers into review monitors while PMs claim credit damages morale. Others saw value in smaller, low-risk contributions from designers or product people. The self-driving car analogy appeared. An average AI-assisted non-engineer may outperform an average unassisted one within limited scope. But complexity changes the equation. Small autonomous teams of three to five people, with clear ownership, looked like the practical response to blurred roles.
The feature debt problem lingers. AI makes writing code cheap. Shipping and maintaining it remain expensive. Internal tools spun up in an afternoon become permanent fixtures. Processes meant to evaluate build-or-buy decisions get skipped. One suggestion was to separate feature ships from health work. Create technical health teams that refactor and delete with equal status. Business incentives favor velocity. Securing budget and recognition for maintenance proves difficult.
Storey and others stress that cognitive debt must be repaid, just like technical debt. In her ACM Queue article drawn from the triple debt paper, she outlines diagnosis and mitigation. Slow down deliberately. Use pair programming, refactoring and test-driven development not only for code quality but to rebuild shared understanding. Document intent explicitly so both humans and future AI agents can work safely. Without those steps, velocity today buys fragility tomorrow.
Recent X discussions show practitioners wrestling with the same tension. One post noted that cognitive debt turns a PR review into a forty-minute archaeology session about decisions no one remembers. Another warned that agent velocity of 140 to 200 lines per minute outruns human comprehension. The conversation has moved from hype to hangover. Teams celebrate PR counts while quietly losing the plot.
Academic work adds weight. An MIT study from 2025 on essay writing with ChatGPT found users accumulated cognitive costs. They performed worse on neural, linguistic and behavioral measures over months. Quoting their own work became harder. The parallel to code is direct. Convenience trades for deeper processing. The brain takes the path of least resistance. Debt builds.
Thoughtworks included codebase cognitive debt in its April 2026 Technology Radar. The entry warns that AI-driven change velocity, especially with agent swarms, widens the gap between implementation and understanding. Combined with technical debt it creates a reinforcing loop. Systems grow harder to reason about. The caution level is clear.
So what now? Leaders at the Toronto table and in subsequent writing agree on basics. Establish baselines before aggressive ROI targets. Standardize tools rather than allow everything. Treat verification as the real cost, not generation. Build internal wrappers over model APIs to reduce lock-in. Prioritize practices that restore shared understanding even when they slow output. Measure what matters beyond lines or tickets.
The dinner ended without clean answers. That was the point. Candor replaced pitch decks. The discomfort is shared. AI has delivered speed. It has also delivered a new class of risk that sits inside heads rather than repositories. Organizations that treat cognitive debt as seriously as technical debt may keep their capacity to change. Those that don’t risk building systems no one truly owns. The free-for-all is over. The hard management work begins.
WebProNews is an iEntry Publication