I had been building indxr as a “fast codebase indexer for AI agents.” Tree-sitter parsing, 27 languages, structural diffs, token budgets, the whole deal. And it worked. Agents could understand what was in your codebase faster. But they still couldn’t remember why things were the way they were. Karpathy’s tweet about LLM knowledge bases prompted me to take indxr in a different direction. One of the main issues I faced, like many of you, while working with agents was them making the same mistake over and over again, because of not having persistent memory across sessions. Every new conversation starts from zero. The agent reads the code, builds up understanding, maybe fails a few times, eventually figures it out and then all of that knowledge evaporates. indxr is now a codebase knowledge wiki backed by a structural index. The structural index is still there — it’s the foundation. Tree-sitter parses your code, extracts declarations, relationships, and complexity metrics. But the index now serves a bigger purpose: it’s the scaffolding that agents use to build and maintain a persistent knowledge wiki about your codebase. When an agent connects to the indxr MCP server, it has access to wiki_generate . The tool doesn’t write the wiki itself, it returns the codebase’s structural context, and the agent decides which pages to create. Architecture overviews, module responsibilities, and design decisions. The agent plans the wiki, then calls wiki_contribute for each page. indxr provides the structural intelligence; the agent does the thinking and writing. But generating docs isn’t new. The interesting part is what happens next. I added a tool called wiki_record_failure . When an agent tries to fix a bug and fails, it records the attempt: Symptom — what it observed Attempted fix — what it tried Diagnosis — why it didn’t work Actual fix — what eventually worked These failure patterns get stored in the wiki, linked to the relevant module pages. The next agent that touches that code calls wiki_search first and finds: “someone already tried X and it didn’t work because of Y.” This is the loop: Search — agent queries the wiki before diving into the source. Learn — after synthesising insights from multiple pages, wiki_compound persists the knowledge back Fail — when a fix doesn’t work, wiki_record_failure captures the why. Avoid — future agents see those failures and skip the dead ends Every session makes the wiki smarter. Failed attempts become documented knowledge. Synthesised insights get compounded back. The wiki grows from agent interactions, not just from code changes. The wiki doesn’t go stale. Run indxr serve --watch --wiki-auto-update and when source files change, indxr uses its structural diff engine to identify exactly which wiki pages are affected — then surgically updates only those pages. Check out the project here: https://github.com/bahdotsh/indxr Would love to hear your feedback! submitted by /u/New-Blacksmith8524
Originally posted by u/New-Blacksmith8524 on r/ClaudeCode
You must log in or # to comment.