Run the Old System Until the New One Works

I missed one Tuesday and nearly missed a second. The last issue went out September 15. The gap after it was not laziness. It was a migration.

The Insight

For a long time, Obsidian was everything. File system, writing area, memory. I was building a second brain, and I kept feeding it.

A second brain is a trap for me. The time goes into building and maintaining it instead of applying it. Tie it to one app and it gets worse, because a working system is never one tool. It is a collection of systems that use different tools.

The research on this is narrow but pointed. Whittaker et al. (2011) followed 345 email users through more than 85,000 refinding actions. People who built complex folder structures did rely on them, but the effort did not improve retrieval success. Search did better. That study is about email, not notes. It still describes the trap I fell into: preparing more than finding.

PARA never fit either. I understand why it exists. I find the idea interesting. I tried hard to make it work, and for a while I decided the problem was me. It wasn’t. It just doesn’t work the way I work.

Then AI changed the job. I delegate to agents now, and to teams of them. Media production is turning generative. Folder structures built for one person filing notes stop making sense when delegated hands do the work.

More scaffolding is not automatically the answer. Gloaguen et al. (2026) put it to the test with coding agents, in a preprint. Context files did not generally improve task success, and they pushed cost up by over 20%. Specific instructions were followed. General repository overviews did not help. It is a study of code, not of writing, but it matches what I keep learning. Structure has to earn its place.

The Fix

So I rebuilt. The system is no longer a note-taking app. It spans multiple applications and multiple computers. Docker and Hermes put computers inside computers. That is a meta system, and it needs a map more than it needs a brain.

Obsidian still has a job in it. It becomes a Markdown viewer inside specific repos, and maybe the map. Milo’s (n.d.) ACE framework has a space called Atlas, for knowledge and how ideas relate. I like that idea. A map points at things. It doesn’t try to hold them.

The part that hurt was the migration itself. I had planned a switch: one day the old system, the next day the new one. Switches don’t always go as planned. Mine didn’t.

What works is running the legacy system while building the new one. It is double the work. Two structures, two sets of habits, two places for something to get lost. It is also the only version where production keeps going.

I didn’t do that this time. I stopped producing to rebuild. It cost one issue and nearly cost two.

I am not the first to learn this the hard way. Fowler (2024) has watched the simple version of a rewrite, build a new system that does exactly what the old one did and then swap, go “down in flames most of the time.” He writes about company software, but the warning travels. What he recommends instead is gradual replacement.

The Hard Truth

I gained real insight over those two weeks. I still shipped nothing, and I hold myself to one standard: if nothing gets produced, I wasn’t productive. Learning is not output.

Migrating is part of growth. Sometimes a system gets outgrown, and scaling up means moving. That is fine. The mistake was treating the move as a pause instead of a second job running next to the first.

Next time the old system keeps shipping until the new one has earned its place. And the question worth asking about any setup: is it being used more than it is being maintained?

---

Sources

• Folders vs. search for refinding email: 345 users, more than 85,000 refinding actions — Whittaker et al., ACM CHI 2011
• Repository context files and coding agents: no general gain in task success, over 20% higher cost (preprint) — Gloaguen et al., arXiv 2026
• The ACE framework and its Atlas space — Linking Your Thinking
• Rewrites that swap all at once vs. gradual replacement — Martin Fowler, "Strangler Fig"