Why You Shouldn’t Integrate Your Tools — The Context Spine Idea
Context evaporates at every planning→development→deployment handoff. The fix wasn’t tool integration.
The Problem: There’s a Tax at Every Seam
While building myWiki, I noticed something odd. It was the day I was working on the B12 session and the Organize pipeline — and I caught myself re-explaining, from scratch in a new session, everything Claude and I had agreed on in the previous one.
“We decided on this last time” just doesn’t work. The model has no memory, and I have to fully reassemble the context from that decision and hand it over again. This wasn’t a one-off. Things settled in a planning chat would be gone by the time I opened the IDE, and at the deployment stage I’d have to explain all over again why we structured things this way.
I started calling this the handoff tax. Every time you cross a boundary between tools, you pay a re-explanation cost.
Diagnosis: The Seams Are the Problem, Not the Tools
The first instinct is “okay, let’s integrate the tools.” Planning, coding, deployment — all in one place. But that’s the wrong approach.
Figma is Figma, the IDE is the IDE — each one is best-in-class for a reason. Merging them into one means giving up the depth each brings. And honestly, building something that replaces all of them on my own isn’t feasible.
The problem wasn’t the tools. It was the seams between them. Between the planning chat and the coding session. Between the coding session and deployment. That’s where context was leaking out.
So instead of replacing the tools, what if you just thread the context that evaporates at the seams?
The Approach: Atlas — Build Only the Spine
That’s where the Atlas idea starts. The structure is simple:
- app-creator: planning, requirements, design — “what and why we’re building”
- app-builder: implementation, running the build-plan — “how we’re building it”
- app-publisher: deployment — “how we ship it”
- Atlas: the context spine that threads all three together
Atlas doesn’t do the actual work. Its job is to carry what decisions were made at each stage, why those decisions were made, and what the next stage needs to know. Like how a spine doesn’t move your limbs — it holds them together.
The name comes from that too. Atlas — the titan holding up the sky, and at the same time, an atlas (an index, a map). A load-bearing spine and an index of knowledge.
Why It Works: The Logic of Escalation
The key in this structure is deciding what gets escalated to the human and what the AI handles on its own. Especially if you’re thinking about non-developers using this, that distinction matters even more.
Something I learned from actually working with Claude Code: the criterion for escalation shouldn’t be “importance” — it should be “decisions the user owns.”
Even if something is technically complex, if the AI knows it well, the AI can decide. But things like “the cost doubles” or “going this direction makes it hard to change later” — those aren’t technical judgments. They depend on the user’s intent and priorities. Those need to go up.
And when you escalate, you can’t surface it as “MikroORM v6 vs v7 API contract drift.” You have to translate it: “Do you want to go slow and cheap, or fast and expensive?” Escalate in the language of outcomes.
There’s a real example too. I was running auto mode and during a MikroORM version upgrade, a contract drift got escalated. Auto mode means “doesn’t show you the plan,” not “never asks.” Decisions the user owns will punch through the mode — I confirmed that firsthand.
The Recursion: Building the Spine with the Spine
The part of this idea I find most interesting is the recursive structure.
Atlas is the spine that lets a solo developer build something big — “human sets direction, AI handles execution.” But the way you build Atlas is exactly that. I build it alone using build-plan, making only the escalation decisions myself.
Building the spine with the spine. The process of making it becomes a live demo of the product.
I already have two pieces in place. myWiki is running as the knowledge spine, and build-plan is running as the builder. Next is picking the single most painful seam to fix.
Something You Can Try Right Now
On your next project, try measuring how much “re-explanation tax” sits between planning and coding. How long does it take to explain “why did we make this decision”? How many messages does it take to recover the context from a previous session? That’s exactly the problem Atlas is aimed at.
You don’t need to change your tools. You just need to thread the seams.
Background: I connected the context because planning AI and dev AI working in silos was frustrating · My second brain design decisions Method: Cutting development time with the build-plan skill Deep dive: When your agent won’t listen — the 4-lever method See also: Why myWiki was born
변경 요약: 본문에 비개발자-자연어-개발-가이드·claude-code-4레버-방법론 인라인 링크 2개 추가, 하단 관련 글을 배경/방법/심화/함께 보기 레이블로 정비