← All AI Engineer talks

AI Engineer World's Fair 2025

Understanding is the new bottleneck

Geoffrey Litt· Design Engineer, Notion19:33

Read the talk

Understanding is the new bottleneck

As agents write more code, explanations, quizzes, and custom learning environments can help developers understand enough to shape what happens next.

From a talk by Geoffrey Litt

Before you start: Familiarity with code changes and pull-request review is helpful; no knowledge of Prolog or isometric rendering is required.

How do you keep up with code you did not write?

If an agent can produce code faster than you can read it, how do you remain an effective developer? Geoffrey Litt, a design engineer at Notion, opens with the premise that people still need to understand how code works. His audience largely agrees, though he acknowledges the selection bias. The pressure behind the question is real: Litt invokes agents landing 50,000-line pull requests as an illustration of output that humans struggle to keep up with, not as a measured benchmark.

Reading every line is only one way to build that understanding. An agent can also write an explainer, generate questions that expose gaps in your knowledge, or build a small environment where you can explore the system directly. The same ability that makes code production accelerate can produce teaching materials tailored to the code you need to understand.

Slide titled “How I understand agent code” with three labeled examples: Code explainers, Quizzes, and Micro-worlds.
Three ways to understand agent code: code explainers, quizzes, and micro-worlds.
0:220:35
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

0:22 · section reference included

Correctness is only one reason to understand

The familiar reason for human review is verification. An agent proposes a change; a person checks whether it matches the specification, threatens production, or fits the architecture. These are substantial questions, but they largely lead to an acceptance or rejection decision. Understanding, in this model, is what lets the reviewer decide whether the result is correct.

Agents can increasingly ask those questions too. With an appropriate verification loop, they can check their own work and return a result that already satisfies the request. Litt welcomes that prospect: when the intention is clear, receiving a correct implementation is better than receiving an incorrect one. He expects the human role in correctness checking to decrease.

Diagram with a faded person at a laptop and faded connecting arrows, beside a dark hard-hat figure with a circular arrow labeled “Correct?”
The correctness loop remains prominent as the human review loop fades.
2:282:42
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

2:28 · section reference included

What you learn changes the next iteration

It does not follow that better automated verification removes the need for human understanding. Development is not a single loop ending in a verdict. Understanding enables participation in the next loop. When you examine a change, you come away knowing something you did not know before. That knowledge affects the next idea you have, the next question you ask, and the next direction you choose.

A rich mental model lets you recombine concepts quickly. You can imagine an alternative design or notice an opportunity without first asking another person or agent to explain every relevant part. Someone several layers removed from the implementation can still contribute, but the ideas available to them differ from those available to someone who understands the machinery. Better agents do not eliminate this connection between knowledge and creative agency.

Litt connects this to cognitive debt, a term he credits Margaret-Anne Storey with popularizing and which Simon Willison has also discussed. Like technical debt, an understanding deficit may remain tolerable for a while. A vibe-coding session can appear to be going well until you realize you no longer know what is happening well enough to participate meaningfully. The system has advanced, but your model of it has not.

3:524:02
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

3:52 · section reference included

Turn a diff into a lesson

Keeping up does not require abandoning agents or returning to an earlier pace of development. It requires treating understanding as a teaching problem. Education already offers methods for helping people acquire new conceptual structures. A raw diff supplies the changed material; it does not necessarily supply the explanation a particular reader needs. A useful design question is: what would an exceptionally good, personalized curriculum for this one change look like?

Litt’s Explain Diff skill, which he says he and coworkers use regularly, applies that question to code changes. His example is a game for drawing zen gardens. The change replaces a top-down view with an isometric perspective. The skill produces an explainer document, which can be HTML, Markdown, or a Notion page. Litt prefers the collaborative page because teammates can comment and discuss the explanation together.

The explanation begins before the change itself:

  1. Establish the background. Introduce the game engine, coordinate system, and relevant subsystems so the reader has the prerequisites for understanding the change. Skip or tailor material the reader already knows.
  2. Build intuition before showing details. Explain that the goal is to make the garden feel three-dimensional using 2D drawing tricks. Examples and a clear statement of intent give the reader something to attach the implementation details to.
  3. Expose the mechanism through interaction. Let the reader drag rocks in a small simulation while watching their coordinates and painting Z layers change. The movement connects the visible result to the values that determine it.

