AI Engineer Code Summit · Wed 11 Nov 2026 · Mainstage

Code is memory

Lauren Tan (“Potato”) shipped three thousand pull requests to production in a month. Her talk is about why that volume doesn't turn into slop. Read with the notes taken in the room, it comes down to one idea: the codebase is the agent's memory, and verification loops are how you keep that memory clean.

Lauren Tan, SpaceXSI (xAI) · 18 min · Links and further reading
The volume

Everyone is a coding machine now

Before agents, a few engineers were “coding machines”, wildly productive outliers. Now anyone can be one. She used to review three pull requests a day from colleagues; now it's more like three hundred. Every engineer is a team of hundreds of agents, and code arrives as a continuous stream.

Her thesis: the engineer's job is now to keep, or raise, code quality while productivity explodes, and the way to do that is trust. Not blind trust, but an environment built so you can trust agents to do the right thing. It took her six months to get there.

Evidence: transcript 00:01:40, 00:04:26

The memory

Code is memory

Agents produce output from their inputs, and the codebase is the biggest input. So it works like memory: workarounds, anti-patterns, deprecated code and tech debt get copied by the next agent, because they look like the established pattern. Her image is a garden where weeds spread before you notice; constraints and guardrails are the concrete that new code grows around. She calls it organic architecture.

“So you want to make your codebase as pristine as possible, so that agents are always copying the right stuff.”00:04:26

Dune, the client framework they built (she describes it as Next.js for Electron apps), encodes those lessons as constraints. Anything that needs nuance gets banned: React's useEffect is allowed only inside a few framework APIs, so the problem is gone rather than caught in review. Folder structure carries context too: main-thread and renderer code sit in two top-level directories, and imports between them are blocked by a dependency check.

From the notes: “code is memory”, and “nuance tends to create slop, so just design better APIs”. The codebase isn't only what agents edit; it's what they remember.

Evidence: transcript 00:02:55, 00:04:26, 00:05:56

The rule

Comment slop

Agents write a lot of markdown: docs, code comments, rules, skills. They use it to justify not doing something, or to turn one small correction into a rule that can never be broken. Her example from earlier work on Cursor: agents patched an architecture clash with timers and wrote comments explaining why each quick fix was fine. The timers spread and the app got slower.

So they banned 99% of comments. Comments go stale, people don't read them, they give agents an excuse, and nothing enforces them. Lint rules with helpful error messages tell the agent to fix the root cause instead. It's her trust pyramid: prefer the code itself, then linters, types and tests, then verification, and only a thin layer of prose rules last.

“And so our general principle is that every time we correct our agents, it turns into one of these deterministic checks.”00:07:54

Do that enough and there is less and less to look for in review, until most pull requests can merge without a person reading them.

From the notes: “comment slop”, and “stop agents from writing unsolicited markdown”. The comment is the slop, because it can't be checked.

Evidence: transcript 00:02:55, 00:07:54

The loop

Review the evidence, not the code

What replaces reading code is verification. Review has shrunk to looking at artifacts: videos, screenshots, a feature map of what the app does from the user's side. Agents run the app themselves through the same debugging tools people use.

“And our code review process has now really shrunk into looking at verification artifacts.”00:10:40

Then formal verification, which she still treats as an experiment. TLA+ model-checks whole user flows, such as notifications arriving across several devices. Lean proves specific algorithms: their own list-virtualization library, checked so it can't flicker or jitter. It has already found real bugs, and she is clear it is not a silver bullet. For the interface, property-based testing with bombadil explores the app looking for broken rules. A tweet she cites says 70 percent of one developer's daily tokens now go to verification, and she says that matches her own.

“And really, we are entering a golden age of software testing”00:12:50
Read alongsideHer pstack plugin makes this routine. The statechart skill has the agent write a TLA+ model, check it, and draw what the user sees, marking each broken rule with the shortest path to it; rules come only from behavior a person agrees to and are never weakened to pass. Other skills turn one proved property into a check that reruns on every change, and tell model drift from real bugs.
From the notes: “code review has become looking at verification artifacts”, and the read of the whole talk: “this is all about verification loops really”. It is the move Ankit Jain made yesterday: review intent and evidence, not diffs.

Evidence: transcript 00:10:40, 00:12:50

The factory

Don't automate a bad loop

The payoff: the team shipped eleven thousand pull requests to production, cuts a stable release about once a day, and 227 people contributed at least one pull request in October. The share of reverted pull requests has fallen to about half a percent, and the app got faster at startup, typing and switching chats.

“A ridiculous eleven thousand pull requests to production, which is a wild number.”00:14:22

Her warning comes before any of that: fix the codebase first, clean up old patterns, and make verification strong, because that work is the prerequisite for automation. Then the outer loop is easy: every release now spins up agents that fuzz the build like a real user, open fixes for what they find, and auto-merge them.

“Then automating that loop just produces more slop.”00:16:10
From the notes: “don't automate a bad loop”. Clean memory and real verification are what make the factory safe to build.

Evidence: transcript 00:14:22, 00:16:10