PowerUp Coaching — Living Knowledge Base

Insight: Spec-Driven Parallel Work-Tree Development — Become the Spec Writer, Not the Coder

5 min read

“I’m trying as much as possible to be the guy that writes the spec. And then has the AI go through the entire thing — think about it, plan it, code it, execute it, test it — and if it doesn’t work, try it again. Until it does, and when it does, issue a PR against the Git.” — Lou

Session context: 2026-05-07_Mastermind — Lou described the development methodology he’s been testing this week as he rebuilds his ambient AI architecture from spec-first principles.

Core Idea

The most effective human role in AI-assisted development is not coding. It is not reviewing code. It is writing specifications.

The spec-driven, parallel work-tree model turns this into a concrete workflow. You write the architecture: what the system should do, what it should not do, what it should look like, what functionality it should expose. Then Claude runs the full implementation cycle — planning, coding, testing, retrying — inside a Git work tree isolated from your main codebase. If the work tree succeeds, you issue a PR and merge. If it fails completely, you delete the work tree. Nothing in your production code was ever touched.

Why work trees matter. The biggest psychological and practical barrier to aggressive AI-assisted development is fear of breakage. If Claude can write directly to your main branch and mess it up, you’ve created real risk. Work trees solve this: they are isolated, sandboxed, expendable. Each work tree is a full copy of your repository state at a point in time, with its own branch, and changes made to it cannot affect your main code until you explicitly accept them via PR. This makes the mental model of “let Claude try everything” psychologically safe.

The parallel dimension. Because work trees are isolated, you can run multiple of them simultaneously. Lou described running 4, 5, 6, 8, or 10 work trees at the same time — each implementing a different feature, or a different approach to the same feature. You write the spec; Claude clones the environment, runs the implementation, and reports back. You review the results and choose which implementation to merge. This is product management at a technical level: you are setting direction and evaluating outputs, not executing them.

The model allocation. Lou’s approach: use Opus 4.7 for the brainstorming and architecture deliberation — the spec-writing phase, where reasoning depth matters most. Then use Sonnet for implementation and testing — faster and more token-efficient for the execution phase where the thinking is already done. The expensive model handles the high-leverage thinking; the efficient model handles the high-volume execution.

What this turns us into. The work-tree workflow produces a role transition: from someone who writes code or reviews code, to someone who writes specifications, evaluates results, and makes architectural decisions. “We’re kind of turning into app developers and product managers, which is a good thing, and we don’t have to turn into coders.” For knowledge entrepreneurs building personal tools, this is the right level: define what you need, evaluate what you get, improve the spec when the output misses.

The blind spot. Spec quality determines everything. A vague spec produces vague implementations, and “try again” loops with a bad spec don’t converge — they drift. The investment isn’t in the code; it’s in learning to write precise, testable specifications. This is a skill that takes deliberate practice and looks nothing like the learning most people do when they “learn to code.”

Practical Application

The work-tree development habit (for Claude Code users)

  1. Write the spec first. Before typing a single line of code or making a single Claude Code request, write a short document: what this should do, what it should not do, what done looks like (observable test). Even 5 sentences is better than improvising.

  2. Ask Claude to plan before it builds. “Read this spec. Tell me your implementation plan — the components, the file structure, the key dependencies — before you write any code. I want to review the plan.”

  3. Create a work tree for implementation. In Claude Code: “Create a new work tree for this feature.” If Claude Code supports it natively, use it. If not, git worktree add ../feature-name feature-branch from the terminal.

  4. Let it run. The instructions to Claude: “Implement the spec in this work tree. Run the tests. If the first implementation fails, try a different approach. When it passes, issue a PR.”

  5. Review and merge or discard. Review the diff. Merge if good; git worktree remove if not. Zero risk to your main codebase either way.

Coaching Question:

“What’s the last piece of software or automation you built where you felt like you were in the weeds? If you’d written a precise spec first and let AI implement it, what would have been different — and what does that tell you about where your time is actually best spent?”

Evolution Across Sessions

This builds on Insight - Use a PRD-First Workflow to Build Apps Without Getting Lost (Sep 11, 2025) which established the value of PRD-first development. The new development: the work-tree isolation mechanism that makes aggressive parallel experimentation psychologically and practically safe. PRD-first said “write the requirements before coding.” This adds: “run multiple implementations simultaneously and delete the ones that fail.” The risk management and parallelism dimensions are new.

Graph View

Backlinks