Geoffrey Litt, Design Engineer at Notion, thinks the answer is yes, but not for the reason most people give. His talk lays out three techniques he uses himself, including a skill he runs every day.
Litt opens with what he himself labels a hot take: he still considers it important to understand the code that agents write. That position now requires a defense, because the prevailing direction in agentic coding is to remove the human from the loop and let agents loop themselves.
He concedes the pressure behind that expectation. Agents are writing a growing share of the code, and keeping up with their output is becoming genuinely difficult. But he argues that reading every diff line by line is not the only way to understand a system. A diff is the before-and-after view of a code change, typically the object examined during review.
The talk introduces three other ways of building understanding: code explainer docs, quizzes that test his own understanding, and micro-worlds he can explore and manipulate. Those three make up the sections that follow.
In his framing, once the volume climbs, the question is not whether to read the code, but whether reading diffs line by line is the only way to read it.
The counterargument follows directly from the direction of the technology. If the objective is to take people out of the loop and let agents run those loops themselves, then human attention to implementation details should matter less as models improve. Litt thinks most answers to that objection are off by one step.
One answer is that people need to understand the code in order to verify it. They must determine whether the result is correct, whether it matches the specification, and whether it is well architected. In his formulation, this is "understand to verify": understanding serves a final thumbs-up or thumbs-down judgment on the agent's work.
He finds that answer incomplete. Agents are becoming better at checking their own output, and he notes that he prefers it when an agent does not make mistakes in the first place. If verification increasingly belongs to the agent, then an argument for human understanding based only on verification leaves progressively less for the human to contribute.
His alternative is "understand to participate". A software project, he argues, is not a single exchange with an agent. As he puts it, it is never just one loop. Projects evolve through many rounds, and the concepts a person holds about the system shape their ability to generate the next idea. Without a sufficiently rich understanding of what exists and how it works, it becomes harder to think fluently and creatively about how the system should develop.
“It's never just one loop!”
He connects this problem to cognitive debt, a term he says was popularized by Margaret-Anne Storey and Simon Willison; his slide credits Storey as Margaret Storey. Cognitive debt is debt accumulated by moving quickly that resides in people's heads rather than in the code: a change has shipped, but nobody understands what it does, making later changes difficult.
Even if AI agents produce code that could be easy to understand, the humans involved may have simply lost the plot and may not understand what the program is supposed to do, how their intentions were implemented, or how to possibly change it.— Margaret-Anne Storey, Cognitive debt (emphasis as it appears on Litt's slide)
Litt compares this with technical debt, meaning code-level shortcuts taken for speed that become more costly to modify or extend later. In his view, both forms of debt can be tolerated temporarily, but the deferred cost eventually returns.
That leaves the practical question on which the rest of the talk turns: how can a person build understanding while working with AI and continuing to move quickly? His answer begins outside software engineering. Communicating understanding is not a new problem, and education has already developed methods for it; his question is whether those ideas can be taken from education and applied to work with coding agents.
The first technique lands on a concrete tool: /explain-diff, a Claude Code skill he wrote himself. A skill is a reusable instruction set, invoked as a slash command, that makes a coding agent produce output in a fixed shape. Every time an agent finishes a piece of work, the skill turns that change into an explainer document, which he reads before examining the diff itself.
A diff is the raw record of which lines changed, and it is not organized for explaining. Litt starts from a different question: what would the best possible explanation look like if a human or AI team had carefully worked through how to explain the change? That question set the direction for the skill. It is his personal skill, published as a gist, rather than an official Notion or Anthropic product; he uses it every day and says many of his coworkers have found it valuable.
The skill can produce explainers in three forms: HTML, markdown, or Notion docs. He describes Notion as a useful place for teams to collaborate on and discuss these documents, while disclosing that he works at Notion and is therefore biased.
Four sections are fixed in the skill file, and so is their order, in both variants. What follows comes from the published skill files themselves, not from the talk narration:
He demonstrates the structure with a change to the visual perspective of a video game. The document begins by describing the existing game engine. Before any code, it states the goal as "make the garden feel three-dimensional with 2D drawing tricks" and then explains the concepts behind it, one of which is isometric projection, a way of drawing a two-dimensional scene so that it reads as three-dimensional, commonly used in games. In his account, this sequence catches him up as the human, giving him enough conceptual footing to be an equal participant in understanding.
He also embeds figures he can manipulate: dragging rocks around the garden and watching their coordinates move is how he comes to understand the isometric perspective. He notes that the document uses a feature Notion had just shipped, the ability to embed interactive HTML inside a page.
Only after that preparation does the explainer reach the code. A conventional diff presents edits as a collection of changed files ordered by filename, without explaining the conceptual sequence that connects them. What he calls a literate diff is structured as prose instead: it walks the changes in a sensible order with surrounding explanation and embedded code snippets. His judgment is that this is faster to review than the raw diff.
The finished result is an explainer packet. He still reads the code diff, but he always reads the packet first. He also points out the irony in it himself.
“It's beautifully ironic: AI turns an interactive activity into a static paper report I can focus on deeply”
His own caveat is that this leaves one problem in place: reading is hard work. He cites Andy Matuschak's formulation that "books don't work": it is too easy to fool yourself into thinking you did the reading when you did not actually retain or understand it.
His response draws on work by Matuschak and Michael Nielsen that embeds spaced repetition quizzes inside essays. Spaced repetition is a memory technique in which someone quizzes themselves on the same material at widening intervals. That work is Quantum Country, an online text with quiz questions placed directly in the prose.
Litt adapted the idea for code explainers. At the bottom of each explainer there is now an interactive quiz containing five questions about the change, and he tries to answer them. He applies a specific rule to his own work.
“My rule: I won't send code to others until I can pass the quiz, and I do the same when reviewing others' code.”
“A quiz is a speed regulator.”
That completes the first technique. Litt published the skill and offered it through a QR code during the talk, in two variants: one outputs HTML, one outputs a Notion page. They diverge on how the quiz is implemented. The HTML variant requires interactive multiple-choice questions that tell the reader whether they were correct and give feedback on click. The Notion variant requires each option to carry an explanation of why it is right or wrong, held in toggle blocks, with ❌ and ✅ marking those explanations.
YYYY-MM-DD- format, so files stay time-sorted and out of version control<pre> for code blocks; a custom styled div must include white-space: pre-wrap, or the browser collapses all newlines into a single line, and every block is to be scanned before savingThe Notion variant also asks for example data, but states it as a general rule for all diagrams rather than for the system diagram alone.
A prompt of the same shape, asking for an HTML report with a quiz at the bottom that must be passed before merging, appears in Finding your unknowns on this site. That piece is about articulating unknowns before starting, where the quiz is one closing prompt; this one gives the full skill file, plus the reframing of why understanding matters at all.
The second technique does not require reading the code directly. Instead, the agent helps create a separate small program that a person can play with, and that interaction becomes the means of understanding what the original code does. The idea comes from the education researcher Seymour Papert.
Papert's question was whether you could build an environment where children learn math naturally, as a consequence of their curiosity. Litt applies that older educational idea to software: can people inhabit small worlds in which they naturally develop an intuition for how a system works and how it is changing. He gives two examples from his own projects.
Prolog is a logic programming language in which a program consists of rules, and running it means matching those rules to derive an answer. The distinction between building this tool and delegating the investigation was central to his account.
“There's a big difference between making a tool for me to debug and letting the agent debug”
He did not simply ask the agent to diagnose the interpreter and return an answer; he used the agent to build a tool through which he could do the debugging himself. His second case came from migrating his personal website from one framework to another. Claude wrote a script to perform the migration, but he was unfamiliar with the new framework and found the result difficult to review.
“I guess that looks about right.”
By watching the new site come to life incrementally, he says he developed an understanding similar to what he would have gained by completing the migration manually, but much faster because the sequence had already been laid out for him.
He presents it as a significant capability: agents can write bits of code that help us humans understand other code.
Everything up to this point concerns an individual developing understanding alone. The third technique shifts the unit of analysis to the team.
When two people hold the same mental model, he argues, they can communicate efficiently because shared vocabulary evokes the same underlying images and structures. That common ground, in his words, is what lets people "jam and riff and have creative conversations". Without it, the same exchanges become much harder. He says he is interested in shared environments where teams build this understanding together, connecting the idea to the work of Notion, where he has already disclosed that he is employed.
As one concrete example, he describes features Notion has been shipping for humans and agents to work in the same environment. Claude and Cursor agents can now run in Notion, which he says is how he does much of his coding. When an agent produces a technical plan there, the plan appears by default in a collaborative page, so he can comment on it and discuss it with his team immediately rather than leaving each person to work with an agent in a separate silo.
“Thinking together, not alone!”
The three techniques are ways to understand code, but his closing argument is broader. He believes humans still need to understand how things work in general, not just to verify, but to participate.
He argues that this idea is not new, tracing it back to the origins of computing and to Alan Kay, a computer scientist and early designer of the personal computer and graphical interface who has long advocated for the computer as a medium for thinking. Fifty years ago, Kay envisioned computers becoming a new medium, better than the book at helping people, especially kids, learn how to think about the world.
He says it is beautiful that AI has made creating simulations so accessible, and that using AI to teach people is one of the greatest possibilities computing has ever opened up. That possibility, he says, is what makes him very optimistic about the future.
“The point was always to augment, not just automate.”
If we build the right tools, we can now understand the world better than we ever could before. We don't have to merely take ourselves out of the loop, we can get deeper in the loop too. It's up to us.— Geoffrey Litt, closing the talk
geoffreylitt.com · 2026-07-02 · Geoffrey Litt, Design Engineer at Notion. The written version of his talk at the AI Engineer conference in July 2026, slide by slide across 35 slides. This piece reproduces his claims and methods without adding evaluation, implications or recommendations; his own judgments are attributed throughout.
/explain-diff skill variants
gist.github.com · published by the author. The subsection on what the skill mandates is taken from these two files rather than from the talk narration; the four section names and the format rules are grouped as they appear, with rules common to both variants separated from those specific to each. This is his personal skill, not an official Notion or Anthropic product.
margaretstorey.com · 2026-02-09 · Margaret-Anne Storey, Professor of Computer Science at the University of Victoria. Slide 9 of the talk quotes this post; the quotation here was checked against the original and cognitive debt is explained from it. Litt's slide credits her as Margaret Storey.
Every image inside a .source-figure on this page is a quoted talk slide, individually attributed and linked back to the original. The site's content security policy does not permit third-party images, so these are served as local copies, uncropped and otherwise unmodified. The concept diagrams (the three-frame progression, the diff comparison, the speed regulator, and the two self-built tools) were redrawn here from the originals, as noted in their captions.