Human understanding is needed for participation and creative work, even when agents can verify whether code is correct.
2
Explainer documents and quizzes help engineers learn what an agent changed before sending the work for review.
3
Interactive microworlds let people build an intuitive feel for code by exploring its state and behavior.
Summary
Geoffrey Litt argues that human understanding remains necessary as coding agents produce larger and more complex changes. Correctness checking is becoming easier to automate, but understanding has another purpose: it lets people form the next idea and participate creatively in the work. Litt calls the loss of this understanding cognitive debt. He presents three ways to reduce it. Explainer documents teach the system background, establish intuition, provide interactive figures, and present code changes as prose-led diffs. Quizzes test whether the engineer actually understood the change. Microworlds are small interactive simulations, such as a debugger for a Prolog interpreter or a step-by-step website migration, that make a system easier to feel and inspect. He also describes shared spaces where teammates and agents discuss plans together. Litt connects these ideas to Seymour Papert and Alan Kay, arguing that AI can make temporary learning tools cheap to build and help people stay more deeply involved in technical work.
Understanding lets humans participate in the next loop
Litt distinguishes understanding to verify from understanding to participate. Agents can increasingly check whether their own output meets a specification or avoids breaking production. That reduces the human role in correctness checking. However, each review also changes what the human knows, and that knowledge informs the next idea, decision, and creative leap. Litt says people with rich conceptual structures can recombine them quickly without asking another person or agent how the system works. He describes this as the human part of the work. If someone keeps accepting changes without learning how they work, they can accumulate cognitive debt and eventually realize they cannot participate anymore.
An explainer should teach the system before presenting the diff
Litt's first technique is an agent-generated explanation of a code change. His Explain Diff skill does not begin with a raw list of changed files. It first gives the background needed to understand the system, such as the game engine, coordinate system, and subsystems in his Zen garden example. It then establishes intuition before details. For the change from a top-down view to an isometric view, the document explains that the goal is to make the garden feel three-dimensional using 2D drawing techniques. Interactive figures can let the reader move rocks and see coordinates and painting layers change. The code comes later, presented as a prose-led, literate code diff.
Quizzes expose the gap between reading and understanding
Litt says reading an explanation can create a false sense of understanding. He cites Andy Matuschak's phrase, "Books don't work," referring to how easily readers can finish a book without noticing what they failed to understand. Matuschak and Michael Nielsen used interactive spaced-repetition quizzes in essays to test recall. Litt adds a five-question quiz to the bottom of his code explainers and will not send an agent-written change to teammates for review until he can pass it. He says the quiz repeatedly catches cases where he thought he understood the work but did not. He calls it a speed regulator because it slows work down when speed has outpaced understanding.
Litt's second technique comes from Seymour Papert's idea of learning by living in a "Mathland." He applies it by asking an agent to build a small environment around the system he wants to understand. For a Prolog interpreter, Claude created a temporary debugger that visualizes the interpreter's state at every step as Litt scrubs through a timeline. He used it to fix narrow bugs and develop a broader feel for how the machine works. A similar website migration tool showed the old and new sites side by side, displayed the commands being run, and showed files moving through file trees. Clicking through the process provided some benefits of doing the migration manually without all of the manual effort.
Agents can write learning tools instead of only shippable software
The purpose of Litt's microworlds is not to produce software for users. Agents write small simulations, debuggers, and playgrounds that help their human creator understand a system. Litt says that simply asking an agent to fix a bug can produce the fix without giving the person peripheral vision into the machine. Exploring a focused environment changes that. The same principle applies to the website migration game, where each step exposes commands and file changes. These tools make technical processes observable and interactive. Their value comes from helping a person develop an intuitive model, even when the tool itself is temporary.
Shared spaces help teams and agents build one understanding
Litt's third technique addresses work done by teams. A team needs shared concepts and names for system parts, interface elements, and product ideas if its members are going to communicate and generate ideas together. He describes experiments with multiplayer chat threads where several humans and agents can see the same conversation. A product manager, engineer, and another agent can discuss what users are asking for without splitting into private one-on-one chats. Documents provide another shared surface. A teammate can comment on an agent-generated plan and discuss a question beside the relevant passage. Litt says Notion had recently added the ability to bring Claude and Cursor into Notion, and his team builds much of its code there because the shared space supports this discussion.
AI can return computing to learning through construction
Litt connects his argument to Alan Kay's 50-year-old vision of children modifying a computer program while playing a game to learn physics. In that vision, the point is the children, not the computer. Litt sees AI making code cheap enough to create ephemeral interfaces, dynamic simulations, debuggers, and playgrounds for learning. He argues that these tools can help people understand systems more deeply rather than simply removing them from the loop. The talk's broader claim is that the same methods used to understand code can apply to everything people work on, especially when agents make it practical to build a custom learning environment for a specific concept or change.
"Your understanding of what's going on is the foundation for you having that next idea and being an active creative participant in a project."04:29
Who should watch
You use coding agents to produce changes faster, but you often cannot explain what they changed when a teammate asks.
Your team reviews agent-generated code in separate private conversations and needs a shared place to discuss plans, assumptions, and behavior.
You want practical ways to learn an unfamiliar system without reading every line or doing every repetitive migration step manually.
