Background coding agents vs pairing: which work suits each

Stefan-Iulian Tesoi · 16 October 2026 · 6 min read

Hand work to background coding agents when the outcome can be written down and checked without you in the room: a bounded change, acceptance criteria, a command that proves it. Pair when the work is still being discovered. An agent working alone settles every ambiguity by choosing a reading, and you learn which one when the pull request arrives.

The choice is not between two products. GitHub, OpenAI, Cursor and Anthropic each ship both modes: an interactive session you watch and steer, and a cloud coding agent that takes a task, works in an environment of its own and comes back with a branch. What differs is the work, and whether it can leave the room.

What are background coding agents?

Background coding agents are coding agents that work on a task with nobody watching, in their own environment, and return the result as a branch or a pull request. The vendors have converged on the shape and are renaming it to match: Cursor's Background Agents became Cloud Agents, and GitHub Copilot coding agent became Copilot cloud agent in 2026.

The interactive counterpart is what used to be called AI pair programming: the agent in your editor or terminal, you reading each step and correcting it before the next one. An asynchronous coding agent trades that steering for parallelism. Claude Code's documentation shows three --cloud tasks started one after another and running at the same time.

Which work can leave the room, and which cannot?

Work can leave the room when someone could check the result without having watched it being made. That is a property of the item, not of its size.

Work that suits a background agent:

• A bug with a reproduction, and a failing test the fix has to turn green.
• A dependency upgrade whose test suite already covers the call sites.
• A rename or migration across forty files, with a grep that should return zero lines afterwards.
• A small feature whose criteria name a command and the output it should print.

Work to keep pairing on:

• A design whose shape you will only recognise when you see it.
• A bug nobody can reproduce yet, where each step depends on what the last one turned up.
• Code nobody on the team understands, where the explanation is the deliverable and the diff is a side effect.

The test: can the outcome be checked without you?

Three questions decide it, and an item needs a yes to all three before it goes to the background.

1. Could the criteria be written now, before any code exists? If the honest criterion is "I will know it when I see it", you are the criterion, and you need to be there. Acceptance criteria an agent can verify name a command and a result.
2. Is everything the agent needs inside the item? A background agent reads its task once. GitHub's documentation states that Copilot "does not see comments added after assignment". Whatever the team agreed in a thread afterwards does not exist for the agent.
3. Is a wrong reading cheap to throw away? A branch that guessed wrong costs the review it takes to notice. A guess inside a data migration costs more.

If the only acceptance test is your reaction to the result, the work cannot leave the room.

Anthropic's own guidance for Claude Code draws the same line: plan the task interactively in plan mode, commit the plan, then send its execution to the cloud. That is pairing on the part still being discovered and delegating the part that is not.

Which tasks go wrong when they are delegated too early?

The ones that contain a decision nobody wrote down. A background agent does not stop at the decision; it makes one, plausibly, and carries on, so the result looks deliberate.

This blog has its own example. In the first week of October 2026, an agent given a one-line instruction to write posts found the list of reader questions empty and filled the gap with topics taken from the product backlog. Six posts came back, fluent, formatted and about the wrong thing, and all six were withdrawn and redirected. The instruction held a choice about where topics come from. It was made out of sight, and review was the first place a person could see it.

Ten minutes of pairing at the start would have surfaced it, because the first question would have been the right one. An agent that stops and asks when it gets stuck is the other defence, and it works only when the gap is visible to the agent. Here it was not: an empty list looked like permission.

How does the review load differ between the two?

Pairing spends attention during the work; delegation spends it afterwards, and spends more. In a paired session the review is continuous: you watched each file change and corrected the reading as it formed, so the final diff holds no surprises and takes minutes to accept.

A background pull request arrives whole. The reviewer meets the work for the first time and has to reconstruct intent from the diff and the agent's summary, which takes ten to twenty minutes against written criteria and longer without them.

That is why the number of background agents a team can run is set by review rather than compute. One person reviewing carefully saturates at two or three concurrent agents; the arithmetic is in how many coding agents one team can run, and it is the number engineering leaders should plan around.

Laimonade sits on the delegated side of this. A background agent pulls one work order over MCP with the criteria inside it, hands back its evidence, and can take the item as far as In Review. Nothing it can call marks the item Done. The full sequence, from specifying to verifying, is in the coding agent workflow a team can actually run.

Frequently asked questions

Can one person pair with one agent while others run in the background?

Yes, and it is the arrangement that tends to hold up: one interactive session on the item that is still unclear, one or two background agents on items already specified. The limit is the pull requests that come back. Each needs a careful read, and they arrive while you are concentrating on the paired session.

Are background agents cheaper than interactive sessions?

In compute, roughly the same: the same models do the same work, and Claude Code's cloud sessions count against the same plan limits as local ones. In people's time they are cheaper while running and dearer at review. A background run that guessed wrong costs a full review plus a second run; pairing would have caught the guess in minutes.

Should a background agent open a draft or a ready pull request?

A draft, until its own checks have run and the evidence is attached. A ready pull request asks a person to review now, and one opened before the tests finish asks them to review a guess. Marking it ready is the agent's claim that the criteria hold, so it should come with the commands that show they do.