Storing what the AI got wrong in a learnings database

Once your AI coding assistant has a searchable memory, the question becomes what to put in it. My answer is the opposite of careful curation: store everything from your sessions and let the system filter it. But of all the notes that go in, the ones that pay off most are the mistakes, the things the AI got wrong, the wrong assumptions it made, and the corrections you had to give it. Capture all of it, and the next time the assistant is planning or building something related, it checks the store and avoids the mistake instead of walking into it again.

I run a local knowledge base behind my assistant (I use Claude Code; the full setup is in how to give your assistant a searchable memory). After a few weeks of using it, the clearest pattern was this: the notes that paid off most were the ones that recorded a failure.

Why mistakes are the highest-value notes

Documentation tends to repeat what the model already half-knows. The model has seen a million READMEs. What it has never seen is the specific, weird truth of your project, especially the places where the obvious answer is wrong.

A few real examples from my own store:

• A diagnostic in my iOS editor that looks like a real error but is actually cross-file noise you should ignore and trust the command-line build instead.
• A UI component that freezes if you present it one way, so it has to be presented a different way.
• A platform API that needs an explicit parameter passed in, not the convenient shortcut version, or it silently misbehaves.

None of these are in any documentation the model was trained on. They are the kind of thing you only learn by hitting the wall. If that lesson is not written down, the assistant walks into the same wall next week, because nothing corrected it. The correction lived in a session that no longer exists.

What a good "learning" note looks like

A useful learning note has three parts:

1. What happened (the symptom or the wrong assumption).
2. The truth (what is actually going on).
3. What to do instead (the fix or the rule).

So a useful note is not "fixed the modal bug." It is "Presenting this kind of view full-screen freezes it. Present it modally with the over-full-screen style instead." That kind of note changes behavior next time, because it is specific and it tells the assistant what to do.

You are storing all of them, so it is worth nudging your assistant to write notes this way: short, self-contained, and phrased as a rule. Each one should make sense on its own, because search will pull it back in isolation, without the surrounding conversation.

How the saving actually works

In my setup the assistant saves notes as it works by calling a save_to_brain tool, and at the end of a session I run a single command that dumps everything I learned that session into the brain at once. The server stores each note locally and, if no tags are passed, auto-generates three to five so the note is easy to find later.

This only works because I am not careful about it, and that is by design. Before saving, the server checks for near-duplicates using plain vector similarity, done in code, with no model call. My first version used a model to judge duplicates and it made every save slow and noisy. Swapping it for simple vector math made saving instant. The rule I took from that: only use a model where you genuinely need judgment. "Are these two notes basically the same" does not need a model. (I wrote more about that trade-off in the pillar post.)

How the lessons come back

When the assistant is planning or about to build something related, it searches the store, and the matching learnings come back as a short summary with the source notes. So the mistake from three weeks ago shows up exactly when it is relevant, phrased as a rule, while the assistant is still deciding how to do the thing. It reads "do it this way, not that way" before it writes the code, instead of after it breaks.

That is the whole loop: hit a wall once, write the lesson down, and never hit it again. Over time the store becomes a record of everything that is non-obvious about your work. It is also completely original, no one else has your set of scars, which is part of why this content cannot be faked or copied.

A simple habit that keeps it fed

The store is only as good as what goes in, so the habit is to feed it without overthinking. At the end of a real working session I run one command that dumps everything I learned that session into the brain. I do not sit there deciding which notes are worth keeping. Storage is cheap, the dedup drops near-duplicates on its own, and search only ever pulls back the few notes that match what I am doing, so there is no penalty for saving too much. Curating would just be a chore that makes me skip it. Dump everything, let the system filter, and within a couple of weeks the store actually knows your project.