How my AI wiki actually got built (wrong turns included)

TL;DR: I built a personal wiki that my AI reads and writes as its memory – and I’m not a coder, which is the fact that explains everything else here. Every problem arrived unannounced. Concurrent sessions ate a day of work. An “action inbox” ballooned into a moving box I never unpack. Stale decisions kept resurrecting themselves. A safety filter eventually refused to work near topics I write about professionally. Ten and a half weeks, every wall fixed with a mechanical rule – and it’s the most exciting thing I’ve ever built. Here’s my honest chronology, and what you should know if you want to do the same.

Start with the important fact: I’m not a coder

My complete programming history: in 1993, I could type WIN at the MS-DOS prompt. Since then I’ve pasted very specific instructions into a terminal maybe a handful of times, cautiously, when something was broken, understanding none of it. That’s the whole résumé. Claude Code – a tool with “code” in the name – sounded like it was for other people, and that’s part of why I circled it for so long before starting.

I’m leading with this because it explains the shape of everything that follows. A developer building a system like this would anticipate half the problems before they happened – file conflicts, stale references, folder sprawl. I couldn’t. I didn’t know the terms, didn’t know what was happening in the background, didn’t know what could go wrong. So every problem in this post was experienced first and understood afterward. The fixes, it turned out, were always easy. Anticipating them was the expertise I didn’t have – and, as it turns out, didn’t need in advance.

Day one: empty folders and a pretty graph

The start was someone else’s idea, and I want to be exact about whose: Andrej Karpathy’s – give your AI a folder of plain markdown files as its memory and let it read and write them itself. I saw somebody show off their version – the graph view where your notes appear as glowing connected dots, the cool things it could do – and I wanted it. So I found a YouTube walkthrough with exact instructions and picked the version that looked safest: Karpathy’s original idea, with as little third-party code as possible from people I didn’t know. I understood almost nothing about what the setup was doing, so “this can’t make my computer do things I don’t expect” was my entire selection rubric. (What learning AI looked like before this point is its own story.)

And here’s the confession that matters: I had no idea what I was building it for. None. I wanted the pretty graph with my information in it. That was the whole plan.

Once it was built, it was a blank slate, so I started feeding it: the TikTok videos from a hobby project, the free course I offer alongside them, the transcripts from all of it. What does it look like when you connect all those dots? I looked at the picture for a while and thought: okay, that’s cool. Now what?

The answer didn’t come from using it. It came a few days later at a hockey game, where my brain does its background processing whether I ask it to or not: this thing could solve one of my clients’ problems. Build a wiki holding the scientific papers on the topic they care about, and use it to spot the gaps and develop a content plan. So the second wiki I built wasn’t mine – it was theirs, papers only. And playing with that one is what finally taught me what my own was for. I came back and started really filling it: developing ideas, developing plans, outlining new content, auditing content I’d already made.

The day it looked broken

Then came the morning the wiki appeared to have amnesia. Work from the previous session – real decisions, real progress – was just gone, as if the day had never happened. I assumed the whole thing was broken and started mentally budgeting for a rebuild: re-ingest everything, start over.

What had actually happened: I’d gotten ambitious. I was stacking sessions – running more than one at a time – and multiple sessions had written to the same shared files. The syncing layer has no referee, so the later save simply erased the earlier one, and information was gone. (The day-of experience – staring at a wiki that looked corrupted and wasn’t – I’ve told in How I built an AI that actually knows my work.) No rebuild was needed; the AI repaired the connections, and we made a rule.

But here’s the part worth watching, because it’s the whole learning curve in miniature. First the rule was simply don’t run two sessions at once – and that worked, and I hated it, because parallel sessions were exactly how I got more done. So I ran parallel sessions on unrelated things, in separate wikis, which was safe because they never touched the same files. Then I wanted parallel sessions in the same wiki, and for a while I coordinated them by hand – telling one session “I have another one open, don’t write to those files yet” – which worked, and made me the referee, which is a job I did not want. The final fix: each session writes its own timestamped staging note instead of touching the shared files, and a merge step reconciles them later.

Small, boring – and probably obvious to any coder, who would have built it on day one. I’m not one. The fix was easy; I just couldn’t have anticipated the problem. I now think that’s fine. Waiting to solve problems until they’re real also means you never build machinery for problems you’ll never have. And notice the shape of every fix that stuck: a mechanism, never a resolution to be more careful. Careful doesn’t survive a busy Tuesday. Rules do.

The moving box, and the zombie decisions

Two confessions about what an LLM-managed wiki can do when it works.

First: it can help you generate ideas faster than you can act on them. Having everything connected meant ideas arrived constantly – do this, don’t forget that, here’s a thing you could build. So we made an “action inbox” to catch them all. It ballooned into hundreds of items. Some got done, many got superseded by better-organized threads, a batch got deduplicated away – and the rest sit there like that box from when you moved house. If you haven’t opened it in a couple of years, you probably don’t need what’s inside. I still haven’t fully unpacked mine. I’m telling you this so you don’t mistake the tidy system in my other posts for the whole truth.