The demonstrated simulation lives inside a Notion HTML block, a feature Litt describes as having launched that morning. Interactivity needs a reason to exist: changing a rock’s position is useful because it reveals coordinates and drawing order. A widget that merely adds activity can become distracting clutter. Used selectively, interaction can convey a relationship that is difficult to grasp from static pictures alone.

Only then does the explainer reach the code. Literate code diffs introduce each file with prose and arrange the walkthrough in an order that teaches the change, rather than simply listing files. The accumulated background, intuition, and commentary make the patch easier to follow. The result can also work away from the development environment: Litt sometimes prints these documents and reads them at a café, effectively studying a small textbook about a pull request.

5:566:02
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

5:56 · section reference included

Test understanding before requesting review

A good explanation still leaves room for false confidence. Litt once sent a pull request to a coworker believing he had read and understood it. She asked a basic question, and he could not answer. Reading had felt like understanding without producing the knowledge he needed.

That failure connects to Andy Matuschak’s Why books don’t work: readers can fail to notice what they have not understood. Matuschak and Michael Nielsen’s Quantum computing for the very curious embeds recall questions in an essay and revisits them through spaced repetition, with email reminders bringing readers back. These checks make passive reading harder to mistake for learning, though remembering an answer is not itself a guarantee of understanding or permanent retention.

Litt’s explainers end with five medium-difficulty questions. His personal rule is to pass the quiz before sending agent-written code to teammates for review. He reports that it repeatedly catches gaps he otherwise would have missed. The quiz acts as a speed regulator: progress depends on his understanding as well as the code’s correctness.

The published Explain Diff skill has HTML and Notion output versions. That makes the explanation-and-quiz workflow something a developer can adapt to their own working environment, rather than a practice tied to the particular garden demonstration.

10:0510:22
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

10:05 · section reference included

Learn the machine by exploring its state

An explanation teaches from outside a system. A microworld gives the learner an environment to inhabit. Litt draws on Seymour Papert’s idea of Mathland: if children learn French by living in France, what environment would let them learn mathematics through similarly direct experience? Programming the Turtle robot to draw offered such an environment. The intended outcome was a change in the child’s understanding, not merely a working robot.

Litt encountered a similar need while implementing a Prolog interpreter for his own learning. He introduces Prolog as somewhat like a database query language. Written descriptions of its mechanisms could feel complicated even when the underlying idea became straightforward once it clicked. He wanted a representation that would help those ideas become intuitive.

He had Claude build an ephemeral debugger specifically for his interpreter’s internals. Scrubbing through a timeline exposes execution step by step, with the state visible at each point. He also added comments on the timeline so he could preserve observations and remember what he had been thinking. Program, stack, timeline, and notes become parts of one environment for investigating the machine.

Slide titled “An interactive debugger for a Prolog interpreter,” showing green text on black with Program and Stack panels, a timeline, and populated notes.
A Prolog debugger displays program code, stack state, a timeline, and step notes.

The debugger helped him fix individual bugs, but its value extended beyond each repair. While investigating a narrow failure, he developed a broader feel for how the interpreter behaved. Litt describes this as peripheral understanding: knowledge gained around the immediate task that would be missing if he simply delegated the fix and received the corrected code.

11:5712:06
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

11:57 · section reference included

Make a migration visible as it happens

A website migration exposed the same gap between an apparently successful result and a useful mental model. Litt asked Claude for a script to move his personal website from one framework to another. The script seemed to work, but reading it did not give him a feel for the transformation. Files had moved; he did not yet understand the process.

His next request was for something closer to a video game in which he could perform the port himself. The interface placed the old website on the left and the new website on the right. Each press of Next advanced the migration, displayed the commands being run, and made another part of the new site come to life. File trees below the previews showed files moving.

The interface preserved some of the learning benefit of doing the migration manually while removing much of the mechanical work. Instead of treating the migration as a single opaque operation, Litt could follow its sequence and connect commands to visible changes. This is a distinct use of agent-generated software: build code that helps a person understand other code. The microworld does not need to be a product intended for release; its purpose can be the understanding developed by its user.

13:5013:58
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

