How I Manage Multiple AI Projects Without Losing My Mind

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.

The Spec Lifecycle

Every project or feature follows the same lifecycle:

1. Create: define scope, acceptance criteria, constraints
2. Active: implementation in progress, agent working against ACs
3. Review: all ACs pass, quality gates green, awaiting human review
4. Shipped: merged, deployed, archived with retro notes
5. Dropped: abandoned with documented reasoning, reusable pieces preserved

Specs live in a directory structure that makes status visible at a glance:

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.

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:

1. Scope the task (write or review the spec)
2. Delegate to an agent (point it at the spec, start execution)
3. Move on to the next project
4. 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:

1. Design session: pick the highest-priority project, do the creative work—architecture, spec writing, problem decomposition. This gets the synchronous, undivided attention.
2. Delegation pass: scope tasks for the other projects, hand them to agents in their respective worktrees.
3. 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.

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.

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.
• Isolate context. Physical separation (worktrees) beats mental discipline (remembering which branch you're on).
• 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:

1. 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.

2. 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.

3. 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.

4. 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.