Swarm-Coding with Multiple Background Agents for Large-Scale Code Maintenance

faire · E-commerce · 2025 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Large-scale software maintenance and developer productivity

Faire wanted to automate repetitive engineering maintenance such as expired feature-flag cleanup and test migrations without blocking teams on manual developer time, while still keeping pull requests reviewable and connected to existing Slack, Jira, GitHub, and CI workflows.

Constraints:

• Background agents had to work in parallel without losing task state.
• Non-engineers needed a safe way to request simple code changes.
• Autonomous pull requests still required human review and build feedback.
• Agents needed access to Jira, Slack, Buildkite, and repository context.
• Prompt templates had to direct agents to relevant files without wasting context.

Architecture

Faire implemented swarm-coding with GitHub Copilot background agents, custom instructions, MCP servers, Slack/Jira delegation, and review automation. A Slackbot or other context creates issues, MCP tools expose task and state context, Copilot creates PRs in parallel, and CI/review automation feeds build failures and readiness signals back into the workflow.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  fairey_slackbot["Fairey Slackbot"] --> mcp_assignment_tool["MCP assignment tool"]
  slack_and_jira_state["Slack and Jira state"] --> mcp_assignment_tool
  mcp_assignment_tool --> github_copilot_background_agents["GitHub Copilot background agents"]
  prompt_templates["Prompt templates"] --> github_copilot_background_agents
  github_copilot_background_agents --> pull_request_automation["Pull request automation"]
  pull_request_automation --> slack_and_jira_state

Components

Data flow

Users or scheduled jobs identify maintenance tasks in Jira or Slack. MCP tools assign GitHub issues to Copilot background agents, which create placeholder PRs and iterate. Build and review automation summarizes failures, controls review routing, and notifies the originating Slack thread so humans can inspect and approve changes.

Why this architecture

Faire used a swarm of background agents because large maintenance programs can be decomposed into many scoped tasks, while MCP and existing collaboration tools keep the agents grounded in state and process.

Models used: GitHub Copilot background agents · MCP-enabled assistants

Scale

• 18% of Faire's engineering team had merged at least one Copilot PR after just over a month.
  “18% of the engineering team are Copilot users (have merged at least one Copilot PR).”article, stated
• Faire had merged over 500 Copilot pull requests.
  “We’ve merged over 500 Copilot pull requests.”article, stated
• Average reported time saved was 39.6 minutes per pull request.
  “Average time saved reported is 39.6 minutes per PR.”article, stated
• Copilot users' PR volume rose 25% on average.
  “Copilot user’s PR volume rose 25% on average (or, 41% for DX’s TrueThroughput metric).”article, stated

Alternatives considered (roads not taken)

Manual engineer-led cleanup for every maintenance task

Rejected because: It consumed engineering time on tedious work and delayed lower-priority fixes.

Use one agent task at a time

Rejected because: Swarming gains come from parallelizing separate task slices across multiple background agents.

Patterns

multi-agent-orchestration (agent coordination)

Faire coordinated multiple background agents in parallel to swarm large maintenance programs.

tool-use-orchestration (tooling)

MCP servers let agents use Jira, Slack, Buildkite, and assignment tools as part of the coding workflow.

human-in-the-loop-gate (review)

Copilot-authored PRs require human review before owner review and merge.

Tradeoffs

Coordinate many background agents rather than wait for human-driven maintenance queues.

Chose Parallel background-agent swarm over Sequential manual maintenance.

Rationale: Parallel agents reduced burden on engineers and made large-scale changes faster.

Integrate agents into existing tools instead of creating a separate AI work queue.

Chose Slack, Jira, GitHub, Buildkite, and MCP integration over Standalone agent dashboard.

Rationale: Existing systems already hold task state, approvals, and operational context.

Gotchas (what bit them)

Background agents need task state or duplicate and stale work become hard to manage.

Root cause: Parallel coding agents can leave incomplete work across Slack threads, Jira issues, and PRs.

Resolution: Use the same ticketing system and MCP search tools to surface in-flight work.

Prompt templates can waste context if they do not narrow agents to the right files.

Root cause: A generalized background agent may burn context searching the codebase.

Resolution: Use prompt templates with variables for the task specifics.

Autonomous PRs still need readiness and failure handling.

Root cause: Agents may open PRs before they are ready or hit CI failures without targeted feedback.

Resolution: Require review sequencing and automatically summarize build failures back to Copilot.

Evaluation

Faire measured adoption, merged Copilot PRs, PR volume, and self-reported time saved, while using PR review and CI signals as operational controls.

Metrics: 18% of engineering team using Copilot. · Over 500 Copilot PRs merged. · 25% average PR volume increase for Copilot users. · 39.6 minutes average reported time saved per PR.

Outcomes

• Background agents were adopted by 18% of the engineering team in the first month.
• Faire merged over 500 Copilot pull requests.
• Copilot users saw a 25% average PR volume rise.
• Average reported time saved was 39.6 minutes per PR.

The article reports early-stage adoption after just over a month, with 18% engineering-team usage and over 500 Copilot PRs.