AI has removed the friction that used to keep a team's judgement in sync, but the need for that shared understanding hasn't gone anywhere. This post traces the idea from software's comprehension debt to a professional firm's tacit debt, and suggests some fixes.
A report goes out to the client. It is well written, on time, and nobody in the firm could tell you how the third recommendation was reached. The consultant asked AI for an idea, skimmed it, and it made sense. It shipped. Everyone moved on.
Nothing broke. That is the point. The work looks fine - better than fine, in many cases - and is being produced faster than ever. That is when the gap opens: what the firm produces starts to outrun what anyone actually understands.
Software teams hit this first. Armin Ronacher (creator of the Flask framework for Python) reaches for the Tower of Babel. The builders lose their shared language and construction stops. His twist: with AI, construction does not stop. The tower keeps rising after the shared understanding underneath it has collapsed.
In software, the really hard part was never typing code. It was everyone holding the same model of what the thing does and why. That model was maintained by friction: reading each other's work, reviewing, arguing, asking "why did you do it this way?" Slow, yes. But as Ronacher puts it, "this friction synchronizes people."
Your professional services firm's tower is the accumulated judgement of the team: what good advice looks like, where the risks sit, why the firm does things a certain way. The same accidental friction kept that judgement in sync. Hand the brief to an AI agent and the friction is gone. The need for the shared understanding is not.
Polish used to be a fair proxy for rigour: a clean, well-argued document usually signalled good thinking. AI severs that link - you can now generate something that reads like top-tier consulting with none of the thinking behind it. Much of the removed friction deserved to go. Nobody should mourn hours spent reformatting slides. The trouble is that the same tools also remove the pauses in which people used to notice that they disagreed.
“
“The lack of an immediate failure is what makes it curious and a bit disorienting. The tower does not fall, and so we do not notice what was lost. It just keeps rising.”
Addy Osmani calls this comprehension debt: the widening gap between how much work exists and how much any human still understands. He means code, but it generalises. Every AI-drafted memo, report or slide deck that ships without a human fully understanding it adds to the balance. His end state is the "dark factory": agents scope, build and ship with nobody reading the details. The professional-firm version is work leaving the building that nobody can defend line by line if the client pushed.
Debt is the right word because, like the tacit debt firms already carry, it accrues quietly and comes due all at once. A firm can run on it for a long time. Then a client asks the one hard question, or a regulator wants the reasoning, and nobody in the firm can give it.
The obvious objection: we will just read the output more carefully. In practice, that is not what happens.
Kernighan's 1978 line that debugging is twice as hard as writing code points at something real here: the writer holds a model of every assumption and the reviewer does not. AI-drafted work drops you straight into the reviewer's chair for a document you never built a mental model of. Checking it is the heavier job, not the lighter one.
And checking does not come naturally. Shaw and Nave separate offloading, where you delegate but keep evaluating, from surrender, where you adopt uncritically. Across their studies, 73% of faulty-AI trials showed cognitive surrender and only 20% showed genuine evaluation (offloading), with the rest failed overrides. Even error feedback barely moved the numbers. A reminder won't do it. The workflow has to make people stop and explain what they're approving.
Geoffrey Litt argues that understanding is the new bottleneck. His fix is a habit: each time the agent finishes, it writes a short explainer plus a quiz he answers before moving on. The knowledge-work version is an explain-back at every handoff where AI did the heavy lifting. Before a deliverable moves on, the person responsible states in their own words and without the document open: what it claims, why, and where it is weakest. It is not proof that the work is right, but failure is good evidence that nobody should be signing it off yet. A practical aside: there is a prompt at the end of this post that lets you try Litt's method today.
Two further rules would help:
Not every deliverable earns the same gate. Client-facing advice, anything a regulator could question, or any number a client will act on has to pass the explain-back - a throwaway internal summary or a draft nobody will act on yet can move at the speed of the tool.
And the whole thing depends on company culture. An explain-back will fail in firms where admitting confusion harms your reputation. People will rehearse an answer, pass the gate and keep the debt hidden.
Content generation is abundant and nearly effortless. The scarce thing, the thing worth building a company culture around, is the smallest gap between what you ship and what you understand. Measure your capacity by what you can defend, not what you can produce.
“
“Measure your capacity by what you can defend, not what you can produce.”
Save this as a markdown file and at the end of a chat session, drag the file in with: "follow these instructions." The AI agent will produce an HTML page that captures the background, explains the decisions made, examines the tradeoffs and quizzes you about it all. Very useful, sometimes sobering.
---
name: explain-session-html
description: Use at the end of a work session to produce a rich explanation of the changes made to a document, slide deck, or similar deliverable. Captures background, key decisions, tradeoffs, and what the human still needs to understand. Produces HTML output.
---
# Explain Session
Please make me a rich, interactive explanation of the work we did in this session on the document, deck, or other deliverable.
The point is to hand a human a clear record of what changed and why, so they can review it, catch anything they disagree with, and understand it well enough to defend it or build on it later. Assume they were not watching every step.
It should have these sections:
- Background: Explain the context this work sits in. What is the document or deck for, who is the audience, and what state was it in before we started? We don't know how much the reader already knows, so include a deep background for anyone new to the project (note that it can be skipped if they already know it), and then a narrower background covering the specific part we worked on. If we drew on source material, prior versions, research, or a brief, name it here.
- Key decisions: Walk through the decisions we made, one by one. For each, state what we chose, what the main alternatives were, and why we went the way we did. The focus is the reasoning, not a blow-by-blow of every edit. Use concrete examples with real snippets from the work. Use figures and diagrams freely.
- Tradeoffs and open questions: Spell out what each decision costs, what we gave up, and where reasonable people might have chosen differently. Flag anything still unresolved, anything the reader should double-check, and any assumption we made that could be wrong. Be honest about weak spots.
- Walkthrough: Give a high-level tour of what actually changed in the deliverable. Group and order the changes so they make sense to someone reading them cold, not in the order we happened to make them.
- Quiz: Come up with five questions that test whether the reader has understood the substance of this session. Medium difficulty: hard enough that you need to grasp the decisions and tradeoffs to answer, but not gotchas. The goal is to help the reader confirm they have actually understood. Present them as interactive multiple-choice questions, and when the reader clicks, tell them whether they were right and give feedback.
## Format:
- Output a single self-contained HTML file that includes its own CSS and JavaScript. Make the whole thing one long page with section headers and a table of contents. Don't use tabs for the top-level structure. Basic responsive styling so it reads well on a phone is a plus. Put the file in a global place on my computer, outside any project folder, and make sure the filename always starts with today's date in `YYYY-MM-DD-` format, because it keeps the files time-sorted. For example: /tmp/2026-01-12-session-<slug>.html
- Write with the clarity and flow of Martin Kleppmann: engaging, plain, classic style. Transitions between sections should be smooth. Never use a long word where a short one will do. If you can cut a word, cut it. Use the active voice, not the passive. No emdashes.
- Some tips on diagrams. Pick a small number of diagram families and reuse them throughout to explain different points. Some useful kinds:
- A simplified before-and-after view of the deliverable (a slide, a section of a document, a table) to show what a change looks like to the reader.
- A flow or structure diagram showing how the parts of the document or deck fit together, or how the argument moves from one section to the next. Include real example content, not placeholders.
- Don't use ASCII diagrams. Always use simple HTML designs for diagrams, HTML lists for lists of things, and so on.
- For any block of quoted text, an excerpt from the deliverable, or a snippet, always use <pre> tags. If you use a custom styled div instead, it **must** include `white-space: pre-wrap` in its CSS, or the browser will collapse all the newlines into a single line. Before saving the file, scan each such block in the HTML source and confirm its CSS includes `white-space: pre` or `pre-wrap`.
- Use callouts for key concepts or definitions, important edge cases, decisions the reader really should not miss, and anything that still needs their sign-off.
If you would like to find out more about working effectively with AI, please do get in touch.