13:50 · section reference included

Let the team learn in the same space

Individual understanding is not enough when a team needs to invent and build together. Effective communication depends on shared concepts: names for system components, interface elements, and the ideas behind them. A team needs opportunities to develop those concepts collectively.

One approach Litt describes is a shared chat thread containing several humans and agents. A developer asks a product manager what users want from a feature; the product manager brings an agent into the conversation to help answer. Both people can see the questions, responses, and context as they develop. Litt compares this to moving from separate one-to-one conversations into Slack channels: more of the work becomes visible to everyone participating.

A collaborative document provides a second shared surface. When Claude produces a plan, a developer can leave a comment on the relevant passage and invite a teammate into the discussion. The question and its answer remain attached to the idea being discussed, rather than isolated in a local file or private agent conversation.

Litt says his team builds substantial amounts of code within Notion because that shared context is valuable. He describes support for bringing Claude and Cursor into Notion as having launched the previous week. Those relative launch dates are his account at the presentation; Notion’s July 2026 release notes document both External Agents and the HTML blocks used earlier.

14:5815:16
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

14:58 · section reference included

Build tools that develop the person using them

Explanations, microworlds, and shared spaces point toward an ambition larger than understanding code. Preserving people’s ability to understand how things work requires deliberate choices about what computers do for them. Litt connects that ambition to the origins of personal computing and Alan Kay’s essay A Personal Computer for Children of All Ages.

The pictured children can look, to a contemporary viewer, like children watching videos on tablets. But in the vision Litt describes, they are playing a game and changing its code to learn physics. The computer’s purpose is to develop the children’s capabilities. Litt presents AI as an opportunity to return to that educational ambition after computing’s departures from it.

Easier code generation makes ephemeral interfaces, simulations, debuggers, and playgrounds more practical to create for a particular learning need. Their value lies in what becomes understandable through using them. This possibility revives an old goal of computing: tools should expand what people can think about and do. With deliberate design, AI can put people more deeply into the work, equipped to understand it and shape its next iteration.

Slide stating that humans need to understand how things work and that the right tools can help us understand better than ever before.
With the right tools, we can understand better than ever before.
17:0117:06
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

17:01 · section reference included

Resources

From the talk

