The Manager Pattern: Treating Your AI Like a Development Team

Most people interact with AI coding tools as a single entity. You talk to it, it responds, you iterate. That works for small tasks. But for anything substantial - building a feature, refactoring a module, fixing a complex bug - treating AI as a team of specialists with a manager is dramatically more effective.

I call this the Manager Pattern, and it's the foundation of how I build software today.

The Core Concept

Instead of one AI instance doing everything sequentially, you have:

• A Manager - coordinates work, talks to you, never writes code
• Implementation Agents - write code, create files, make changes
• Verification Agents - run tests, lint, typecheck, review
• Explore Agents - research the codebase, find patterns, gather context

The manager decomposes your request into tasks, assigns them to appropriate agents, and coordinates the results. You talk to the manager, not the agents.

Task Decomposition

The most important skill in the Manager Pattern is decomposing work into parallelisable, independent tasks. Here's how I think about it:

Good decomposition

Feature: "Add user profile page"

Tasks:
1. Create UserProfile component (Agent A → src/components/UserProfile.tsx)
2. Create profile API route (Agent B → src/api/profile.ts)
3. Add profile page route (Agent C → src/pages/profile.tsx)
4. Write tests (Agent D → src/__tests__/profile.test.tsx)
5. Verify all (Agent E → run lint, typecheck, tests)

Each agent owns different files. They can all work simultaneously without conflicts.

Bad decomposition

Feature: "Add user profile page"

Tasks:
1. Create component and page (Agent A → touches UserProfile.tsx AND profile.tsx)
2. Add API and update component (Agent B → touches profile.ts AND UserProfile.tsx)
   ⚠️ Conflict! Both agents edit UserProfile.tsx

When two agents edit the same file, one will overwrite the other's changes. File ownership is the number one rule of decomposition.

File Ownership

Every task should have a clear "file ownership" scope. The rule is simple: one agent per file, no exceptions.

If a feature requires coordinated changes across files, there are two approaches:

1. Sequential agents. Agent A creates the type definitions. When it's done, Agent B creates the component that imports those types. The dependency means they can't run in parallel, but they won't conflict.
2. Interface contracts. Agree on the interface upfront (in the task prompt), and let both agents work against that contract simultaneously. Agent A creates the API that returns UserProfile, Agent B creates the component that consumes UserProfile. They both know the shape; they don't need to see each other's code.

Parallel vs Sequential Work

Not everything should be parallelised. Here's my decision framework:

Parallel when:
- Tasks touch different files
- Tasks have no data dependencies
- Each task is self-contained (>5 minutes of work)

Sequential when:
- Task B depends on Task A's output
- Tasks modify the same file
- Task B needs to verify Task A's work

Don't parallelise when:
- The total work is <10 minutes for one agent
- Coordination overhead exceeds the time saved
- Tasks are tightly coupled with shared state

Communication Patterns

Agents in a team communicate through the manager. There are three communication patterns I use:

Fire and forget

The manager assigns a task and doesn't need the result to continue. Used for independent implementation tasks.

Wait for result

The manager assigns a task and needs the result before assigning the next task. Used for sequential dependencies and verification.

Broadcast

The manager sends information to all agents in a team. Used when context changes mid-build (like "the API shape changed, here's the new interface").

When to Group Agents

Sometimes it's better to have one agent do more work rather than splitting across many. My rule of thumb:

• Group when the work is cohesive. A component and its styles and its tests are tightly coupled. One agent that understands the full picture will do better than three agents working in isolation.
• Split when the work is independent. A new API endpoint, a new page component, and a database migration are independent concerns. Three agents will be faster and produce better results than one agent context-switching.
• Never split trivially. If a task takes one agent 5 minutes, splitting it into three 2-minute tasks adds more coordination overhead than it saves.

Error Handling

Agents fail. They produce code that doesn't compile, tests that don't pass, or implementations that miss the mark. The Manager Pattern handles this through layers:

1. Hooks catch mechanical errors (formatting, secrets, env files) immediately
2. Verification agents catch compilation and test failures after implementation
3. The manager interprets verification results and re-assigns fixes to the appropriate agent
4. You catch architectural and business logic issues during your review

The key insight is that the manager should re-assign fixes to the same agent that made the error when possible. That agent has the freshest context about the code it just wrote.

Real-World Example

Here's a real session from last week. I needed to add a blog section to my portfolio site:

Me: "Build the blog section with data layer, listing page, detail page, and card component"

Manager:
  → Creates team "blog-build"
  → Task 1: "Create blog post data with TypeScript interface" → Agent A
  → Task 2: "Create BlogCard component" → Agent B (waits for Task 1 types)
  → Task 3: "Create BlogPage with grid layout" → Agent C (waits for Task 1 + 2)
  → Task 4: "Create BlogPostPage detail view" → Agent D (waits for Task 1)
  → Task 5: "Verify all" → Agent E (waits for all)

Timeline:
  [0:00] Agent A starts (data layer)
  [0:45] Agent A done → Agents B and D start simultaneously
  [1:30] Agent B done → Agent C starts
  [1:45] Agent D done
  [2:15] Agent C done → Agent E starts (verification)
  [2:45] Agent E done  -  all checks pass

Total: ~3 minutes wall clock for what would have been 30-45 minutes of manual work.

The Manager Pattern isn't just about speed. It's about working at a higher level of abstraction - thinking about what to build rather than how to type it. And once you get comfortable with it, you'll wonder how you ever worked any other way.