Theo’s Case Against Automatic Coding-Agent Memory

A coding agent needs to understand the repository, where things live and how work gets done. Many systems try to save this context automatically for future sessions. I am skeptical that a separate memory store is the right place for evolving facts about a codebase.

I start with a conversation between Mario, creator of Pi, and Armin, creator of Flask. Their discussion of memory and minimal tools prompted me to inspect my own Claude Code setup and explain what I prefer to put in project instructions.

Mario argues that code is the ground truth and changes over time. A separate memory system creates another place to maintain. I agree that even ordinary comments can become harmful when the code changes and the comment keeps telling readers or agents the old story.

The more copies of knowledge you maintain, the easier it is for them to diverge. Old plans and Markdown files can stay in the repository long after their assumptions have expired, and that stale context can steer an agent in the wrong direction.

Mario suggests that models can infer style from nearby code, while a short directory map can help them navigate. He is skeptical of elaborate retrieval systems without evaluations showing they improve output. That is his position, not a controlled test of every retrieval approach.

I compare this with the evolution of coding tools such as Cursor. Earlier tools invested heavily in gathering context for models; newer coding agents can use shell and file tools to seek out relevant code themselves. I favor giving them useful tools over assuming a complex index is necessary.

Mario describes a Slack bot that searches an append-only log of prompts and responses using jq. Instead of maintaining a separate summary, the bot can look up the underlying record. That example also shows that conversational history and a changing repository are different problems.

I think memory can be more useful in general chat than in code. A personal question may relate to an earlier, apparently unrelated detail, whereas code often offers explicit paths and references to investigate. Still, personal context can also bias an answer toward irrelevant past details.

The Pi discussion turns to small tools and shell composition. Armin describes building a Sentry skill that authenticates as he prefers, downloads results to JSON and exposes only a small sample to the model, leaving it able to inspect the rest when needed.

I agree with the value of keeping tool output manageable, but I am less convinced that every integration needs a new skill. Strong models can often use ordinary tools and decide what to read. The right approach should be evaluated in the workflow, not assumed from the label.

I ask Claude Code what it has stored about T3 Code. On one machine it reports a single memory about a feature spec that I am not even planning to ship. That makes me wonder what other temporary details have been saved elsewhere.

On another machine, the inventory covers multiple project directories and includes notes about configuration experiments, benchmarks, plans and projects. Some information might have been useful at the time, but it can become misleading if the state has since changed.

The main T3 Code clone has 45 memory files in the agent’s inventory. They include onboarding and design work. I ask the agent which entries still earn their keep, because my concern is not merely the number but whether old notes remain accurate and relevant.

The agent estimates that roughly a third of the 45 files are still useful. It groups others as duplicating AGENTS.md, describing shipped features, or recording point-in-time conditions that could have changed. This is an agent-generated assessment of my files, not an independent study.

I inspect examples: an outdated CLI issue, old plans and notes from probing an integration. Some entries record details from a specific investigation without making clear whether they remain true. One worktree warning may still be useful, which illustrates that not every saved detail is equally bad.

Other memories describe how T3 Connect worked during a particular development effort and the possibility of state conflicts. I can reconstruct why the agent wrote them, but I am not convinced they belong in a persistent store that may influence later work.

I decide to have my own machines archive the existing memories and disable the feature. That is my choice for my workflow; readers should inspect their own situation before changing or removing information they may need.

The agent’s transcript audit reports about 355 T3 Code sessions on that machine: 19 opened an individual memory file, while roughly 80 wrote or edited one. It also says 26 of 45 memories were never read after creation. These counts describe that local sample and method; they do not establish the value of memory for all users.

What do I want instead? Two related but distinct outcomes: fewer avoidable errors, and an agent that understands my direction without requiring every detail in the prompt. I do not believe indiscriminately saving more memories reliably supplies both.

Adding a “do not do this again” rule after every mistake can help, but it is worth stepping back. The real problem may be unclear communication, an unintuitive architecture or a mismatch in how the team and the agent understand the product.

I prefer instructions that communicate how I want the agent to think and what the team values. When the agent understands the direction, I find that many smaller errors become less frequent. That is an observation from my own workflow, not a guarantee.

Lauren proposes an order for preventing repeated mistakes: eliminate the failure through architecture or data structures; then use a lint rule or test; then consider a skill or rule; and finally rely on human review. I like this hierarchy as a way to ask which layer can prevent the issue.

For example, I value tRPC and Convex because shared types and architecture can remove some classes of frontend–backend mismatch. Making a codebase easier for human contributors can also make it easier for agents to navigate and change safely.

If architecture alone cannot prevent a regression, make it detectable in CI. T3 Code had a concrete performance problem: loading threads over WebSockets was transferring tens of megabytes, which was particularly painful on weak mobile or airplane connections.

I reduced the transfer volume and built a local replay suite using large sample threads, but regressions appeared again within days. So I added CI measurements for replayed Codex and Claude threads and a PR comment that shows the impact of a change.

After the optimization, the examples were consistently under 100 KB, with most under 10 KB. I set a ceiling roughly 30% above the optimized baseline; crossing it fails the check. I have seen this catch real regressions and give the agent feedback before it reports completion.

My preference is to exhaust architectural and automated-test options before introducing another skill or rule. A skill can be useful for a process that cannot easily be expressed in the codebase, such as exposing a development server remotely. It is a fallback, not a universal substitute for design.

Human review remains another layer when automated approaches are insufficient. I apply the same thinking to a possible SwiftUI rewrite: the existing web, Electron and React Native surfaces share TypeScript data-loading code, while a separate implementation risks drifting.

A SwiftUI app has already regressed in my experience because that shared relationship is less direct. We have held back a version I otherwise like because the architectural tradeoff could allow failures that the shared implementation currently avoids.

Theo plays an excerpt in which Uncle Bob argues that human values matter for an agent, even if mechanically imposing a human work discipline may not. I like that framing: communicate the outcomes and standards we care about, then consider how the agent can achieve them.

My T3 Code AGENTS.md begins with what the product is and how its server wraps provider CLIs for web, desktop and mobile clients. I want an agent to understand the product, not merely the file it is editing, so its suggestions fit the direction of the project.

The document also names principles: keep the project open, protect performance, support remote use and account for all surfaces. I have seen reminders about performance reduce regressions, while CI catches others. That is my experience with this project.

Remote readiness matters because a change can work in a local desktop test but fail over the web or on a phone. Naming all the surfaces gives contributors and agents a reason to check the behavior beyond the environment immediately in front of them.

I include a personal note, a shared glossary and warnings about actions that can interrupt the server being used for development. The glossary helps people and agents use the same words, while concrete cautions address failures I actually encountered.

Other sections cover development servers, representative test data, verification, PRs and code location. A taste section records preferences about where complexity belongs, avoiding unnecessary types and keeping comments tied to the code they describe.

The goal is for the agent to understand your intentions well enough to suggest related work or push back when appropriate. In my workflow, carefully written project context has helped more than the automatic memories I inspected.

Every new thread begins without the prior conversation, so durable context needs to be available somehow. My recommendation is to put the important goals and current project facts where they can be maintained, rather than assume automatically saved notes will stay useful. Experiment and see what works for your team.