AI made execution cheap. That was the first shift. I stopped writing code and started designing systems that write code. Shipping got faster.
Then the second shift hit: I started too many things.
Not out of recklessness. The math changed. When a feature that used to take a week ships in a day, the natural response is to start more features, more projects, more experiments. The execution constraint disappeared, and I filled the vacuum.
Within weeks, I was managing multiple active codebases, each with its own context, its own state, its own decisions pending. The bottleneck moved from "can I build this?" to "can I keep track of all of this?"
The answer was no. Not with heroics. Not with willpower. Only with a system.
The Wall
The pattern is recognizable. AI-augmented builders hit it at roughly the same point: three to five active projects running simultaneously.
The symptoms:
Context bleed. You confuse which project has which architecture decision. State from Project A leaks into your reasoning about Project B.
Decision fatigue. Every project generates micro-decisions. At five projects, you're making 50+ small decisions per day before doing any real work.
Lost state. You step away from a project for two days. When you return, you spend 30 minutes reconstructing where you left off.
Shallow thinking. Every slot in your working memory is occupied by project management. No room for the architectural thinking that actually matters.
The core problem is structural, not personal. Human working memory holds roughly four items. Each active project occupies at least one slot, often more. At five projects, you're over capacity. No amount of discipline fixes that.
The fix is the same fix that works everywhere else in engineering: externalize state.
The System
Three layers, each solving a different part of the coordination problem.
Specs externalize project state. Worktrees prevent context contamination. Async delegation decouples attention from execution. Together, they make coordination cheap enough that creative work stays possible.
Layer 1: Specs as the Coordination Layer
The spec is the most underrated coordination tool in AI-driven development.
The spec isn't a planning document or a requirements doc. It's the project's externalized state: what's happening, what's done, what's next.
When I context-switch to a project, I don't reconstruct mental state. I read the spec. Everything is there:
Scope: what's being built, what's explicitly excluded
Acceptance criteria: testable conditions that define "done"
Current state: which items are complete, which are in progress
Decisions made: architectural choices and their rationale
Open questions: what still needs resolution
The spec serves three roles simultaneously:
For me: instant context recovery. Read the spec, know the state, make the next decision. No "where was I?" moments.
For the AI agent: complete task definition. The agent reads the spec, understands the scope, implements against the acceptance criteria. No ambiguity about what "done" means.
For continuity: session-proof state. Agent sessions end, context windows reset, memory fades. The spec survives all of it. A new session picks up exactly where the last one stopped.
State in your head
Context-switching costs 15-30 minutes per project
Decisions evaporate between sessions
Agent starts from scratch every time
Can't tell what's done vs what's in progress
Scope creeps because boundaries aren't written down
State in the spec
Context-switching costs 2 minutes: read the spec
Decisions are captured with rationale
Agent resumes from spec state
Completion is explicit: acceptance criteria pass or fail
Scope is frozen at spec creation
The Spec Lifecycle
Every project or feature follows the same lifecycle:
Active: implementation in progress, agent working against ACs
Review: all ACs pass, quality gates green, awaiting human review
Shipped: merged, deployed, archived with retro notes
Dropped: abandoned with documented reasoning, reusable pieces preserved
Specs live in a directory structure that makes status visible at a glance:
specs/
backlog/ # ideas, not yet scoped
active/ # in progress
shipped/ # completed and archived
dropped/ # abandoned with learnings
No project management tool needed. The filesystem is the kanban board. ls specs/active/ shows the current workload. If that directory has more than three files, I'm overcommitted.
Layer 2: Worktrees for Physical Isolation
The second layer solves context contamination at the filesystem level.
A git worktree checks out a branch into its own directory. Instead of one working directory with branch switching, each project or feature gets its own directory with its own state.
project/
.worktrees/
feature-auth/ # auth feature, own directory
feature-api/ # API work, own directory
article-privacy/ # content work, own directory
src/ # main branch
Why this matters for AI-driven work:
No stashing. Branch switching forces you to stash uncommitted work, switch, rebuild context, then switch back and pop the stash. With worktrees, each project is always ready. Open the directory. Start working.
Parallel agent sessions. An AI agent operates in one worktree while you review completed work in another. The agent's changes in feature-auth/ don't affect your review of feature-api/. No interference.
Physical context boundary. When you close the terminal pointing at feature-auth/, that project is gone from your working memory. No residual state. No accidental edits in the wrong context. The directory boundary is the context boundary.
Independent builds. Each worktree has its own node_modules, its own build artifacts, its own running dev server. Project A's broken build doesn't block Project B.
The mental model: worktrees turn branches into independent workspaces. Each workspace is a self-contained project with its own spec, its own agent session, its own state.
Layer 3: Async Delegation
The third layer decouples your attention from execution timelines.
Traditional development is synchronous. You write code, run it, see the result, iterate. Your attention is locked to the execution cycle.
AI-driven development enables a fundamentally different pattern:
Scope the task (write or review the spec)
Delegate to an agent (point it at the spec, start execution)
Move on to the next project
Review the output when ready—not when the agent finishes
This is async delegation. The same pattern that makes distributed teams effective, applied to human-agent collaboration.
The critical constraint: delegation quality depends on spec quality. A vague spec produces vague output. A spec with testable acceptance criteria produces reviewable output. The investment in writing a good spec pays off across every delegation.
What Makes a Task Delegatable
Not every task works with async delegation. The pattern works when:
Scope is clear. The spec defines inputs, outputs, and acceptance criteria. The agent doesn't need to ask clarifying questions.
Validation is automatic. Quality gates (lint, typecheck, build, test) run without human intervention. You review results, not intermediate steps.
The task is self-contained. It doesn't depend on decisions from another in-progress task. No circular dependencies between workstreams.
The output is reviewable. You can verify correctness by reading the diff and checking test results. You don't need to run it mentally to know if it works.
Tasks that fail these criteria need synchronous attention. That's fine. The goal isn't to delegate everything, it's to delegate enough that your synchronous attention goes to the tasks that actually need it.
Decision Batching
The three layers converge into a practice I call decision batching.
Instead of reacting to each project as it produces output, I review all projects in a single pass. The rhythm:
Design session: pick the highest-priority project, do the creative work—architecture, spec writing, problem decomposition. This gets the synchronous, undivided attention.
Delegation pass: scope tasks for the other projects, hand them to agents in their respective worktrees.
Review session: batch-review all completed work. Check diffs, verify tests pass, merge or request changes.
This converts five streams of constant interruption into three distinct activities. Design gets uninterrupted blocks. Delegation is mechanical. Review is systematic.
Reactive management
Switch context every time an agent finishes
Decisions spread across the entire day
Deep work interrupted by coordination
Mental overhead scales linearly with projects
Constantly wondering: what needs my attention?
Batched management
Review outputs in a single dedicated session
Decisions concentrated in review blocks
Deep work protected in design sessions
Mental overhead stays flat regardless of project count
Spec status shows what needs attention
The key insight: the number of projects you manage is limited by decision bandwidth, not execution bandwidth. Batching decisions makes the constraint manageable.
Protecting Creative Headroom
The entire system exists for one reason: protecting the space to think.
The real risk of managing multiple AI projects isn't burnout from work. It's losing the capacity for creative thought because every mental slot is occupied by coordination overhead.
Architecture decisions. Design intuition. Problem decomposition. The recognition that two problems are structurally the same. These are the high-value contributions a human makes. They require uninterrupted cognitive space. They can't happen in the cracks between project management tasks.
The system protects this space through three mechanisms:
Externalized state. Nothing lives in your head that can live in a spec. When you stop thinking about project state, working memory frees up for creative work.
Physical boundaries. Worktrees create real separation. You're not "kind of working on three things." You're in one directory, working on one thing. The rest doesn't exist until you open it.
Temporal boundaries. Batching creates blocks. Design blocks are sacred. Review blocks are mechanical. The two never mix.
This isn't time management. It's attention architecture.
The Operational Rhythm
A typical day with this system:
First block: design. Pick the project that needs the most creative attention. Read its spec. Think. Make architectural decisions. Update the spec with those decisions. Write acceptance criteria for the next piece of work.
Second block: delegate. Open each worktree in sequence. For projects with scoped specs, start an agent session and point it at the spec. For projects waiting on previous delegation, check if the agent finished. If yes, quick-scan the output and move to review. If still running, skip.
Third block: review. Batch-review all completed work. Read diffs. Check test results. Verify acceptance criteria. Merge what passes. Write feedback for what doesn't. Update the spec, the agent picks it up next cycle.
Between blocks: nothing. This is the point. The system doesn't need you between blocks. No notifications. No "just quickly check on Project C." The projects are in worktrees, the state is in specs, the agents are executing. You're free to think about something else entirely.
When the System Breaks
Honesty about failure modes:
Spec quality bottleneck. The system only works if specs are good. A rushed spec produces bad delegation, which produces bad output, which you have to redo synchronously. The pressure to "just start" is the enemy.
Too many active projects. The system extends the limit, but it doesn't remove it. Three active specs with agents executing in parallel is comfortable. Five is manageable. Eight starts degrading. Review sessions get too long, decisions pile up, design blocks shrink.
Cross-project dependencies. When Project A's API change blocks Project B's integration, async delegation breaks down. You need synchronous attention on both. The mitigation is designing projects to be independent, but that's not always possible.
Agent output quality. Complex architectural work, novel algorithms, and nuanced design decisions still need human depth. The agents handle implementation well. They don't reliably handle "should we even do this?" The system assumes the human does the thinking and the agent does the building. When that boundary blurs, quality drops.
The Economics of One
This system exists because a structural shift made it possible: AI made one person's execution bandwidth elastic.
Before AI agents, managing five codebases meant either hiring a team or shipping nothing. The coordination cost of a team (meetings, alignment, communication overhead) was the tax on parallel execution. Solo operators avoided it by working on one thing at a time.
AI agents changed the math. Execution scales without coordination tax. But management overhead doesn't disappear. It transforms. Instead of coordinating people, you coordinate workstreams. Instead of meetings, you write specs. Instead of PR reviews from teammates, you review agent output.
The trade-off is worth it. One person, with a good system, ships across multiple projects with zero communication overhead, zero alignment meetings, zero "let me sync with the team" delays. The system IS the team.
Team coordination
Meetings to align on priorities
PR reviews from 2-3 people
Async communication overhead
Context shared through conversation
Hiring and onboarding cost
System coordination
Specs define priorities, no meetings
Quality gates validate automatically
No communication overhead
Context lives in specs and code
New project = new worktree + spec
This isn't anti-team. Teams have strengths that systems don't: diverse perspectives, domain expertise, creative friction. But for the solo operator shipping across multiple projects, the system-first approach is structurally superior to trying to manage everything mentally.
Trade-offs
Real trade-offs, stated plainly.
Upfront investment. Writing good specs takes time. Setting up worktrees takes time. Building the habit of batching takes time. The system costs more upfront than "just start coding." It pays back across weeks, not days.
Rigidity. The system works because it imposes structure. But structure can become constraint. A spontaneous idea that doesn't fit the spec/delegate/review cycle feels like friction. The escape hatch: not everything needs the full system. Quick experiments can live in a scratch worktree with no spec.
Spec-writing is a skill. Bad specs waste agent time and produce bad output. Writing testable acceptance criteria, defining scope precisely, capturing the right constraints. It's a learnable skill, but it takes practice. First month is rough.
Review is still synchronous. Delegation is async. Review is not. You still need to read the diff, understand the changes, and make judgment calls. The system reduces synchronous work but doesn't eliminate it.
Principles
The system follows a few principles worth extracting:
Externalize state. Everything that can be written down should be written down. Your memory is volatile. Specs are persistent.
Batch decisions. Concentrated decision-making is more efficient than distributed decision-making. Fewer switches, deeper thinking.
Protect creative time. Management is a tax on creative work. Make the tax as small and predictable as possible.
Systems beat heroics. The goal isn't to be better at juggling. It's to build a system where you don't have to juggle.
These principles aren't specific to AI development. They apply to any domain where execution is cheap and coordination is expensive. AI just made that the default operating condition for software.
How to Start
If you're hitting the wall (too many projects, too much context-switching, decisions piling up), here's the minimal viable system:
Write one spec. Pick your most active project. Write down what you're building, what "done" looks like (testable acceptance criteria), and what's explicitly out of scope. Put it in a specs/active/ directory.
Create one worktree. For your second most active project, create a worktree: git worktree add .worktrees/project-name branch-name. Now you have two projects in two directories.
Delegate one task. Write a scoped spec for a feature in the second project. Hand it to an AI agent in its worktree. Move back to your primary project and do creative work.
Batch your first review. When the agent finishes, don't immediately switch. Finish your current design block. Then review the output in a dedicated review session.
That's the seed. Spec, worktree, delegate, batch. Once the pattern clicks, you scale it to more projects naturally.
More posts on building systems in the Building category.
