Parallel Coding-Agent Workflow Based on Simon Willison’s Process

Parallel-agent task triage

Choose parallel agent work by expected usefulness and review cost, not by how many sessions are available.

Inventory the backlog

For every candidate task, record the desired outcome, whether code should be retained, current specification quality, verification path, repository sensitivity, likely files, and estimated review effort.

Classify each task

Use one of four source-derived classes:

Disposable proof-of-concept research

Use an agent to test whether a library, protocol, API, or technical approach can work. The result is evidence and a recommendation; experimental code is disposable unless separately promoted.

Reusable codebase explanation

Ask a read-only agent to trace behavior, identify files, explain an integration, or locate missing documentation. Preserve useful notes as context for future work.

Small maintenance

Delegate warnings, deprecations, focused test failures, documentation repairs, and other low-stakes changes with an obvious definition of done.

Carefully specified implementation

Delegate code intended to ship only after the human has chosen the problem and approach. Supply the outcome, relevant patterns, non-goals, acceptance criteria, and verification plan so review does not begin by reconstructing intent.

If a task fits none of these classes, keep it for human clarification before assigning it.

Estimate review cost

Rate each result by the attention needed to understand and accept it. Prefer work whose desired behavior and evaluation are already known. Defer implementation likely to create a large unexplained diff or decisions the human has not made.

The operator's review capacity is the concurrency limit. Do not create a queue of meaningful changes that grows faster than it can be reviewed.

Choose isolation by risk

• Use a disposable directory or checkout for proof-of-concept code.
• Use read-only access for codebase explanations.
• Use a scoped branch or isolated checkout for maintenance.
• Use a sandboxed asynchronous environment for riskier repository work.

Do not run untrusted repository instructions with unrestricted local or network access.

Write and launch assignments

For research, ask a concrete question and require sources, commands, findings, limitations, and a recommendation. For implementation, include the selected approach and checks. Launch only independent tasks within the declared review limit.

Preserve the right artifact

• Store useful explanations and research notes.
• Discard exploratory code by default.
• Review intended code against the original specification.
• Land only work whose checks and remaining risk are explicit.

Return:

Source attribution

Independently compiled by XSkills from Simon Willison's article about adopting parallel coding agents. Willison did not author or review this skill. Research proofs of concept, codebase explanations, small maintenance, carefully specified implementation, disposable checkouts, and review bandwidth as the bottleneck come from the source. The formal classification table, review-cost rating, and launch gate are XSkills adaptations. Attribution does not imply endorsement.