Talk write-up · AI Engineer 2026 · Geoffrey Litt (Notion)

Does a human still need
to read what the agent wrote

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.

His answer
To participate
understand to participate · a project is never one loop, and the concepts a person holds about the system are part of their ability to generate the next idea
The usual answer
To verify
understand to verify · but he notes agents keep getting better at checking their own output, which leaves an argument resting only on verification with progressively less for the human to contribute
01 · Scale

The volume is what outruns a human reader

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.

GitHub diff stat bar reading: Files changed 372, plus 55,219, minus 3,027
Talk slideWhat the scale problem looks like: the talk uses the size of one real change to make the point, 372 files changed, 55,219 lines added, 3,027 removed. Source: Understanding is the new bottleneck (the author's own blog, 2026-07-02)
The starting point

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.

02 · Why

From verifying to participating

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.

① Verifying sits with the human human agent Correct? thumbs-up or thumbs-down ② Verifying moves to the agent human agent Correct? it checks itself; the human fades ③ What the human keeps is participation human agent next idea understanding carries the next round
Redrawn from the three-frame progression of a single illustration in the talk. In frame ①, "Correct?" sits with the human; in frame ②, the same question moves to the agent and the human side fades; in frame ③, what lights up on the human side is no longer a judgment but the next idea.

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.

03 · Technique one

An explanation, and a quiz he will not ship without

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:

Background
Explain what was already there
Explain the existing system relevant to the change, exploring the surrounding code broadly to do so. Include both a deep background for beginners (noting it can be skipped) and a narrower one tied to this change
Intuition
Essence before detail
Explain the core intuition, focusing on the essence rather than the full details. Use concrete examples with toy data, and use figures and diagrams liberally
Code
Then walk the code
Give a high-level walkthrough of the code changes, grouped and ordered in an understandable way
Quiz
Then test the reader
Five questions testing the reader's knowledge of the PR. Medium difficulty, hard enough that answering requires understanding the substance, but not gotchas

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.

Screenshot of the explainer's Background section, covering the Phaser 3 engine and the flat canvas, with a callout on the coordinate system
Talk slideThe Background section: the existing engine and its coordinate system first, with a concept callout. Source: as above
Screenshot of the explainer's Intuition section, stating the goal of the change and then explaining isometric projection
Talk slideThe Intuition section: the goal, then what isometric projection is, and only then the code. Source: as above

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.

Raw diff · ordered by filename a/GardenScene.js b/border.js c/sand.js no explanation, no reading order built for understanding Literate diff · reordered for reading 1 · Shape constants first const GARDEN_RY = … 2 · Then the perspective gradient fillSand() { … } a sensible order, with snippets wrapped in explanation
Two ways of reading the same change. The talk shows both for one commit: on the left the raw diff laid out by filename, on the right the same change reordered into prose with the snippets embedded in the explanation.
Black and white photo of a printed code explainer packet held together with binder clips
Talk slideHe sometimes prints the explainer packet and takes it to a café, where he finds it less distracting. The body text was redacted by the author. Source: as above

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.”

Speed of the agent's loop Speed of human understanding quiz quiz quiz nothing passes until he does, and the two speeds realign
He describes the quiz as a speed regulator: in an AI-assisted loop, code can be generated and revised faster than a person can build an understanding of it, and the quiz introduces a counterbalancing force that makes him stop and mechanically ask whether he actually understands the change.

“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.

Common to both variants

  • A named prose style: the clarity and flow of Martin Kleppmann, written engagingly in classic style, with smooth transitions between sections
  • Diagrams should form a system: pick a small number of diagram families that can be reused throughout, then apply them to the various cases
  • Callouts carry key concepts, definitions and important edge cases

HTML variant only

  • A single self-contained file, CSS and JavaScript included, laid out as one long page with section headers and a table of contents; no tabs for the top-level structure; basic responsive styling is called out as desirable
  • The output is deliberately kept out of the repository: a global location on the machine, and the filename must start with today's date in YYYY-MM-DD- format, so files stay time-sorted and out of version control
  • Two kinds of diagram are named as useful: a very simplified version of the app's UI, and a system diagram of data flow between components, which must include example data
  • No ASCII diagrams; diagrams use simple HTML designs and lists use HTML lists
  • Always use <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 saving

Notion variant only

  • Use the Notion MCP tools to create a new page and return its URL

The Notion variant also asks for example data, but states it as a general rule for all diagrams rather than for the system diagram alone.

Related

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.

04 · Technique two

Micro-worlds: a small program built to be played with

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.

Slide with a black and white photo of two children and a Logo turtle robot on the left, and the title Living in Mathland with Papert's quote from Mindstorms on the right
Talk slidePapert's "living in Mathland": to learn math, live in Mathland, just as you would go live in France to learn French. The slide also carries his passage from Mindstorms. Source: as above

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.

<> Program father(orville, abe). father(abe, homer). parent(X, Y) :- father(X, Y). grandfather(X, Y) :- father(X, Z), parent(Z, Y). grandfather(X, Y)? Stack R0 Goals: grandfather(X, Y) θ: ø Timeline: Step 1 of 85 < Prev Next > Reset Add notes about this step…
Case one: last year, relative to this talk, he was building a Prolog interpreter and struggling to understand what was happening inside it. Working with an agent, he built this debugger, which lets him scrub through time, inspect the stack and the rules being evaluated, and leave comments for himself. Redrawn from the screen recording in the talk.

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.”

ASTRO PORT · INTERACTIVE LIVE EXEC STAGE 2 · PENDING ADD CORE STYLING EXECUTE TERM $ npm install packages installed ✅ Copying essential images… ✅ Creating basic homepage… ✅ Basic site initialized SRC · Middleman :4567 Geoffrey Litt Projects · Writing · Inspirations Files Path not found: /source · Retry DST · Astro :4321 Geoffrey Litt Projects Writing Inspirations Files · 9 items (5 changed) astro.config.mjs package.json public/ src/ README.md
Case two: he asked Claude for a video game-like command center where he runs the port himself, one step at a time, watching the visible site and the file tree evolve with his old and new sites side by side. In the recording, the old site runs on Middleman and the new one on Astro. Redrawn from the screen recording.

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.

His conclusion for this section

He presents it as a significant capability: agents can write bits of code that help us humans understand other code.

05 · Technique three

Shared spaces: from understanding alone to understanding together

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.

Notion page screenshot: a technical plan with two colleagues exchanging comments about an implementation trade-off in the margin
Talk slideA plan produced by an agent lands in a collaborative page by default, with an exchange in the margin about an implementation trade-off (one asks whether the approach is good, the other answers that pointers suffice instead of a full snapshot). Source: as above

“Thinking together, not alone!”

06 · Closing

The point was always to augment

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.

Line drawing from Alan Kay's paper A Personal Computer for Children of All Ages: two children sitting on grass, each holding a tablet-like device
Talk slideFrom Kay's paper A Personal Computer for Children of All Ages. At first glance the kids look like they are watching video on a tablet; they are playing an interactive game and editing its code as they play. This is a drawing, not a photograph. Source: as above
Astronaut meme: one figure asks whether the point of computers is to create dynamic simulations that help people understand complex concepts, the other answers always has been
Talk slideHe closes the lineage with this meme. The figure holding the gun carries a photograph of Alan Kay. Source: as above

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
Sources

One primary source, faithfully reproduced

PrimaryUnderstanding is the new bottleneck

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.

PrimaryThe two /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.

CitedHow Generative and Agentic AI Shift Concern from Technical Debt to Cognitive Debt

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.

ImagesThe talk slides embedded on this page

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.