Understand to participate

Simon Willison recently highlighted a talk by Geoffrey Litt at AIE that condensed a profound challenge into four words: Understand to participate. It sounds obvious, but in the current wave of AI coding agents, it hits a very subtle pain point.

Origin: When agents write code faster than we can read it

Tools like Cursor, Copilot, and Claude Code have made AI-generated code routine. A single prompt can produce hundreds of lines of correct logic or refactor an entire module in seconds. Efficiency skyrockets, but a deeper question emerges: how much of your project do you truly still understand?

Litt labeled this drift as cognitive debt. Technical debt we know—messy code that costs more to maintain. Cognitive debt is different: it’s not about code quality but the growing gap between your mental model and what the code actually does. You think a function works one way, but reality drifts, and you don’t notice until something breaks.

Deconstruction: Why cognitive debt is more dangerous than technical debt

Technical debt is visible; you can measure, refactor, and schedule it. Cognitive debt is invisible and often unrecognized. You might not realize you’re in debt until you suddenly can’t read a module the agent wrote two months ago, or you lack confidence to modify seemingly working logic.

Litt argues this debt directly damages your ability to participate. He compares it to fluency: you need a rich set of concepts in your mind to think creatively and fluently about advancing a project. Without that fluency, you demote yourself from driver to ‘confirmation-button pusher’. You lose the agency to shape the product; you just accept what the agent gives you.

Trend insight: The new human-AI collaboration divide

This reveals a subtle but seismic shift: the stronger AI tools become, the higher the cognitive demands on the user. Many assumed AI would let ‘anyone code’, but reality suggests deep systems thinking and architectural understanding are more critical than ever.

Before, you built code line by line, naturally absorbing detail. Now code materializes like magic, but after the magic fades, if you haven’t deliberately interrogated, questioned, and reviewed, you find yourself in a forest of unfamiliar code. The core skill of future engineers may not be ‘writing code’ but ‘managing and sustaining high-level comprehension of code semantics’—like shifting from craftsperson to site superintendent, needing to know where every brick is and why, even if you didn’t lay them.

Practical value: How to guard your understanding

This isn’t just theory; it suggests concrete actions:

1. Treat understanding as a deliverable. Set a rule: no code is ‘done’ until you truly understand it. Have the agent explain its changes, draw diagrams, or document decisions—force digestion.
2. Conduct regular ‘cognitive audits’. Pick a module and try to draw its flow or state machine without looking at the code. Inaccuracies reveal where your mental debt lies.
3. Build a teaching-learning relationship with the agent. Don’t just accept outputs; ask the agent to explain its reasoning. This keeps you in the loop and can uncover hidden agent mistakes.

Counterintuitive: It’s not easier, just a different kind of hard

Many adopt AI coding to reduce mental load. Yet Litt’s view implies the most effective long-term users are those who willingly shoulder a higher cognitive load—redirecting saved time into higher-order thinking: understanding structure, questioning design intent, and anticipating ripple effects.

In short, AI hasn’t made programming simpler; it has redefined which part is hard. The old hard was syntax and details. The new hard is keeping the map in your head clear and complete—and that map is the irreplaceable source of your creative power.