Agent-Driven Development: From Supervisor to Orchestrator

The search for a single, all-powerful coding agent is a distraction. The current model—supervising one AI in a conversational loop—is a productivity bottleneck, not a breakthrough. It keeps you chained to a single task, reacting to one stream of output.

The real unlock isn’t a 10x agent; it’s becoming a 10x orchestrator.

The goal is to shift from supervising one agent to directing a team of them. You run them asynchronously and in parallel across branches, worktrees, and repositories. Your role changes from a conversational partner to a systems conductor: defining work, dispatching agents, and integrating verified results. This is a practical playbook for that shift.

The Orchestrator’s Pillars: Isolation and Verification

To manage a portfolio of agent-driven tasks without creating chaos, you need a system built on two pillars: radical isolation and relentless verification. These principles are not suggestions; they are the foundation that makes parallel agentic work possible. Without them, you’re just creating merge conflicts and technical debt at an accelerated rate.

1. Isolate Everything: Each task must live in its own sandboxed environment. This prevents dependency conflicts, build contamination, and merge nightmares. It gives each agent a clean room to work in and ensures that one agent’s failure doesn’t derail another’s progress.
2. Verify Relentlessly: You cannot manually review the output of five agents at once. A non-negotiable, automated verification script is the only way to scale your attention. It’s the safety harness that allows you to move fast with confidence.

With these pillars, you can confidently parallelize complex engineering work.

Pillar 1: Isolate with Worktrees and Workspaces

Your primary tools for isolation are version control features that create separate file trees without the overhead of cloning a repository multiple times. You need to be able to spin up and tear down these environments with near-zero cost.

Git Worktrees: Simple, Directory-Based Isolation

Worktrees are the simplest way to check out multiple branches into different directories, all linked to a single .git history. This is ideal for tasks that are independent but need separate build artifacts (node_modules) or runtimes. Think of it as having several clones of your project open at once, but without the disk space and synchronization headaches.

# Create two isolated directories from the same repo
git worktree add ../feature-auth feature/auth
git worktree add ../viz-dash feature/viz-dash

# Open separate terminals, cd into each, and dispatch an agent
cd ../feature-auth && claude "Implement the auth logic per the spec"
cd ../viz-dash && claude "Build the dashboard components"

# When a task is merged and done, safely remove the worktree
git worktree remove ../feature-auth

JJ: Agent-Native Sandboxes

Jujutsu (jj) treats your working copy as an implicit commit, making it purpose-built for agentic workflows where you never want to lose work. Its ‘revisions’ are cheap, instant sandboxes that allow for rapid context switching. You can let an agent work on a task, then instantly jump to another to check progress, all without stashing or complex branch management.

For true filesystem isolation like worktrees, jj offers workspaces. This gives each agent its own directory, build artifacts, and dependencies, combining the benefits of worktrees with jj’s powerful history manipulation. With jj, you can let agents create messy, iterative commits, then use commands like jj squash and jj split to programmatically curate a clean history for final review.

# Create a new workspace and directory for a feature
jj workspace add ../project-feature-a --rev main
cd ../project-feature-a

# ...run agents, install dependencies, etc.

# When done, the workspace is removed but the commits remain
jj workspace forget ../project-feature-a

Pillar 2: Verify with a Single Command

Parallel work is unsafe without automated quality gates. Create a single, authoritative script that runs the same checks your CI server does. An agent’s job isn’t done until this script passes. This script becomes the agent’s contract for ‘doneness.’ It codifies your quality standards and removes ambiguity from your instructions.

A good verify.sh script is comprehensive, covering the full spectrum of code health from style to security.

#!/usr/-bin/env bash
set -euo pipefail

# 1. Format and Lint for consistency
prettier --write .
eslint --fix .

# 2. Check Types to catch integration errors
tsc --noEmit

# 3. Run All Tests for correctness
npm test

# 4. Check for Security Issues
npm audit

echo "✔ Verification passed."

Now, the instruction for every agent is simple and unambiguous: ‘Implement the feature, then run ./verify.sh and fix any errors until it passes.’ This makes verification a deterministic, repeatable task that the agent owns.

Specializing the Workforce: Roles and Subagents

Just as you wouldn’t ask one engineer to do everything, you shouldn’t rely on one generalist agent. The orchestrator model thrives on specialization. By assigning clear roles, you can create more effective and reliable workflows. You might have one terminal tab open with a ‘writer’ agent and another with a ‘reviewer’ agent.

Consider these specialized roles:

• Test Author: Writes unit tests, integration tests, and fixtures based on a spec before any implementation code exists.
• Code Implementer: Its sole job is to make the tests written by the Test Author pass.
• Refactor Specialist: Analyzes existing code for improvements, guided by specific goals like improving performance or readability.
• Security Auditor: Scans for vulnerabilities, checks dependencies, and flags potential issues.

By breaking down the work and using specialized prompts or even different models for each role, you create a pipeline where the output of one agent becomes the input for the next, with your verification script acting as the gate between stages.

The Workflow in Practice

Here is what orchestrating three tasks looks like. You begin by writing three precise specs, each with clear acceptance criteria. Then, you fan them out by creating an isolated environment for each—two jj workspaces and one git worktree.

In three separate terminal windows, you cd into each directory and assign an agent to its task. Your role is now to monitor and unblock. You cycle through your terminals, not to supervise line-by-line, but to check for errors, approve critical tool calls, and ensure the ./verify.sh script is running and passing. When an agent reports a green build, you step in for the final, human-centric review.

You’re not looking for typos or style violations; the verify.sh script already handled that. You’re evaluating architectural fit, naming clarity, and potential side effects—the things that require true engineering judgment. Once approved, you merge the clean, verified work and tear down the sandbox. The cost of a failed experiment is near zero, so you can abandon stalled efforts without hesitation and move on.

Risks and How to Mitigate Them

This high-leverage model introduces new classes of risk, but they can be managed with discipline.

• Spec Drift: An agent can misinterpret a vague spec, leading to wasted work. Mitigation: Start by having an agent write tests that codify the acceptance criteria first. The spec is only ‘correct’ when the tests reflect your intent.
• Merge Conflicts: Parallel work naturally leads to conflicts. Mitigation: Keep branches or sandboxes short-lived. Prefer smaller, independent tasks. Use the isolation of worktrees and workspaces to minimize overlap.
• Flaky Verification: An unreliable verify.sh script will stop your entire workflow. Mitigation: Stabilize your CI and local validation scripts before you automate. Make the script the single source of truth for code quality.

The Mindset Shift

Agent-Driven Development isn’t about finding a magical agent that does everything. It’s a systems-thinking approach to development. You are the architect and conductor of a workforce, not the user of a tool.

Your leverage comes from the precision of your specs, the strength of your verification, and the efficiency of your parallel workflow. The work gets done while you’re thinking about the next problem. Once you internalize this orchestrator’s mindset, running five projects at once becomes calm—and normal.