Technique 1: explanations that teach the change

Video segment: 06:54–08:25

The idea in plain language

An agent-written change should not end with a person receiving a raw code diff. In this segment, the speaker proposes treating the change as an opportunity to teach that person how the relevant part of the system works.

He calls the practice ExplainDiff. It creates a personalized code explainer: a document that gives the reader the background needed to understand one particular change. Rather than stopping at the raw diff, the practice adds an explanation around the change.

Teaching interpretation: A raw diff records which lines were added, removed, or edited. It may be exact, but it often assumes that the reader already knows the surrounding system. An explainer reduces that assumption. It builds a small mental model first, then uses that model to make the change easier to reason about.

Teaching interpretation of the contrast:

A raw diff	A code explainer
Shows the textual change.	Teaches how the change fits into the system.
Often makes the reader reconstruct missing context.	Supplies the relevant context before asking the reader to interpret the code.
Is useful evidence of what changed.	Is a learning path around that evidence.

The difference is not cosmetic. A shorter, cleaner diff still leaves a reader with the same unanswered prerequisite questions. If they do not know what the engine does, how positions are represented, or which components work together, seeing changed lines alone cannot reliably create understanding.

Start with the model the change depends on

The speaker's example is a Zen-garden game that changes from top-down rendering to isometric rendering. Before explaining that change, the explainer supplies background about the game engine, its coordinate system, and the relevant subsystems.

Teaching context: These terms name the reader's starting model:

• A game engine is the software framework that runs and draws a game.
• A coordinate system is the convention a program uses to represent positions with numbers.
• Subsystems are separate parts of a program that cooperate to produce a result, such as the visible scene.

This background is causal, not introductory decoration. A rendering change has meaning only in relation to the system that already renders the scene. The reader needs that reference point before they can judge what the altered code accomplishes.

existing engine, coordinates, and subsystems
                    ↓
          a model of the starting system
                    ↓
      top-down → isometric rendering change
                    ↓
       code that the reader can now interpret

In a top-down view, a scene is presented as if viewed from above. An isometric view is a two-dimensional drawing style that gives an angled, three-dimensional impression. The video establishes the intended perspective change, but it does not establish the exact projection math, file layout, or implementation used for the game.

Consider what a reader would face without the background. They might see changed position calculations in a diff, yet not know whether those numbers control drawing position, depth, collision behavior, or something else. That is a general teaching example, not a description of the demo's code. The background section turns otherwise isolated symbols into parts with roles.

Why this is a curriculum, not a prettier report

Teaching interpretation: Calling the document a personalized curriculum emphasizes sequence. The explanation begins with what the reader must know, then connects that knowledge to the particular change. The reader does less blind reconstruction and can spend more attention on the new idea.

This is especially important when an agent produces a large change quickly. The diff may contain all the evidence, but evidence is not automatically an explanation. A person needs help answering questions such as:

1. What system existed before this change?
2. Which concepts matter for this change?
3. How do the changed parts relate to those concepts?
4. What should I now be able to reason about or discuss?

The speaker's background-first structure prepares the ground for the next principle in the talk: establish intuition before overwhelming the reader with implementation details.

Make the explanation available where people work together

The speaker says that an explainer can be delivered as HTML, Markdown, or a collaborative Notion document. The delivery format can change, but the teaching goal remains the same: give a human a path into the change rather than only a final artifact.

A collaborative document adds a team benefit. Teammates can comment on the explanation and build understanding together.

Teaching interpretation: The format alone does not make a document explanatory. An HTML page, a Markdown file, or a collaborative page can all become a dump of code. The useful design choice is to organize the material around the reader's missing model and to leave room for questions. Keeping a question beside the relevant background or change can also preserve its context.

A practical test for an explainer

The following checklist is teaching guidance, not a verbatim procedure from the video:

• Name the change in plain language.
• Introduce only the prior concepts needed to understand it.
• Explain how those concepts connect to the change.
• Use the diff or code as evidence after the reader has a frame for reading it.
• Put the result somewhere where the intended readers can ask questions.

If a reader can point to changed lines but cannot explain what role those lines play, the document is still functioning mainly as a report. If they can describe the starting model, the intended change, and the connection between them, it is beginning to function as a lesson.

Visual checkpoints in the video

• At about 06:58, a slide shows an annotated red-and-green code diff. The visual supports the contrast between a raw code comparison and an explanation built around it.
• At about 07:46, a slide titled “Code explainer doc” shows a Notion-style document about changing the Zen garden from top-down to isometric rendering.
• At about 08:01, a slide titled “Start with background” shows background material on Phaser 3 and the flat canvas, including the coordinate system and scene-rendering components.

Source boundary: The video describes the explainer and shows documentation context, but the actual document and code are not supplied here. Its exact layout and implementation details should not be inferred from these slides.

Takeaway

ExplainDiff changes the handoff from a list of changed code to a model a reader can use to understand the change. That model helps a person stay able to review, question, and contribute after an agent has done the code production. Starting with background makes the later implementation details easier to learn rather than merely harder to read.