My Planning AI and Coding AI Were Working in Silos — So I Started Connecting Their Context
Second Brain Series — EP3: Integration
I plan in Claude Chat, develop in Claude Code, and automate with Hermes. Each one is good at different things, so I keep switching between them — and every time I switch, I have to re-explain everything. “What this project is about,” “what decisions have been made so far,” “where I got stuck” — I have to lay it all out from scratch every single time.
At some point I realized this was eating up more of my energy than anything else. I gave it a name so I could manage it: the “re-explanation tax.” An LLM meets you for the first time in every new session, and that was the source of all the chaos.
Why Merging the Tools Isn’t the Answer
My first instinct was simple: “Why not just use an all-in-one tool that handles chat, coding, and automation?” But I tried it, and it was a trap. Chat is good at being chat. A code editor is good at being a code editor. Forcing them together just gives you two knockoffs, each one notch worse than the original.
What needed to be unified wasn’t the tools — it was the context flowing between them. I wrote up why you shouldn’t merge the tools, and why you need a context spine instead.
Unifying Just the Knowledge Unclogged Everything
I started ingesting CLI sessions into my second brain. The direct expectation was “I’ll be able to look this up later” — but there was an unexpected effect. The next session started not with “explain from scratch” but with “where did we leave off?”
I actually used these exact words at one point:
“I plan in chat, design in design tools, code in code tools, and all that context is completely siloed — but I can’t stop using them because that’s where each thing works best — and then I discovered the LLM wiki and just having the knowledge unified somehow unclogged everything”
That was exactly it. The tools hadn’t changed at all, but adding one thing to thread between them meant the context stopped getting lost. The re-explanation tax disappeared.
The Spine Concept: Don’t Replace the Tools — Thread Between Them
What if I extended this across the entire development flow? Planning (what and why) → Implementation (how) → Deployment (shipping) — each stage handled by the tool that does it best, with a spine in between that does nothing but carry context.
The second brain already proved this on a small scale through knowledge integration. I’m working on a bigger version of the same idea applied to the entire build chain. I’ve been calling it Atlas — the name works on multiple levels: a giant holding up weight, an atlas as in an index or reference book. It’s also recursive. The way you build Atlas is exactly what Atlas is trying to do.
The Next Session Starts Differently
Something has already changed about how I open a session. Running Hermes and Claude Code together, when I ask “where did we get to last time?” it reads the second brain wiki and pulls the context back. I don’t have to explain anything.
Try it yourself: after your next AI conversation, ingest it somewhere. The first line of the session after that will be different.
← Prev: EP1·EP2 Build · Next →: EP4 Discord Deep dive: Context Spine Idea · Method: Second Brain Automation · See also: Two AIs, One Workflow · EP5 In Practice · EP6 The App