Watch someone debug with a coding agent for an hour and you see the same shape every time. Twenty exchanges of wrong hypotheses, logs pasted back and forth, three fixes that fix nothing, and then the actual answer, which is usually embarrassingly small. A missing await. A header the proxy strips. An environment variable that only exists locally. The whole afternoon compresses into three lines of diff.
Then the conversation ends, and those three lines go into the codebase while everything that made them findable stays in the chat log. Two months later a different project hits the same class of bug, a fresh agent session opens with no idea any of this happened, and you pay for the whole search again.
Generation is cheap, diagnosis is not
The reason fixes matter more than components comes down to an asymmetry. If you lose a component, a fresh agent regenerates a decent one from a short description, because generation has a wide target: many implementations are acceptable and the model knows the neighborhood. Diagnosis has a narrow target. The value was never the three lines. The value was eliminating everything else, and that elimination work does not transfer when only the diff survives.
This is why re-encountering a bug you already solved feels so bad. You are not annoyed at writing the fix twice. You are annoyed at paying for the search twice: the same wrong turns, the same token spend, the same context window filling up with dead ends.
The anatomy of a fix worth saving
A diff alone is almost useless to a future agent, because the future agent will never find it. What makes a fix an asset instead of a leftover is everything around it:
The symptom, written the way you would search for it. Not "fixed auth bug" but the error message, the observable behavior, the words someone would actually type when it happens again. Retrieval fails when the label describes the solution instead of the problem.
The root cause in one sentence. Not the story of the afternoon, just what was actually wrong.
The failed approaches. This is the part nobody saves and the part that saves the most. Negative knowledge is what lets the next session skip the first five wrong hypotheses instead of re-walking them.
The environment. Library versions, runtime, the specific combination that made this bug possible, because half of these fixes are only true for a particular stack state.
Save that, and a fix stops being a scar and starts being a building block.
Chat logs are where fixes go to die
The default storage for all of this right now is the conversation history, and conversation history fails in a specific way: it is write-only. The knowledge goes in and never comes back out, because there is no path from "this error looks familiar" to the right thread from six weeks ago. You cannot grep for a vibe.
So the habit that matters is deliberate capture at the moment the fix lands, while the root cause and the wrong turns are still in front of you. Save the fix once, with its symptom and its negative knowledge, and retrieve it in every project after that. Bug fixes are memory too.
What this compounds into
I keep coming back to the same line: what persists between sessions is memory, and what your memory stack is should be your highest priority. Components were the obvious first asset, but fixes are where the compounding gets loud, because every saved diagnosis removes an entire class of future cost instead of just a future generation step.
A team, or even one developer, that treats fixes this way ends up with a strange advantage: their agents get better at their specific stack over time. The obscure failure modes of their infrastructure stop being rediscovery exercises. Debugging starts to look like composition: recognize the symptom, pull the asset, move on.
That is a large part of why I am building Sirro, and I wrote about the server side of it in what shipping a hosted MCP server taught me about agent memory. The short version: the agents are interchangeable, and what they keep is not. Save the fix. Your future self, in a fresh session with a familiar-looking error, will thank you.
Top comments (0)