At the AI Engineer World’s Fair, Geoffrey Litt reframed the AI coding conversation around human limits rather than model capabilities, warning that delegation without comprehension turns developers into spectators who accumulate cognitive debt and lose creative control over iterative projects.
before @geoffreylitt 's talk I was 90% given up on sloppy work around me, now i am more hopeful. the future will be very polarized: those who understand will keep having the next big idea. those who delegate understanding will be replaced by the agent.
Just spoke at AIE about how and why humans need to understand our code. Turns out people care about this!
Litt described code explainers that front-load context and intuition, quizzes that act as speed bumps before the next AI iteration, and playable micro-worlds that let people step through behavior instead of scanning diffs.
The talk surfaces an unresolved tension around team-level adoption, noting that joint mental models in shared spaces may be needed yet leaves open how many groups will invest in the extra scaffolding required.
Users are praising threads and talks on understanding AI agent code as insightful and crucial for effective human-AI collaboration in coding.
No Digg Deeper questions have been answered for this story yet.
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. 2/
OK, so that's explain-diff. Here's the skill if you want it: two variants that output either HTML or Notion page. 23/
https://gist.github.com/geoffreylitt/a29df1b5f9865506e8952488eac3d524
I really like this "understand to participate" framing of the cognitive debt problem when working with coding agents
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... 7/
Most of this thread will be about techniques I have found helpful to understand systems my agents are building:
> Code explaner 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... 3/
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)
Let's see what's in one of these explainers, using an example of editing the perspective of a video game.
14/
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. 8/
Another example. I was migrating my personal website from one framework to another, and Claude wrote a script that did it — something like this. But it was very hard to review: I wasn't familiar with the new framework, and all I could say was "I guess that looks about right."
So I asked Claude to make me a video game — a command center where I do the port myself, step by step, watching the visible effects and the file tree evolve.
It produced a UI where I click buttons to run the port step by step, with my old site and new site running side by side.
In this command center I watched the new site come to life incrementally. That left me with a similar understanding to doing it by hand — but much faster, because the whole experience was laid out for me. 28/
BTW, this relates closely to the idea of Cognitive Debt popularized by Margaret Storey and @simonw.
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. 9/
This makes me very optimistic about the future!
If we build the right tools, we can now understand the world better than we ever could before. We don't have to merely take ourselves out of the loop, we can get deeper in the loop too. It's up to us.
FIN
36/36
And now hopefully you understand this meme.
The point was always to augment, not just automate.
It's beautiful that AI now makes creating simulations so accessible... Having AI teach us is one of the greatest possibilities computing has ever opened up. 35/
Blogged about it here: https://simonwillison.net/2026/Jul/2/understand-to-participate/
"You need a rich set of concepts in your mind to think creatively and fluently about how to move something forward."
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... 7/
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 structured as prose — walking through the changes in a sensible order, with surrounding explanation and embedded code snippets. Faster to review than a raw diff. 18/
Papert had this beautiful idea he called living in Mathland: if you want to learn math, live in Mathland — just like if you want to learn French, you go live in France.
Could we build an environment where children learn math naturally, as a consequence of their curiosity?
So how do we apply that to code? Can we make worlds you inhabit and naturally intuit how the system works and how it's changing? 25/
Today I want to share three techniques that show how we can attempt this.
First: explanations. What makes a good explanation? 11/
I do something similar with my code explainers now. At the bottom of an explainer there's an interactive quiz — five questions about the change — and I try to answer them.
My rule: I won't send code to others until I can pass the quiz, and I do the same when reviewing others' code. 21/
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! 4/
There's only one problem: reading is hard work 😅
As @andy_matuschak says: "books don't work"! It's too easy to fool yourself into thinking you did the reading when you really didn't retain or understand.
How do we fix this? I took inspiration from Andy and @michael_nielsen 's work on embedding spaced repetition quizzes in essays. 20/
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. 15/
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. 16/
