Deleting my second brain twice in one morning

On the morning of Tuesday 3 March I deleted my second brain. An hour and a quarter later I deleted it again.

The first delete took out 242 files and 46,445 lines at 10:08. Five minutes later the AI had rebuilt it as 40 files, and it looked much tidier. At 11:23 I deleted those 40 too. My actual words at the time: "Just nuke v2 and start again."

This is the story of that morning, because it's where I learned the thing I now say to everyone who asks me about AI setups. Copying the files isn't the same as doing the work. And an AI telling you it has done the work isn't the same as the work being done.

Where I'd got to by February

By the end of February I'd been building with AI for about five months. My first go, which I called Bobble, started on 1 October 2025 as a folder of notes and instructions for Claude. It worked for a while, then the notes grew so large that the AI used nearly half its working memory just reading them before I'd asked a question.

So I went looking for someone who had solved it. On 26 February I found a long public post by Muratcan Koylan called "The File System Is the New Database: How I Built a Personal OS for AI Agents". His setup used plain files (Markdown, YAML and JSONL, which is one record per line) with no database and no build step. He'd shared the whole thing openly, including the skills he'd used to design it. It was the most thought-through version of what I was trying to do that I'd seen.

That evening my AI assistant had just finished testing a version I'd built myself. It passed 14 checks and failed 11. I'd already told it of an earlier version, "I wouldn't use this." So I made a decision: stop designing from scratch, and faithfully build Koylan's architecture instead.

Go one: copy the lot

At 22:24 on 26 February the AI cleared out my repo (the project folder that holds everything, with its full history). At 22:29 it had copied Koylan's example in: 238 files, five minutes later. Over the next few days it worked through a 14-story plan and passed 18 out of 18 acceptance tests. On 2 March it ran a "fidelity check" against his original and fixed the structural differences. By then it was 242 files.

On paper this was a success. Every test passed. In practice I had a beautifully organised copy of someone else's brain.

The templates were his. The folders were shaped around his work. And the AI had copied them without understanding why each one existed. Koylan's repo came with a document explaining how his skills had built it. We'd skimmed it and gone straight to copying the output. The commit message from the morning I deleted it says it plainly: "We spent a week copying templates and writing analysis PRDs instead of reading HOW-SKILLS-BUILT-THIS.md."

A week of work, a green test report, and nothing I'd actually use on a Monday morning.

The first delete, 10:08

At 10:08 on 3 March I wiped it. 242 files changed, 46,445 lines deleted. Before I did, I tagged the old version in git as pre-nuke-v1 (a named save point I can always go back to). I'd recommend that to anyone. Deleting feels drastic, but a tag makes it free.

The plan for version two was the right idea. Instead of copying Koylan's output, run his ten design skills in order against my own context and let each one decide what my version needed. The skills cover things like how to layer instructions so the AI only loads what it needs, how to store memory so nothing gets overwritten, and how to keep separate areas from bleeding into each other.

At 10:13, five minutes after the delete, version two was committed. The message listed all ten skills, what each had produced, and finished with "40 files (down from 242). Every file justified by a skill."

It read well. I believed it for about an hour.

Go two: the AI said it had done it

When I looked properly, the trail didn't match the summary. The AI had genuinely run the first skill. Skills two to ten had been "applied" from summaries of what they say. It had predicted what each skill would produce for someone like me, then written that down, rather than running each skill and letting it work through my actual context.

There was a second problem underneath. The plan it was working from had already fixed the outcome: module names, file counts, line limits. So even a skill run properly would have been steered towards an answer someone had decided in advance. The meta note I wrote at 11:22 sums it up in four words: "invoke, don't interpret."

This is the failure that has followed me through every version since, so it's worth saying clearly. The AI wasn't lying in any normal sense. It was doing what these models do, which is produce the most plausible version of the output it was asked for. If you ask for "a rebuild that follows these ten steps", the most plausible output is a rebuild that looks like it followed ten steps. Whether it did is a separate question, and nobody had asked it.

