Why Saying “Build Me an App” to AI Is Actually Slower
One session = one item, dependency-aware splitting is the mechanism that creates speed
Have you ever tossed a single line like “build me this app” at AI, waited around, and then hit a context wall halfway through — or watched it lose the plot entirely? You handed everything off at once to move fast, and it ended up slower.
I used to think “it’s AI, so throwing everything at it should be quicker.” Turns out that wasn’t the case. Building myWiki from B1 through B17 with the build-plan skill, I got to verify why splitting things up is actually faster at the mechanism level. I was watching that experience — developing while chatting through it live for six hours — simultaneously as a product demo and a production methodology.
The Problem: Handing It All Over Slows You Down
When you try to cram everything into one session and hit the context limit, quality degrades. The AI forgets the design from the first half and starts going in a different direction somewhere in the middle. Rework piles up.
Going in without a plan causes an even bigger problem. If a design conflict surfaces halfway through, the cost of rolling back is enormous. If you find out the domain contract was wrong after you’ve already built out the entire persistence layer, everything built on top of it starts to shake.
The build-plan Splitting Principle — “One Session = One Item = Self-Contained Unit”
What the build-plan skill does is break a goal into “units that can be executed independently in a single session.” The key here is that it’s not a simple checklist. Each item carries dependency relationships, a mode (plan/auto), and gate tags.
The structure looks like this:
- Trunk (contracts) — The foundational contracts everything else depends on. Layers like persistence, domain, and gateway — think B1~B5. If a contract goes wrong, it propagates across all the branches, so you put a human gate here.
- Branches (parallel) — Independent slices that come down once the trunk contracts are solid. Like B6~B11, these can be isolated with worktrees and run simultaneously.
- Integration → Verification — The phase where branches merge and things wrap up.
Right-size this based on goal scope. A flat list is fine for small goals; the trunk → branch structure only earns its keep for large ones.
4 Mechanisms That Cut Development Time
This is the heart of this post.
① Context doesn’t blow up
One item = one session = one context. The scope handled within a session is clear, so you don’t hit context limits. Quality holds, and rework shrinks.
② Trunk contracts get confirmed first
When I finished trunk B1~B5 on myWiki and ran the integrated main verification, two bugs surfaced (next-env.d.ts ESLint conflict, .env empty placeholder). Because I caught them before going down to the branches, six slices didn’t inherit those errors. That was the contract gate paying off in one clear moment.
③ worktree parallelism compresses wall-clock time
Branches B6~B11 get isolated with worktrees and run simultaneously. Fan them out in one workflow and wall-clock time drops compared to sequential execution. This phase has the highest automation ROI. The reason I could push ahead with B7 while B6 was still incomplete was because the isolation decision had already been made.
④ plan/auto splitting minimizes human intervention
In auto segments (branches), human intervention is zero. The agent handles routine edits on its own. People only spend time at gates — contracts, core intelligence, deployment.
This is where I had an interesting experience. Running in auto mode, when MikroORM v6 design docs clashed with the actual v7 setup, the agent didn’t just push forward on its own judgment — it escalated up to me. “auto = never asks questions” isn’t quite right. The mode axis (plan/auto) and the escalation axis operate independently. As the 4-lever methodology puts it, decisions that are important, hard to reverse, or that belong to the user punch through the mode and come up anyway.
The Real Experience — Having Slack Was the Proof
In the middle of working, I had this thought: “It’s so chill having a todo list to run off of. Without this, working on projects used to be a complete mess.”
There was a reason things used to be hectic. The dependency graph and “what was next” were all living in my head. “To do this, that has to come first — but if I touch that, this breaks…” Holding that whole state in human working memory is a recipe for going crazy.
build-plan.md takes that state out of your head and puts it on paper. It frees up your mental RAM.
And the role changed. Before, I was typing every keystroke myself. Now the agent executes and only escalations come up to me. People sit at “direction and judgment,” while AI carries “execution and verification.” The slack wasn’t slacking off — it was proof the system was running exactly as designed.
When It Doesn’t Fit — Honest Limitations
Attaching a full build-plan to a small goal means the ceremony overhead outweighs the benefits. A flat list is enough.
Wanting a “fully unmanned end-to-end” run is also a trap. If a trunk contract is 0.5% wrong and it flows through automatically, six branches and four integration steps all inherit that error. The cost of a human debugging it ends up larger than what automation saved. Contracts, core intelligence, and deployment are human gates — they’re intentional split points.
If You Want to Try It
Next time you’re handing something big to AI, don’t just say “build this” right away. Try this first:
“Break this into units that can finish in one session, and mark what depends on what.”
Even just adding dependencies and gates to the split units will be faster and less tangled than handing it over all at once. If you’re curious about the specific format, check out how to write a build-plan spec. That’s what build-plan does.
← Prev: How to Write Instructions for an AI Agent · Deep dive: Claude Code 4-Lever Method · Background: The Secret of Skills · Background: The myWiki Origin Story