How do I dispatch parallel agents for independent tasks?

LingCode runs one agent loop at a time by default, and that's almost always what you want. A typical task — "refactor this module" — looks like:

1. Read module.swift.
2. Decide what to change based on what you read.
3. Write module.swift.
4. Run the test that touches module.swift.
5. Decide what to fix based on the test output.

Every step depends on the previous one. Parallelizing this is impossible — step 2 can't run before step 1 returns. LingCode's natural shape is sequential because reasoning is sequential.

Parallel dispatch is the exception, reserved for the cases below. Reaching for it on the wrong task wastes context and produces conflicting writes; reaching for it on the right task cuts a 20-minute job to 5.

Before asking LingCode to dispatch parallel agents, answer two questions about the task. Both must be "yes":

• No shared mutable state. The agents must not write to the same file, the same database row, the same git branch, or the same in-memory variable. Reads from shared state are fine; writes are the trap.
• No sequential dependency. Agent B's input must not require Agent A's output. If you'd write "first do X, then do Y" — that's serial.

If you can answer "yes" to both, parallel dispatch is safe and faster. If either answer is "no," stay serial.

The patterns that pay off in practice:

• Multi-target builds. Building iOS, Android, and macOS targets of the same app. Each has its own toolchain and project; no shared writes. Parallel cuts a 9-minute total build to a 3-minute one.
• Per-file independent reviews. Code review across 12 separate modules where each review writes to its own REVIEW_<module>.md. Each agent reads one file, writes one file — no collisions.
• Independent research questions. "Find every usage of API A," "Find every usage of API B," "Find every usage of API C." Three agents read the codebase, each writes to its own scratch note. The aggregation step at the end is what merges them.

Common thread: the dispatching turn ends with a clean merge step. The parallel agents produce isolated outputs; you (or a follow-up serial turn) combine them.

• Implementing one feature. "Add login" touches the UI, the model, the network layer, the keychain — all coupled. Running them in parallel produces four agents writing inconsistent contracts at each other.
• Refactor across coupled files. Renaming a Swift protocol that's adopted in 8 files: each file's edit depends on the protocol signature, and the protocol signature itself is being designed during the refactor. Serial loop with iterative judgment is faster end-to-end.
• Anything writing to the same git branch. Two agents committing to main in parallel = merge conflict in your own session. Use isolated worktrees if you genuinely need this — see the worktrees tutorial.
• Iterative debugging. "Try a fix, run tests, try another fix" is inherently sequential — each attempt informs the next. Parallelizing here just burns parallel attempts on stale information.

Ask LingCode to dispatch in parallel by naming the tasks as a list and stating they're independent. A prompt that works:

I want three independent things done in parallel — no shared
state, no ordering between them:

1. Audit Sources/Auth/ for force-unwraps and write findings to
   AUDIT_AUTH.md.
2. Audit Sources/Networking/ for force-unwraps and write findings
   to AUDIT_NET.md.
3. Audit Sources/Storage/ for force-unwraps and write findings to
   AUDIT_STORAGE.md.

Dispatch one sub-agent per task. After all three return,
synthesize a top-level AUDIT_SUMMARY.md that aggregates the
counts and ranks modules by severity.

LingCode dispatches three sub-agents, each with its own context window, runs them concurrently, and joins on completion. The synthesis step is a final serial turn — that's where the merge happens.

Sub-agents don't share your conversation history. They get the task you assigned them and the project files — nothing else. This is a feature, not a bug:

• Smaller context per agent = faster, cheaper, more focused. Each sub-agent isn't carrying your 50-turn history into a 5-minute audit.
• No context leakage between agents = parallel decisions don't accidentally agree because they read the same recent assertion. Each gets independent judgment.

The price you pay: each sub-agent must be given enough instruction to do its job standalone. "Audit Auth" isn't enough — say which directory, what to look for, where to write findings. The prompt above does this for all three.

Parallel dispatch produces N isolated artifacts. The value comes from synthesizing them — and synthesis is serial. Spend more thought on the merge prompt than the dispatch prompt:

Now that AUDIT_AUTH.md, AUDIT_NET.md, and AUDIT_STORAGE.md exist,
synthesize AUDIT_SUMMARY.md:

- Total force-unwrap count across all three modules.
- Ranked list of files by count, highest first.
- Patterns that appeared in 2+ modules (likely systemic, fix once).
- Patterns unique to one module (likely local, fix in place).
- Three concrete next-step PR titles.

Read the three audit files; do not re-scan the source code.

The "do not re-scan" instruction matters. Without it, LingCode often re-does the work the sub-agents already did — defeating the parallelization. Trust the artifacts.

After a parallel run, sanity-check two things:

• No file was written by two agents. Run git status or check timestamps. If two artifacts ended up at the same path, one overwrote the other — your "independent" tasks weren't independent.
• Wall time was actually shorter. If you parallelized three 30-second tasks, the overhead of dispatching may have eaten the win. Parallelization pays off when each sub-task is at least a minute or two of real work.

If the parallel run didn't beat a serial run, that's information for next time. Not every "looks parallel" task actually is.

Package the dispatch heuristic as a skill so LingCode applies the two-question test before parallelizing — and stays serial when serial is right:

---
name: dispatching-parallel-agents
description: Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies. Triggers: 'do these in parallel', 'split this work', 'run multiple agents', 'parallelize', 'fan out', batch of independent file edits, multiple test fixtures, multiple isolated components. Actions: dispatch, parallelize, batch, fan-out, fan-in. Anti-pattern: tasks that share state, sequential dependencies, conflicting writes. Compresses wall time when the two-question test passes (no shared state + no sequential dep).
---

Before dispatching parallel agents, answer two questions about
the task set:

1. Is there shared mutable state? (Same file, same DB row, same
   git branch, same in-memory variable.) If yes — stay serial.
2. Does any task's input depend on another task's output? If yes
   — stay serial.

Both must be "no" to parallelize.

When parallelizing:
- Give each sub-agent a self-contained task description. They do
  not share conversation history.
- Have each sub-agent write to its own artifact path. No two
  agents writing the same file.
- Plan the merge step explicitly. The synthesis turn is serial
  and reads the artifacts; it should not re-scan source.

Good fits: multi-target builds, per-file independent reviews,
independent research questions.

Bad fits: implementing one feature, refactor across coupled
files, two writes to the same git branch, iterative debugging.

After parallel runs, sanity-check: no file written by two agents,
wall time actually beat serial.

Save as ~/.lingcode/skills/dispatching-parallel-agents/SKILL.md — see Install a skill for the exact location and how skills get discovered.

Get LingCode →