Does a human still need
to read what the agent wrote

One possible answer is to "understand to verify". A human needs enough understanding to decide whether the work is correct, whether it matches the specification, and whether it is well architected. In that framing, understanding supports a final thumbs-up or thumbs-down.

That rationale weakens as agents become better at checking their own work. Litt is clear that he prefers an agent not to make mistakes. The improvement is desirable, but its effect on the verification case is straightforward.

The more verification belongs to the agent, the less the verification argument leaves the human.

His reframe is to "understand to participate". A software project is not one instruction followed by one final review. It is a long series of loops, each producing a new state of the system and creating the need for another decision about what should happen next.

“It's never just one loop!”

That next direction does not emerge from verification alone. It depends partly on being able to think about the system: what it currently does, how its pieces relate, what possibilities are available, and which change might be worth pursuing. A person with too few concepts for describing the system may still approve or reject an output, but has a narrower basis for thinking fluently and creatively about the next move.

The gap that accumulates when code advances faster than human comprehension is cognitive debt. Unlike technical debt, where code-level shortcuts taken for speed make later modification or extension more costly, cognitive debt sits in people’s heads: the change has shipped, but the people involved may no longer adequately understand what it does.

The term was popularized by Margaret-Anne Storey, a professor of computer science at the University of Victoria, and Simon Willison, co-creator of the Django web framework and a longtime writer on LLM engineering practice. Litt’s slide credits her as Margaret Storey. Her warning, quoted there, is broader than code readability alone.

As with technical debt, the immediate trade can appear acceptable. A team can move quickly without understanding every change. The deferred cost returns when someone needs to decide how the program should evolve and no longer has a reliable mental account of what was built, why it works, or where a new intention belongs.

Once understanding is treated as necessary for participation, the problem becomes how to build it without returning to exhaustive line-by-line reading. Communicating understanding is not a new problem. Education has already developed a great deal of method for it, and what he wants is to borrow the best of those ideas and apply them to working with AI.

The idea predates the current generation of AI tools. Seymour Papert, whom Litt calls a visionary educator, had an idea he called "living in Mathland": to learn mathematics, live in Mathland, just as someone who wants to learn French would go live in France. Papert was interested in environments where children could acquire mathematical understanding naturally, through curiosity and activity. Applied to code, the idea is to build worlds that people can inhabit, where interacting with the environment reveals how a system runs and how it is changing.

The first of Litt’s two cases began last year, when he was writing a Prolog interpreter and found it difficult to picture what was happening inside it. In Prolog, the program consists of rules, and execution proceeds by matching those rules to derive an answer. Reading the interpreter did not give him a clear sense of that process in motion.

He and an agent built a debugger, a tool that exposes a program’s internal state while it runs. Its central interface was a timeline that he could scrub backward and forward. At each point, it showed the rule being evaluated and the stack, the record of which level of nested calls the program was currently inside. He could watch one rule match, see the interpreter move into another call, inspect the intermediate state, and then reverse the timeline to examine the transition again.

The interface also let him leave notes for himself. A moment when a rule behaved as expected might receive a comment such as “nice, we correctly applied that rule”

Scrubbing the timeline, watching rules match, inspecting the stack, and marking the moments that made sense were the activities through which his understanding grew.

“There's a big difference between making a tool for me to debug and letting the agent debug”

The second case began with a more immediate discomfort. Litt moved his personal site from Middleman to Astro, a framework migration that replaced the development framework underneath the site. Claude wrote a script that did the migration. The result was there, apparently finished, but Litt did not know Astro well enough to evaluate what had happened. His assessment was limited to one line.

“I guess that looks about right.”

That uncertainty became the reason to redesign the migration itself. Instead of accepting the completed output, he had Claude build a video-game-style command center that allowed him to perform the migration step by step. The old Middleman site and the new Astro site ran side by side. He pressed buttons to advance through the sequence, while the interface showed both the visible effect of each step and the corresponding change in the file tree.

A migration that had arrived as one large, difficult-to-assess result became a series of observable operations. He could see which files changed, connect those changes to what appeared in the browser, and watch the Astro version of the site come alive piece by piece.

The resulting understanding approached what he would have gained by carrying out the migration by hand, only much faster, because the steps had already been identified and arranged for him.

That question was already being asked fifty years ago. Alan Kay, a computer scientist and one of the early designers of the personal computer and the graphical interface, argued that computers should become a medium that helps people think. He proposed that they could go further than books, helping people, especially children, understand the world by interacting with systems rather than only reading about them.

One image from Kay’s paper A Personal Computer for Children of All Ages captures that idea through a small reversal. At first glance, the kids appear to be watching video on a tablet. They are actually playing an interactive game and editing its code as they play so that they can understand physics. By changing the rules and watching the results, they are working with a simulation: the system’s rules run as a program that can be observed, tested, and altered. The image itself is a hand-drawn line illustration, not a photograph.

Litt closes this lineage with an astronaut meme. Its text runs "wait, the point of computers is to create new dynamic simulations to help people understand complex concepts?" answered by "always has been". Alan Kay’s own photograph appears on the gun-holding side.

That is also Litt’s position.

For Litt, AI strengthens that possibility because it has made creating simulations so accessible. He calls that beautiful. Having AI teach us is, in his view, one of the greatest possibilities computing has ever opened up, and it is the reason he remains optimistic about the future.

He closes with the choice that follows from that possibility.

“The point was always to augment, not just automate.”