Understanding is the new bottleneck
Your browser is ancient! Upgrade to a different browser or install Google Chrome Frame to experience this site.
July 2026
Understanding is the new bottleneck
This is a written version of a talk I gave at the<br>AI Engineer<br>conference in July 2026, also shared as<br>a tweet thread.
Hot take: I think it's still important to understand the code that our agents write!
In this talk I'll explain why that's the case, and show some ideas for how to efficiently understand code. Alright, let's dive in.
Agents are writing more and more code for us, and we all know it's getting harder to keep up.
But the good news is: there are many ways to understand code! Reading diffs line by line is not the only way.
Most of this talk will be about techniques I have found helpful to understand systems my agents are building:
Code explainer docs
Quizzes to check my understanding
Micro-worlds that I can play with to understand the system
But first we have to ask a more basic question…
Why understand?
Why? Why understand?
Aren't we supposed to be taking ourselves out of the loop now, and letting the agents loop themselves? As the agents get smarter, doesn't it become less important for us to be in the details?
I think many people — even those who are pro-understanding — have a slightly incorrect answer to this question!
One possible answer: we understand to verify. We check the agent's work, we see if it's correct.
Correct can mean many things: does it match the spec, is it well architected… but it's fundamentally a thumbs-up / thumbs-down question.
Here's the thing: the agents are getting better and better at verifying their own work. And this is good! I like it when my agent doesn't make mistakes.
But hmm. Where does that leave us humans?
That's where another answer comes in: we can understand to participate.
You can learn what the agent is doing to make sure you can be an active participant in the creative process. Here's why this matters…
It's never just one loop! A project is many, many loops with the agent.
And the understanding you have of the system is part of your ability to come up with the next idea to evolve it.
You need a rich set of concepts in your mind to think creatively and fluently about how to move something forward. If you're lacking that fluency, your ability to participate in the project is meaningfully limited.
By the way, this relates closely to the idea of cognitive debt, popularized by Margaret Storey and Simon Willison.
It's like tech debt: you can get away with not understanding what's going on in the short term, but it'll bite you eventually.
OK, so fine, understanding matters.
But this raises the next question: how? How do we build this human understanding when we're working with AI and moving fast?
Well, turns out this is not the first time anyone has ever thought about how to communicate understanding. I think we can look to education as an inspiration. Can we steal the best ideas ever invented for education and apply them to this problem?
Technique 1: Explanations
Today I want to share three techniques that show how we can attempt this.
First: explanations. What makes a good explanation?
Whenever an agent finishes some work, it's an opportunity for an explanation — an artifact.
Most naively, we can read a code diff: the raw material that changed.
But what if we ask:
What would the best explanation be? If you had a team — human or AI — that really sweat the details of explaining something well to you, how would that feel?
Here's one answer. I made a skill called /explain-diff, which I use every day and many coworkers have found valuable.
It outputs thoughtfully structured code explainers as HTML, markdown, or Notion docs. Notion is a good place for collaborating on and discussing these explainers as a team. (Disclaimer: I work at Notion so I'm biased.)
Let's see what's in one of these explainers, using an example of editing the perspective of a video game.
First principle: teach me background info!
Before we even get to what changed, help me understand what was already there. In this case, teach me about the game engine.
Second principle: intuition before details.
Before any code, it states the goal — “make the garden feel three-dimensional with 2D drawing tricks” — and explains related concepts, like what isometric projection is.
All of this builds my intuition for the essence of the change. It's catching me up as the human so I can be an equal participant in understanding.
You can also build intuition with interactive figures .
Here I'm understanding the isometric perspective by dragging rocks around the garden and watching their coordinates move.
(This is using a new feature Notion just shipped: you can now embed interactive HTML inside pages.)
We finally get to the code. But a typical diff is a pile of files edited in alphabetical order with no explanation.
A “literate diff” as I call it is...