Geoffrey Litt argues AI coding's limit is human understanding, and proposes explanations, quizzes, and micro-worlds
- Notion design engineer Geoffrey Litt argues that people should understand agent-written code to participate in iterative design decisions, not only to approve or reject a finished change.
- Litt connects lost familiarity with an AI-built system to cognitive debt, an idea associated with Margaret Storey and Simon Willison: short-term speed can leave humans unable to reason about later changes.
- His first proposed technique is an agent-produced code explainer document: rather than reviewing only a raw diff, the agent creates a dedicated explanation artifact after completing work.
- The talk proposes three education-inspired ways to build understanding of agent-built systems: explanations, quizzes that test the human's understanding, and playable micro-worlds.
Hacker News opinions
I read every production commit until I understand it. I own the consequences, and an AI agent cannot take that responsibility. Agent-written code arrives 3 to 5 times faster, though, so reading easily turns into exhausting skimming.
The tips may help with volume, but an LLM can hallucinate its explanation of complex code. I want guidance on making the LLM build a stable architecture rather than an unstable pile of code.
We still architect and guide the LLM, and it does a decent job within that boundary. Fully handing system architecture to a model seems far off because business requirements are not merely technical.
Our LLM-generated PR descriptions are widely disliked. They explain mechanical changes at length, miss the motivation, and cannot validate the code if the same LLM generated both the change and the explanation.
I get useful PR descriptions when I ask targeted questions and supply context. The default output is not the only possible output.
My problem is Claude turning a change that should be 3 lines into 200 lines. Then I have to review needless complexity and a formal, oversized PR description from coworkers who submitted it without understanding it.
If I cannot understand agent-written code quickly, I throw it away and start over or write it myself. Cheap code means we should not fall for sunk cost.
I agree that understanding is the limit, but it always was. LLMs speed up typing, while the hard work remains understanding the problem and choosing the right solution.
Typing is easy but still consumes time, so LLMs help. The issue is that people have a limited understanding budget, and agents make them spend it across far more code and projects.
The real failure predates LLMs: code can work while violating the system's underlying model. An LLM can help clarify the model in discussion, but it will also retain inconsistent statements and cannot be the authority.
Code often leaves its model implicit, so documentation generated from code becomes mechanistic garbage. Document the model separately, or encode it in language abstractions so the model and implementation cannot drift apart.