Second: information goes stale, and stale information doesn’t die – it comes back when you least expect it. The wiki will cheerfully believe you’re connected to a design tool you tried once and abandoned (I speak from experience; that ghost got exorcised today). Or you brainstorm a name, half-decide it, and it gets written into five different files – and when you decide against it later, it has to be un-written in all five, or months from now a draft will confidently use the dead name. So maintenance is real: link checks, contradiction sweeps, retiring out-decided facts. The AI does the mechanical part – finds the broken links, spots the conflicts – but you still have to give the answers at the end. Nobody else knows which decision is the live one.

And the numbers, honestly, because I doubted them myself: when I finally audited the original vault, it held about six thousand files I could actually see – nearly four thousand of them notes – plus some twenty thousand invisible ones that version control and the app keep for themselves. I’d been quoted “twenty thousand files” and didn’t believe it; the truth is the machine’s basement was three times bigger than my house. The visible six thousand were still enough that the folder structure had stopped making sense, and the reorganization that followed had one deciding principle worth stealing: a folder earns its place if it still works when you copy it out – “could we split this?” is theory, “does it survive alone?” is the test.

The wall I could not have seen coming

Some of the topics I write about professionally live near subject matter that AI safety filters are twitchy about. Fair enough – except the filter doesn’t only react when you’re working on those topics. Enough of that vocabulary in your notes and logs, and an advanced model can start stumbling over the vault itself, even in sessions that have nothing to do with the sensitive material. And if a company tightens a model’s filters from one day to the next, that’s entirely out of your control – and suddenly you can’t do anything with your own content. You can’t even run a final proof of the document you thought you were about to ship to a client.

What finally made me act was the limited re-release of Claude’s most advanced model, Fable. There were things I wanted its help with inside my system – and it needed to be able to read the system to help. The fix did not come to me at the computer. It never does; it usually comes while I’m weeding the garden: I could move those files somewhere safe and let the advanced models keep working without ever looking at them. And in a loop I still find funny, Fable itself helped design the strategy – told me exactly what to do and how to build it, using the models that are allowed to read everything.

So we split it – copied (never moved) a verified-clean core into a fresh vault that any model can work in, kept the original as a frozen archive, and put a mechanical gate between them: nothing crosses into the clean vault without passing an automated scan against a maintained term list. Not “an agent promises to be careful.” A scan. The split is recent; I’m still optimizing it; and if the situation ever changes, everything is reversible – but for the topics I work in, this is going to be a recurring theme, and a clean wiki that every model will actually work in is worth the surgery.

What it costs, and what it buys

I won’t pretend: this is real work. The maintenance, the merges, the stale-fact hunts – it takes time. Here’s why I keep paying it. The alternative isn’t zero work; it’s a shit-ton of unconnected files on a computer, organized by administrative willpower, searchable only by filename, holding pieces of information that are related in ways no folder structure can express. The wiki’s entire value is that the connections are real: the AI can pull scattered fragments together and do something with them, and when the structure needs to change, it re-wires thousands of links in an afternoon. You maintain it because you can use it. Files you can’t use don’t need maintenance – they just need a eulogy.

Karpathy’s gift was the vagueness

The idea I copied was deliberately underspecified – a shape, not a spec, meant to be bent around whoever uses it. At the start I found that frustrating, because I didn’t know enough to know what I needed. Now I think it’s the whole point. I couldn’t have designed this system up front, and neither will you; I learned it in place, by doing, one experienced-then-understood problem at a time.

Which is also why I’d be careful with anyone selling you a ready-made version of this – “just download my system.” They’re selling you short. Their system is somebody else’s vagueness: it may not apply to you, and it certainly isn’t optimized for you. If you’re going to bend it around your own work anyway – and you will – why not start with your own? Spend the few minutes of upfront thinking first. What am I actually going to do with this? What kinds of things will I put in it? How will I want to get at them later? And the question I’d weight heaviest: when I know there’s a file in there and the AI isn’t around, how does my brain logically organize information to go and find it? Answer those, and the system you start with is already a step toward the one that actually helps you.

So take everything above as inspiration, not blueprint – the walls you hit will be yours, and if my pattern holds, each one will turn out to have a small, boring, mechanical fix. And maybe there’s a better way I still don’t know yet. If you find it, I genuinely want to hear about it.

If you want the day-one version of this instead of the ten-week version: the starter is one paste – the wiki kickstarter sets up the seedling (a first file, a map, a drop zone, a log) and teaches your AI to do the filing. Mine started with Karpathy’s idea, a YouTube video, and an afternoon. If I can do it, you can do it.