Audit and rebuild a memory system in a personal repo against failing tests

Shawn Knight had Claude Code audit the memory layer of his A.I.N.D.Y. project, turn the gaps into 8 failing tests, then rebuild it in three phases until 384 tests passed.

Done withClaude CodeClaude· Nov 5, 2026

What they did

Shawn Knight was working on A.I.N.D.Y., his own execution runtime, and wanted to know whether its Memory Bridge component actually did what he believed it did. He first used Claude in chat to plan audit prompts, carried them to Claude Code, and brought the findings back by hand. Claude Code searched the repository, compared several half-finished memory implementations against each other, checked which one was really wired in, and ran the tests. Before changing anything it recorded a baseline, then wrote tests for the behaviours the audit found missing. The rebuild ran in three phases (make it real, make it intelligent, make it useful), with the agent told to read named files first, keep stated architectural constraints, run tests after each phase, and stop to investigate when the code contradicted an assumption.

How it went

The baseline was 135 passing tests plus 8 that failed on purpose, one for each missing behaviour. Over the three phases the suite grew to 338, then 362, then 384 passing with none failing. Knight says the audit also changed his own idea of the component: it was meant to orchestrate recall and feedback, not just store data. Over time he stopped relaying work through the chat and did the planning inside Claude Code, because it could look at the real files. He admits agents still got things wrong and later agents caught misses by earlier ones.

Worth knowing

The test counts are the author's own report and he says plainly they do not prove the system is correct. The useful trick is writing the missing behaviour as deliberately failing tests before the rebuild, so progress is measured by the repo and not by the agent's own summary. The post is part of a series and the source code is linked from it.

Try it

With Claude Code· 5 parts to fill in

Audit [component name] in this repository before changing anything. Read [list of files or folders] first. Find every implementation related to [what the component should do], tell me which one is actually used, and where the pieces fail to connect. Run the existing tests and record the baseline. Then write one failing test for each behaviour that should exist but does not, and show me the list. Once I approve it, implement in phases of [number] steps, run the full suite after each phase, and keep [architectural constraint]. If the code contradicts something I told you, stop and explain instead of following my instruction. Stop when every new test passes and the docs match the change.

Square brackets are the parts to fill in. The prompt is ours; the story is theirs.

Where they said it

Related