I Did a Thing
Building a personal wiki with AI to solve the knowledge leak problem during GBS recovery.
I’m recovering from GBS (Guillain-Barré Syndrome). If you’ve read my about page you’ll already know that. I’m not going to dwell on it here because this isn’t that post, but the context matters for what follows.
GBS is neurological. The fatigue it produces isn’t the kind you sleep off. It’s a budget constraint, and the budget varies. Some days it’s generous. Some days you’re rationing everything.
What that means in practice, for engineering work, is this: when I was running low, I didn’t go deep. I reached for what was fast. On a bad day, fast meant putting things on the backlog that shouldn’t have been there, cutting corners I’d have to revisit, leaving comments in code as placeholders for thinking I’d deferred. It meant going down rabbit holes for thirty minutes on problems that a single documented note from a previous session would have closed in two.
I remember one stretch where I was setting up authentication for an internal tool. Nothing exotic. A configuration I’d done variations of before. Should have been thirty minutes. It wasn’t, because the notes didn’t exist. The steps I’d figured out previously lived nowhere. So I figured them out again, slower, and got it done, and documented nothing, because I was already behind.
That’s the failure mode. Not drama. Just slow, expensive drift.
It’s not just a recovery problem. It’s just that recovery made it impossible to ignore.
The Knowledge Leak
Every engineer has a version of this story. You spend two hours tracking down why a particular command keeps getting blocked, you find the fix, you ship. Three months later, in a different project, it happens again. You half-remember solving it. You can’t find where or how. So you solve it again.
Scale that across distributed teams. People spread across geographies and timezones, working in parallel on overlapping problems, with no connective tissue between what they’re learning. The leak becomes a flood. You’re not just losing your own past solutions. You’re losing everyone’s.
Institutional memory is the thing nobody builds until they’ve felt the cost of not having it. By then it’s expensive.
I needed a better system. I found the seed of one from someone else’s idea.
Karpathy’s Pattern
Around this time I’d been thinking about consolidating knowledge across different parts of my life into something like a personal database. Not just engineering. The whole thing. Projects, decisions, reference material. But every time I tried to design it, the architecture got heavier. A database felt like towing a box trailer with a Mac truck. Too much structure for what I actually needed.
Then in April 2026, Andrej Karpathy published a short gist. I read it and recognized the shape of what I’d been circling.
His premise: instead of using LLMs for standard retrieval, where the model re-derives everything from scratch on every query, let the LLM build something persistent. A wiki it maintains incrementally as you work. Markdown files. Simple structure. No heavy infrastructure.
It works for a simple reason. Humans abandon wikis because the maintenance burden grows faster than the value. Updating cross-references, keeping summaries current, flagging contradictions, maintaining links across pages. It’s relentless bookkeeping and nobody wants to do it.
LLMs don’t get bored. They don’t forget to update the index. They can touch fifteen files in one pass and keep everything consistent. The wiki stays maintained because the cost of maintenance drops close to zero.
His structure has three layers: raw sources, the wiki itself, and a schema that tells the LLM how to operate. Add a new source and the LLM reads it, extracts what matters, integrates it into existing pages, and flags where things conflict. That was the starting point. I built from there.
The Guardian
Karpathy’s pattern left something open. LLMs can hallucinate, drift, and write things that feel correct but aren’t. Give one enough latitude over time and it’ll eventually write a pattern that’s wrong, a version number that’s stale, or a claim that contradicts something established months ago.
A wiki nobody trusts is worse than no wiki. It creates false confidence.
So I built a verification layer into the wiki skill itself. The rule is simple: verify before write, not after. Before anything enters the wiki, it checks for valid frontmatter, correct page type, tags from the defined taxonomy. It checks that claims cite sources rather than asserting bare facts. It checks that each page links to at least two others. It checks for contradictions with existing content.
Each check produces one of three outcomes: pass and write, fail and fix, or write with contradiction flags in the frontmatter so you know to come back. Human stays in control. Agent does the work. Nothing slips through without a record.
The Pathogen-Antibody Pattern
When I was archiving one of my older projects, a security tooling project, I started noticing that the most valuable things to preserve weren’t the code patterns. They were the failures. Specifically, the failure and the fix.
I started calling them pathogens and antibodies.
A pathogen is a problem you encountered. Specific enough to be recognizable again. An antibody is the resolution, not a general principle but the actual thing that fixed it.
Here’s a real example from the wiki: security block on a schemeless URL in a terminal curl command. The antibody: always prefix web URLs with explicit https:// in commands. Two lines. Sounds trivial. When you’re moving fast, fatigued, or you’re an engineer onboarding to a project, that entry saves you thirty minutes of confused debugging.
Because it’s documented, it’s findable. An agent can recognize a similar failure in an active session and surface the antibody before you’ve realized you’ve seen this before. Past pain becomes present reference.
For distributed teams, this matters more than it might seem. The engineer who hit the pathogen and the engineer who’ll hit it next may never overlap in time or location. The wiki bridges that gap.
From Personal to Distributed
When I first built this, it was personal. A way to compensate for what recovery was taking, not cognitive capacity exactly, but the energy required to dig. If knowledge was already organized and surfaceable, I didn’t have to dig. I could stay efficient and still be effective. The system did the excavation.
What I didn’t expect was how quickly it scaled beyond that.
Applying the same structure to team projects changed the picture fast. Across sessions, across engineers, across the geographic spread of teams I manage, the return started compounding. Not just my solved problems but everyone’s. Patterns from one project showing up as references in another. An engineer in one timezone leaving an antibody that saves an engineer in another timezone hours of work they’ll never know they didn’t have to do.
The more you put in, the more it pays back. That’s not a promise. It’s just how the structure works.
Why OpenCode
Worth being direct about something: this is built specifically for OpenCode (open-code.ai), the CLI most of the engineers I work with use for scaffolding and QA. That specificity matters.
OpenCode has a native skill system. Custom skill files are auto-discovered from a global config directory. Drop a SKILL.md in the right place and every session picks it up automatically. Pair that with an AGENTS.md at the project root and the wiki is present in every session without anyone having to invoke it.
Auto-triggers are what make it sustainable. At natural moments the agent asks: after a feature ships, when a new tool gets used, before a session ends. You say yes or no. The agent prepares the content, runs verification, writes to the wiki, updates the index and log.
Nobody has to remember to maintain it. That’s the design. Memory is what we’re trying to offload.
What This Is
Let me be clear about what this isn’t. It’s not AI writing code for you. That’s a different category of tool and a different conversation.
What it is: AI handling the overhead that drains you, so you can focus on the work that actually requires you. The maintenance, the bookkeeping, the context-keeping across long projects with many moving parts. Those things are expensive, whether you’re managing energy carefully during recovery or just running engineering across distributed teams at scale.
Apply that principle and the wiki is just one example. Documentation, onboarding, QA patterns, deployment runbooks. Anywhere the cost is maintenance and the value is access, the tradeoff is worth examining.
I built this because I needed it. What started as a workaround during a hard stretch became the backbone of how I manage knowledge across projects, teams, and locations. It’s live, it’s growing, and every project feeds it.
Credit for the core idea goes to Karpathy. His pattern was the starting point. The guardian, the pathogen-antibody structure, and the OpenCode implementation are what I added on top.
If you’re using OpenCode and you’ve ever solved the same problem twice, the skill and the schema are where to start. I’ll write up the implementation in a follow-on post.
There’s more to write about the GBS side of this. The recovery, the return to work, what two years of that actually looks like. That’s coming. For now, this is the engineering story that grew out of it.
Inspired by Karpathy’s LLM-wiki pattern.