Three days ago, Jarred Sumner published a blog post about using an AI Agent to rewrite Bun from Zig to Rust.
The entire rewrite took only a few days. A JavaScript runtime, ported from one language to another — with an AI Agent doing the vast majority of the work.
What’s shocking isn’t “AI can write Rust now.” It’s that this fundamentally changes our definition of “understanding code.”
In the past, a developer needed months to understand Bun’s codebase — reading source, following issues, submitting patches. Now, an AI can traverse the entire codebase in minutes, generate replacement plans, and even pass the full test suite.
The question is: when AI writes code far faster than we can read it, does “understanding” still matter?
0. The Meta-Question: When Writing Code Is No Longer Scarce, What’s Your Moat?
In early July 2026, the AI Engineer World’s Fair convened in San Francisco. Among over 300 talks, one concept from Geoffrey Litt resonated widely.
He wasn’t talking about prompt engineering, or tool calling. He was talking about something that sounds almost cliché — “understanding.”
But he phrased it differently. The term he used was Understand to participate.
The challenge Geoffrey faces: when Coding Agents start independently completing increasingly large-scale code changes, your understanding inevitably drifts away from the code’s actual state. This accumulated gap is cognitive debt.
Cognitive debt is not the same as technical debt. Technical debt lives in the code — tight coupling, missing tests, confusing naming. Cognitive debt lives in your mind — a gap between your mental model of the code and the code’s actual state.
What’s worse: cognitive debt has no compiler error. You won’t get a warning saying “your understanding of this module is 3 weeks out of date.” You’ll only discover it three weeks later when you attempt a seemingly simple change and realize the entire system no longer looks the way you imagined.
Simon Willison added a key observation when sharing Geoffrey’s talk:
“You need a sufficiently deep understanding to be an actively creative participant. If you lack a rich enough set of concepts in your mind, your ability to participate in the project is concretely limited.”
Translated into engineer-speak: AI can write code for you, but it can’t think about architecture for you.
1. “Reading Code” Went from Basic Skill to Core Competency
Ten years ago, one difference between a senior and junior engineer was “code reading speed.”
A senior engineer could glance at a piece of code and immediately know what it does, where the problems are, and what a change would affect. A junior engineer had to grind through it line by line.
Now, a junior engineer’s AI assistant can “read code” too. Give Claude Code the full repository context and it can instantly tell you the call chain of any function, or the likely root cause of any bug.
So “reading code” has been split in two.
One half is what AI can do: fast scanning, pattern matching, dependency analysis. This half has been thoroughly commoditized.
The other half is what AI can’t yet do: judging what matters and what doesn’t.
Geoffrey’s original words:
“You need a rich set of concepts in your mind to think creatively and fluently about how to move something forward.”
In other words: you need a concept network in your head to think creatively about the next step.
This isn’t about “memorizing API docs” — AI does that a hundred times better than you. It’s about knowing when to question a design decision, when to accept a tradeoff, and when to tear something down and start over.
Lesson 1: AI eliminates the barrier of “can I understand this,” shifting the competitive focus to “do I know what’s worth understanding.”
2. Bun’s Zig→Rust Rewrite: A Textbook Case
Back to the Bun story. Jarred Sumner wrote this in his blog:
“Until recently, the choice of programming language for a project like Bun was a one-way ticket. Everyone knows you shouldn’t stop and rewrite a large piece of software from scratch. Joel Spolsky said back in 2000 that it’s the single worst thing you can do.”
But Coding Agents changed the equation.
The dilemma the Bun team faced was concrete: Zig’s handling of mixed GC and manual memory management produced endless use-after-free, double-free, and “forgot to free in the error path” bugs.
Jarred said: “I got tired of going to bed every night worrying Bun would crash.”
In safe Rust, these bugs become compiler errors. RAII-style automatic Drop cleanup inherently solves the resource leak problem.
But what really made the rewrite possible was a non-technical factor: Bun’s test suite was written in TypeScript.
This meant the test suite was implementation-language-agnostic. Swap the implementation from Zig to Rust, and the tests still run. This consistent suite became the automated acceptance criteria for the AI Agent — “translate this Zig code to Rust, run the tests, try again if they fail.”
Lesson 2: The role of the test suite changes in the Agent era — it’s no longer just a quality guard, but the Agent’s “autonomous learning feedback signal.”
Simon Willison, when commenting on this in his blog, pointed out another key aspect:
Jarred started the rewrite as an experiment — he just wanted to try the then-very-early Fable model. “At first I didn’t think it would work. A few days later, a high percentage of functionality was already running.”
This reveals a subtle psychological shift: the core of Agent engineering is no longer “can I do this,” but “am I willing to try.”
3. Three Faces of Cognitive Debt
Putting Geoffrey Litt’s and Jarred Sumner’s stories side by side, cognitive debt manifests in AI programming in three ways:
| Type | Symptoms | Solution |
|---|---|---|
| Understanding Lag | AI produces piles of code; you can’t keep up reading it | Geoffrey’s “understand to participate” — don’t aim to understand every line, aim to understand architectural decisions |
| Decision Outsourcing | AI picks solutions for you; you don’t know why | Make AI explain the tradeoff, rather than giving you the answer directly |
| Confidence Bubble | All tests pass, so you feel safe | Use AI for adversarial review — scrutinize your own code from an attacker’s perspective |
The third is a technique used in the Bun rewrite: Jarred had one Agent write code and another Agent do adversarial review. Let AIs challenge each other, not just cooperate with you.
This actually circles back to Geoffrey’s core argument: the purpose of understanding is not “comprehending,” but “being able to participate.”
You don’t need to understand every line of code. But at key decision points — architecture choices, interface design, error handling strategies — you must be able to say “this part is wrong, let’s try a different approach.”
Lesson 3: “Comprehending” is passive; “participating” is active. The decisive factor in AI programming isn’t how fast you learn, but whether you dare to say “no” at key decision points.
4. Three Things You Should Do
First, shift Code Review’s focus from “finding bugs” to “finding decisions.”
In the past, when reviewing code, we watched for potential null pointers, boundary conditions, and performance hotspots. After AI starts writing code, these low-level errors actually become rarer. The real danger is — AI makes an architectural assumption somewhere that seems reasonable but is fundamentally wrong, and that assumption influences all subsequent implementation.
The Claude Code team shared a suggestion at AIE: let Fable use its own judgment to decide when to write tests, rather than telling it “only write tests for big features.” The same logic applies to review — you shouldn’t review every line, but every architectural decision.
Second, design your test suite as the Agent’s learning environment.
Bun’s TypeScript test suite is a perfect example. It’s independent of the implementation language, giving the Agent an objective right/wrong standard. If you’re working on a project, make sure your integration tests aren’t tightly coupled to the current implementation — they should be “behavioral specifications,” not “implementation snapshots.”
Third, do regular “reverse understanding” checks.
The core problem with cognitive debt, as Geoffrey describes it, is that you don’t know what you don’t know. One practical approach: every two weeks, pick a module you let AI write, and without looking at the code, sketch its architecture and data flow on a whiteboard. If you can’t draw it, or if what you draw doesn’t match reality — that’s the interest on your cognitive debt compounding.
Summary
| Decision | The Fundamental Question It Answers |
|---|---|
| Shift review focus from bugs to decisions | The purpose of understanding isn’t finding errors — it’s participating |
| Test suite as Agent learning environment | Is the feedback signal you give AI objective enough? |
| Reverse understanding checks | How do you know what you don’t know? |
| Adversarial review | Is your confidence a bubble? |
Lesson 3: “Comprehending” is passive; “participating” is active. The decisive factor in AI programming isn’t how fast you learn, but whether you dare to say “no” at key decision points.
The biggest change AI programming brings isn’t a new tool. It transforms the scarcest resource in software engineering from “time to write code” into “mental bandwidth to understand code.”
In the past, your productivity depended on how much code you could write. Now, your productivity depends on how deeply you can think alongside AI — and the prerequisite for thinking is understanding.
🎯 If you’re also using Claude Code / Codex for daily development but feel increasingly disconnected from your own code —
- 📬 Follow 「全栈之巅 - 梦兽编程」 for weekly AI programming engineering practices
- 🔧 Visit AI Tool Directory for the latest AI development tools
References:
- Geoffrey Litt, “Understand to Participate”, AI Engineer World’s Fair 2026
- Simon Willison, Understand to participate , Jul 2 2026
- Jarred Sumner, Rewriting Bun in Rust , Jul 2026