Read the complete timestamped transcript
  1. 0:00

    [upbeat music] What's up? Yeah. Thank you for coming to the Design Engineering track at AI.

  2. 0:16

    Is everyone having fun? [audience cheering]

  3. 0:18

    Yeah.

  4. 0:18

    Yeah, I think this is gonna be a great track, so get excited.

  5. 0:22

    All right, let's get going. Um, my name's Geoffrey Litt. I'm a design engineer at Notion currently, and I'm here to drop a hot take for this room maybe.

  6. 0:35

    I think it is still important for people to understand how code works. [audience cheering] [chuckles]

  7. 0:42

    Now, some of you might agree, some of you might disagree. Let's actually, let's do-- let's try a poll. I'm curious for this room. Raise your hand if you agree with that opinion.

  8. 0:50

    Okay, maybe some selection bias. Any brave-- Okay, raise your hand if you disagree with this opinion.

  9. 0:55

    Get out!

  10. 0:55

    Wow, okay. We, uh, [chuckles] maybe we'll do a debate later. Yeah. I was hoping we'd be at the AI Engineer conference, so we'd have more bo-- Okay. I might be preaching to the choir here.

  11. 1:06

    You know, I think we-- the reality is, though, we are entering an era where this is a legitimate question that people are debating, right?

  12. 1:13

    Agents are writing tons of code for us. They're landing fifty thousand line PRs, and it is getting harder to keep up. We all feel this.

  13. 1:22

    Now, I think the good news is, there are lots of ways to understand.

  14. 1:27

    The, you know, the days of just reading code line by line, that's not the only way anymore. And what the point of this talk is about is, I want to share with you a bunch of the practices that I use to understand the code that my agents are writing for me.

  15. 1:42

    This includes things like explainer docs teaching me about how my code works.

  16. 1:47

    My agents write quizzes for me to, to test my understanding. Am I still really in the loop? Am I keeping up?

  17. 1:55

    I have agents build me micro-worlds that I can inhabit to get this intuitive sense of how my code works that's deeper and richer than just a written document. And I think all of these are really exciting new possibilities that are open-- opening up for AI to help us understand better, not worse.

  18. 2:13

    And so that's what the point of this talk is gonna be about, and I hope I can leave you with some techniques that you can take home and use yourself.

  19. 2:22

    By the way, my timer isn't running. If you could get that running, that'd be great, so I know if I'm blabbering.

  20. 2:28

    Okay, but let's start-- Let's back up for a sec. Before we talk about how, let's talk about why. Why bother understanding? This is, again, it's a question now, right?

  21. 2:37

    And I think a lot of people get this subtly wrong.

  22. 2:42

    So what a lot of people think of why do humans still have to understand, they think we understand to verify. The agents do dumb stuff. We've all seen it, and your job as the human is to keep them in line, right?

  23. 2:53

    Make sure they don't screw up. When people say things like, "Code review is the new bottleneck," I think that's the first thing that pops into people's heads is correctness, checking.

  24. 3:05

    There's this mental model that's like, "Hey, the agent's gonna give you something, and what's your job? It's to ask, 'Is this correct?'" Now, correctness can have lots of definitions.

  25. 3:15

    Does it match the spec doc you gave it? Does it take down production? Is it well-architected? But fundamentally, those are all kind of thumbs up, thumbs down decisions, right?

  26. 3:26

    And the thing is, over time, we've all seen it, the agents are also able to ask these questions, and they're getting better at it. You give it the right verification loop, and over time, this is the reality.

  27. 3:38

    The, the role of humans in correctness checking is decreasing. And you know what? I actually don't hate that. If I have a clear idea of what I want to do and the agent does it correctly, instead of coming back to me with an incorrect thing, that's great.

  28. 3:52

    I'm, I'm into it. So then I think people extend this and say, "You know what? That means as the agents get smarter and smarter and smarter, we, we don't have to understand at all, right?

  29. 4:02

    Get out of the loop, man. Run the loop." And that's where I think people miss something really important.

  30. 4:08

    There is a deeper reason to understand what's going on, and that's understanding to participate

  31. 4:15

    because here's the thing, it's not just one loop.

  32. 4:19

    When you review what's happening and get in the loop, you come away changed. You understand something, and that understanding is what you take to the next loop, and the next, and the next.

  33. 4:32

    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. I think probably you've all, you've all felt even before AI, you know, the difference of the kinds of ideas that someone can have when they really understand what's going on versus when there are a

  34. 4:50

    few layers removed are different. Because when you have rich conceptual structures in your head that you can fluently recombine really fast without going out to, like, ask some, some agent or some human how it works, that gives you the ability to fluidly take creative leaps, and that's the human part of the work, coming up with the next

  35. 5:08

    idea and the next idea. So this is actually the real reason I think understanding matters, and this is not something that we can just wash away with better agents because if we wanna be active participants, you still gotta do this.

  36. 5:23

    There's a great term maybe some of you have heard called cognitive debt that I think really captures this spirit well. It's an analogy to technical debt popularized by the scholar Margaret Storey.

  37. 5:31

    Simon Willison also blogged about it. And I love this idea because similarly to tech debt, you might get away with it for a little bit, but at some point you get burned if your understanding degrades.

  38. 5:42

    And maybe you've felt this. I know I've felt it. You're vibe coding, things are going well, and then at some point you realize, "Wait, I have no idea what's going on.

  39. 5:49

    I basically can't participate anymore," right? You've built up too much cognitive debt.

  40. 5:56

    Okay, so maybe it sounds like all of you were already convinced. We agree. We need to understand.

  41. 6:02

    But how, right? We don't wanna live in 2023. We are using agents to move fast, and it is harder and harder to keep up. How do we do it?

  42. 6:13

    I think to answer this question, we should actually take a step back and a-ask a more fundamental question, which is: how do we understand stuff in general?

  43. 6:25

    Plot twist, this is not the first time that any human has asked this question. [laughs] There is a field. It's called education. [laughs] Now, when you think education, you might think of bad memories from sitting in lectures or whatever, but I think we can do better.

  44. 6:37

    We can take inspiration from the best ideas that have ever been invented in education and use them to stay in the loop and understand. So that's what this talk is about.

  45. 6:46

    We're gonna talk about three techniques. First, explanations.

  46. 6:53

    So when an agent writes some code, it's an opportunity for it to explain the work to you, right? And the most naive explanation is, "Hey, here's the code diff."

  47. 7:00

    That's the raw change, the material of what happened. But we can do, I think, much, much better.

  48. 7:07

    What would the best possible explanation be? Like, if you sent a team away for a year to come up with a personalized curriculum just to explain this one code change to you, what would that look like?

  49. 7:16

    I think this is a very generative question to ask.

  50. 7:20

    So I've done a bunch of attempts at this. One is this skill I wrote called Explain Diff, which I use every day, and a lot of my coworkers do as well, and I wanna walk you through it.

  51. 7:30

    So we're gonna go through a little example here. I'm working on a video game where you draw zen gardens, kinda de-stress. You know, could all use it these days.

  52. 7:39

    And we made a code change to change the perspective of the game from top-down to isometric. And I-- when I run my skill, it produces a code explainer doc.

  53. 7:48

    This can be an HTML file. It can be Markdown. I like to put them in Notion because I work there, but also because it's then collaborative, so my team can comment on it and talk about it.

  54. 7:56

    And here's how it looks. We start with background. We do not start with what happened in this change. It starts by teaching me, "Hey, here's how this system works.

  55. 8:07

    Here's the game engine we're using. Here's the coordinate system, right? Here's the subsystems." It makes sure that I'm sort of being led up to the point where I can even begin to understand what's going on here.

  56. 8:17

    Obviously, you can skip this if you already know. You can personalize it to what you already know.

  57. 8:23

    Second important principle is intuition before details. So before we start, you know, looking at code and stuff, it says, "Hey, the goal of this commit is to make the garden feel three-dimensional using only 2D drawing tricks."

  58. 8:36

    You can think of this sort of as like a well-written commit message, a little deeper. Give me examples. Give me a feel for the essence before, you know, you throw a bunch of code at me, right?

  59. 8:45

    This-- By the way, this is good teaching. This is what, like, good math teachers do.

  60. 8:51

    Third, interactive figures. So where it makes sense, give me things to fiddle with and try. So with this change, it was, like, changing how we draw rocks. So I can drag around rocks in this little simulation, and it shows me the coordinates that are happening, how the Z layers of the painting are changing.

  61. 9:07

    This, by the way, is actually using a new feature that Notion literally launched this morning of HTML blocks in Notion pages so agents can put interactive simulations into your Notion pages.

  62. 9:16

    Pretty cool. I think you have to be careful with interactivity. It can just be a crutch, and it can be kind of slop, to be honest. But used tastefully, it can provide an understanding that's hard to achieve with just static pictures.

  63. 9:30

    Okay, then we finally get to the code, right? Show me the code. But we don't just throw a list of files in order. We do what we-- what I call literate code diffs.

  64. 9:39

    Give me prose. Explain it to me in the right order. Tell me before each file what's going on. And when you accumulate all this stuff, it's much, much easier to follow than just a raw diff.

  65. 9:50

    Whoops. In fact, I print these out and take them to the coffee shop sometimes and just read them.

  66. 9:56

    I find it really beautifully ironic that AI is actually taking this process where I was-- used to be, like, glued to my computer and my IDE, and now I can go to the café, and it's like I'm reading a textbook about this PR.

  67. 10:05

    It's really cool. Okay, so there is one problem, which is that reading is hard, and I am lazy. [laughs] People are lazy. You know, there was this one time when I sent a PR to my coworker that I thought I had read the thing, I thought I understood, and she asked me the most basic question.

  68. 10:22

    And I was like, "Oh, no. [laughs] I don't know." I clearly hadn't understood, right? I had fooled myself. So I thought, "How can I create a system where that never happens again?"

  69. 10:32

    For inspiration, I look to the work of the researcher Andy Matuschak, who has this great line: "Books don't work." What he means by that is, it's really easy to read a book and not realize you didn't understand it.

  70. 10:43

    So the-- so he and his collaborator, Nielsen, tried this thing where in an essay, there are interactive spaced repetition quizzes that test whether you actually remember what you just read.

  71. 10:52

    And this is cool. It'll actually keep emailing you the quiz to make sure you remember it forever. But this is nice because you cannot get through this essay without understanding it [laughs] or at least without remembering it.

  72. 11:03

    That's what I do with my code explainers. At the very bottom, there's a quiz, five questions, medium difficulty. And my rule is I don't send code to, uh, others on my team to review unless I can pass the quiz about what my agents wrote.

  73. 11:18

    And it might sound kind of silly, but you should try it. It really is shocking the number of times this has caught me and made, and made me realize I didn't understand.

  74. 11:27

    I think of it as sort of a speed regulator. Everything AI is speed up, speed up, speed up. There's all these incentives to go faster. How do we make sure we're not just moving at the speed of correctness but also of understanding?

  75. 11:36

    And the quiz is that speed regulator. That's a system I can use for that.

  76. 11:42

    I did, uh, just put this skill on the internet, so yeah, photo moment. If you want the Explain Diff skill, uh, take that QR code, try it out, make it your own.

  77. 11:49

    It's really simple, actually. There's two versions of that QR code, one that outputs HTML, one that outputs Notion.

  78. 11:57

    Okay. Second technique, micro-worlds. What does that mean? So this takes inspiration from the educator Seymour Papert.[laughs]

  79. 12:06

    real visionary who had this idea of living in Mathland. And what that meant was, hey, kids learn French from living in France. Where do they go to learn math?

  80. 12:15

    Is there a Mathland where you can learn intuitively math just by being there? So he did these great things with, this is a, a robot called The Turtle that kids programmed to draw stuff.

  81. 12:25

    But the point isn't making robots, the point is they actually learn math by doing that programming. The, the point isn't the robot, it's the kids that are changed.

  82. 12:34

    So how could we apply this to understanding code?

  83. 12:38

    Here's one example. Last year, I was trying to implement, um, for my own learning, this interpreter for a programming language, Prolog, which is, think of it a little bit like a database query language.

  84. 12:47

    And there's all these parts of it that look like this, where when you read them on Wikipedia, they seem really complicated. And then when you actually get what's going on, it's like, wait a second, that wasn't that hard to understand.

  85. 12:56

    It just felt hard when I read it that way, right? How could we make it click more for my brain?

  86. 13:02

    So I had Claude make me a microworld. This is a debugger, ephemeral UI that was built specifically to visualize the internal implementation of my programming language. What's happening here is that I'm scrubbing through a timeline that's running step by step, what's my interpreter doing?

  87. 13:18

    It's visualizing all the state at every step. So I can kind of open the hood and see what's going on and start feeling it, you know?

  88. 13:25

    And yes, I can u- I use this to fix bugs. I even added a little, um, [smacks lips] hard to see here, but there's a commenting feature where I can leave comments for myself on the timeline so I remember what I was thinking.

  89. 13:36

    And I use this to fix, fix narrow bugs, but also, as I was fixing the bugs, I was getting a feel for the machine, right? That's something that if you just have an agent to go fix the bug, you don't get that peripheral vision.

  90. 13:46

    If you live in a microworld, you do.

  91. 13:50

    Another example, um, I was migrating my personal website from one framework to another, and first thing I did, I had-- I said, "Claude, write me a script to do it."

  92. 13:58

    It did this. It seemed like it worked, and I read the script and I was like, "Ah, I don't know." Like, I, I just don't have a feel for what it's doing.

  93. 14:06

    A bunch of files went a bunch of places it seems, right?

  94. 14:10

    So what I did is I said, "Hey Claude, make me essentially a video game where I do the port myself." And the way this works is old website on the left, new website on the right.

  95. 14:18

    I just click a button, next, next, next, and at each step it says, "Here's the commands I'm running." Your new website's coming to life step by step. You see it.

  96. 14:26

    There's actually file trees down there where you can see files moving. And it's-- the, the result is it's kind of like if I did it manually, but I'm just clicking a button.

  97. 14:35

    So I'm getting some of the benefit of doing it iteratively without the pain.

  98. 14:42

    And I think the big takeaway here is agents can write code to help us understand code, where the point isn't building software to ship, it's building these little micro-worlds for us.

  99. 14:51

    It's the Mathland, right? It's, it's a, it's a simulation of just this thing.

  100. 14:58

    Okay. Quickly, the last topic, shared spaces. So far we've-- this has all been about me, solo understanding. But a lot of the time, I think the challenge is actually you're working on a team, and your whole team needs to understand together so you can actually jam and have creative ideas together.

  101. 15:16

    We think a ton about this at Notion.

  102. 15:19

    We believe that, you know, the shared understanding that exists between you and someone else is what lets you communicate effectively, whether that's names for parts of a system. It could be names for UI elements or concepts, right?

  103. 15:33

    So we, we think a lot at Notion about how do you make tools that enable collective understanding.

  104. 15:38

    Some things we're exploring, can you have multiplayer chat threads between multiple humans and agents together? So here, you know, I might ask a product manager on my team, "Hey, you know,

  105. 15:49

    what, what are users asking for with this feature?" And she might say, "Hey, I don't know. Let's ask a different agent." And that agent comes in and talks to us.

  106. 15:57

    And what's happening here is that instead of me and my PM both talking to our own agents, we're in a shared space. We can see each other's communication. It's kind of like, you know, going from one-on-one conversations to Slack channels, you know?

  107. 16:09

    You see more of the behavior happening together, and you understand together.

  108. 16:14

    Also, having documents that you can talk about together is a really powerful primitive. Here, you know, Claude made us a plan.

  109. 16:21

    What if I have a question about that that I wanna discuss with my team? I can just leave a comment because this is in a collaborative space, not on my computer locally.

  110. 16:29

    And then I can ask, "Hey, you know, what do you think about this?" And my teammate can chime in and, and we can talk about it right there, right?

  111. 16:35

    I think having these spaces for shared discussion around ideas with our agents is really powerful for building up that collective understanding.

  112. 16:44

    This, by the way, um, we just launched last week, the ability to bring coding agents into Notion, so Claude and Cursor can now live in Notion. And our team actually builds a lot of our code in Notion itself, mainly because of these benefits, because having it in a shared space is just so valuable.

  113. 17:01

    Okay, so we've talked about these three techniques, and I wanna bring it back to the beginning.

  114. 17:06

    You know, I think at the beginning I said it's important for humans to still understand how the code works, right? But I actually think it's much bigger than that.

  115. 17:16

    I kinda think it's just important for humans to still understand how everything works. [laughs]

  116. 17:22

    And maybe, you know, you all agree it sounds like. But this, I think, is being called into question now and is something we actually have to actively fight for.

  117. 17:30

    The thing is, this is not a new battle. It actually hearkens back to the very origins of our field.

  118. 17:36

    Alan Kay is one of the pioneers of personal computing, co-inventor of the modern GUI. And literally fifty years ago, he wrote this essay that I find very prescient, called "A Personal Computer for Children of All Ages."

  119. 17:48

    It looks like two kids on iPads watching YouTube or something, [laughs] right? It's kinda crazy. This is fifty years ago, his vision. But that's not YouTube on the iPads. What he envisioned is, hey, these kids, they're playing a video game and they're modifying the code as they play it to learn physics.

  120. 18:03

    So the point isn't the computer, it's the kids. The, the point of computers was to level us up as humans, right? And Alan has talked a lot about how it kinda feels like at some point computers detoured a bit from that vision.

  121. 18:16

    But I think the exciting thing is maybe now's the time to bring that back.

  122. 18:20

    Here's kind of the meme version of that. [laughs]

  123. 18:23

    I think with AI, a lot of people are waking up to, oh my gosh, code is free. We can make ephemeral UIs, dynamic simulations to understand concepts. We can make debuggers, playgrounds.

  124. 18:34

    And it's like, yes, that's great, and it's actually not a new idea. Like, this was the goal all along. And so I think the optimistic thing that I find really exciting is,

  125. 18:45

    hey, it's still really important to understand how things work.

  126. 18:48

    And with the right tools and the right mindset and the right creativity, we can actually understand better than ever before, not less. With AI, we can kind of empower ourselves more, not just taking ourselves out of loops, but actually putting ourselves more deeply in loops than we ever have before.

  127. 19:05

    And I think that's a really exciting prospect, and I hope it's something that we all together as an industry figure out.

  128. 19:12

    That's all I have for you today. Thank you so much. [audience applauding] [upbeat music]