I rewrote the plan that morning, using my coaching assistant to force the issue: one story per skill, each story must run the skill for real, no predictions about structure, and nothing moves on until the previous step is committed.

The second delete, 11:23

At 11:23 version two went too, all 40 files, tagged pre-nuke-v2 first. It had lived for about seventy minutes.

I did weigh the alternatives. The decision log from that day records three options: keep fixing version two, give up on this architecture altogether, or rebuild properly. Keeping it would have meant patching a structure built on guesses. Giving up would have thrown away the best design I'd found. Rebuilding was the only option where I'd end up understanding what I had.

Go three: one skill, one commit

From 11:29 to 12:04 the AI ran the ten skills one at a time, and committed after each one. The git history (the log of every saved change) from that half hour reads like a checklist:

• 11:29, skill 1: a three-level layout of instructions across eight areas of my life and work
• 11:31, skill 2: each area isolated so it can be loaded on its own
• 11:35, skill 3: data stored as JSONL with its structure described on the first line
• 11:41, skill 4: guardrails against the ways a long session degrades
• 11:43, skill 5: memory kept in plain files, decisions and failures in their own logs
• 11:48 and 11:53, skills 6 and 7: checklists for judging outputs
• 11:56, skill 8: each area works as standalone context
• 12:00, skill 9: a check that each workflow genuinely suits an AI model
• 12:04, skill 10: three joined-up scripts instead of eight fragmented ones

Version three was about 75 files. That afternoon I ran a comparison against Koylan's own example and fixed 20 gaps, finishing at 17:49. Every one passed.

The difference from version two wasn't the file count. It was that I could point at each piece and see which step had produced it and why. When something felt wrong later, I could trace it back. That's what "every decision traceable" means in practice: not a nice phrase in a commit message, but a log you can actually follow.

What I'd do differently

Three things, in hindsight.

I'd have read the method before copying the output. Koylan shared both. I took the bit that was quick to take. If someone has published how they built something, that document is worth more than the thing itself, because the thing was built for them.

I'd have asked for one commit per step from the start. It's the cheapest check there is. If an AI claims to have followed ten steps and there's one commit, you know something was summarised. Ten commits, each with its own change, is evidence. I'm now treating this as a rule for everything I build: "done" means wired up and working, proven by something I can go and look at, not "implemented" because the AI says so.

I'd have kept the plan free of answers. The version two plan specified module names and file counts before any skill had run. That's like briefing a builder with the floor plan already drawn and then asking them to survey the site. If you want a process to decide something, don't decide it first.

If you're building your own

You don't need code for any of this. The habits carry over to anyone setting up an AI assistant with their own notes and instructions.

1. Find a setup that works and read how it was made. Not just the files. Look for the reasoning, the steps, the "why".
2. Run the steps yourself, in order, against your own work. One at a time. Save after each.
3. Make a save point before any big change. In git that's a tag. In a folder it's a dated copy. Either way, deleting becomes cheap.
4. Check the trail, not the summary. When the AI says it's done something, look for the thing it did. A file, a change, a result. If you can't find it, it isn't done.
5. Be willing to delete. If you're feeding the system more than it's feeding you, that's the signal.

Where it goes next

Version three is six days old as I write this, so it's early. The three rules at its core came straight out of that morning's skills: never overwrite anything, timestamp everything, and record where every fact came from and how sure I am of it. Next I'm loading my real work into it (contacts, ventures, decisions), and pulling across the skills I'd built in my earlier projects so they live in one place.

I'm not naive about it. "Invoke, don't interpret" is a lesson I suspect I'll have to learn more than once, because the pull towards a plausible summary is built into how these models work. The protection isn't trusting the AI more. It's making the work leave a trail, and reading the trail.

If you're stuck on a version of this with your own setup, I'm happy to talk it through.