Fire-and-Forget Coding: The Rise of Background Agents in 2026

Last week I gave an agent a ticket, closed the laptop, and went to lunch. When I got back there was a pull request waiting — tests green, a short summary, a diff that touched eleven files. It worked. I merged it.

The other three I dispatched that morning did not go as well. One quietly deleted a feature flag because it "wasn't referenced" (it was, from a config file the agent never read). One burned a few dollars rediscovering that our test suite needs a database container it couldn't start. One produced a diff so plausible and so wrong that I almost approved it on a phone screen.

That's the honest shape of background agents in 2026. The good run feels like cheating. The bad runs feel like managing a junior who works at 3am, never asks questions, and is very confident.

Short version: background agents have basically solved "write code while I'm not watching." What they have not solved — what they have arguably made worse — is review. The bottleneck moved. It used to be how fast a model could type. Now it's how fast you can read, trust, and merge work you didn't see get written. If you don't build a process for that, you don't get a force multiplier; you get a backlog of half-baked PRs.

What "background agent" actually means now

A background agent is an async coding agent that runs somewhere other than your foreground attention — usually a cloud VM — does the task, and hands you a result later. You assign work and walk away. That's the whole pitch, and as of mid-2026 every major harness ships some version of it.

Cursor rebuilt its entire interface around this in version 3.0. The release note is blunt about the new center of gravity: you can "run many agents in parallel across repos and environments: locally, in worktrees, in the cloud, and on remote SSH" (cursor.com/changelog/3-0). Their cloud agents run in sandboxes, "iterate until they've validated their output," and turn Linear or Jira issues straight into PRs (cursor.com/cloud). Futurum's read on the 3.2 follow-up called the IDE "reframed as an agent execution runtime" (futurumgroup.com) — marketing-adjacent, but directionally true.

Claude Code went the same way but kept the vocabulary precise. Its docs distinguish four ways to parallelize: subagents (delegated workers inside one session), agent view (claude agents — "dispatch and monitor sessions running in the background," a research preview), agent teams (a lead coordinating workers, "experimental and disabled by default"), and dynamic workflows (a script that fans out many subagents and cross-checks them) (code.claude.com/docs/en/agents). The four are not interchangeable, and the names are doing real work.

Devin, which more or less started this category, spent 2026 turning one autonomous agent into many. Its March 19 release added "Devin Manages Devins" — a coordinator session that scopes work and delegates to "a team of managed Devins that work in parallel," each on its own isolated VM (docs.devin.ai/release-notes/2026).

The common thread: isolated environment, async hand-off, PR at the end. The differences are in how much rope you get and how the review lands back on you.

What they're genuinely good at

Be specific about where this pays off, because the hype flattens it.

Background agents are good at bounded, well-specified, verifiable work. The sweet spot is a task where (a) you can describe "done" in a sentence, (b) a test or a type-checker can prove it, and (c) it doesn't require taste. Dependency bumps with a passing suite. Adding a field through a known stack. Writing the obvious unit tests. Mechanical refactors across many files — the kind of thing Claude Code's /batch skill is built for, splitting "one large change into 5 to 30 worktree-isolated subagents that each open a pull request" (code.claude.com/docs/en/agents).

They're good at parallel breadth. Cursor's /best-of-n runs the same task across multiple models, "each in its own isolated worktree, then compares outcomes" (cursor.com/changelog/3-0). For a gnarly bug where you genuinely don't know the right approach, firing three attempts and keeping the best one is a real use of being able to run things you're not watching.

And they're good at letting one person do more than one thing. As a solo builder, the constraint was never ideas — it's that I can only be in one file at a time. Dispatching the boring half while I do the interesting half is the actual win. Not "the AI builds my app" — that's still a fantasy. "The AI clears my backlog of small obvious things while I think" is shippable today.

What they're bad at, honestly

The failure modes are not exotic. They're boring and they repeat.

Context starvation. A background agent only knows what it gathered before it started running. It can't ask you a clarifying question mid-run — or if it can, you're at lunch. So it guesses. My deleted-feature-flag incident was pure context starvation: the agent reasoned correctly over the files it had and reached a wrong conclusion because the relevant fact lived somewhere it didn't look. The fix is upfront: better task framing, an AGENTS.md that tells it where things live, links to the issue. Garbage in, confident garbage out.

Silent drift. The scary failure isn't the PR that's obviously broken — you'll catch that. It's the one that's 90% right and subtly wrong, with a clean summary that describes the correct behavior while the diff does something else. The summary is generated from intent, not from what the code does. Trust the diff, not the description.

Merge conflicts and stepping on each other. Run six agents against one repo and they will collide. The whole industry's answer is worktree isolation — each agent gets its own git checkout so parallel sessions "never edit the same files" (code.claude.com/docs/en/agents). That solves agents fighting during the run. It does nothing about six branches all landing on main Tuesday afternoon, each slightly stale. The conflict just moves to merge time, which is to say it moves to you. Devin shipped merge-conflict detection in review in February precisely because this is where the parallel dream meets reality (docs.devin.ai/release-notes/2026).

Runaway cost. Async means no one's watching the meter. Background agents lean on the priciest models, and one honest comparison clocked an "easy PR" on Cursor's background agent around $4.63 during preview (aitechfy.com). That's fine for a real ticket and absurd for a typo. Costs "get unpredictable on novel work," and per-task spend stays "opaque unless you check the usage dashboard" (techsy.io). Anthropic's own docs put it plainly: running several agents at once "multiplies token usage" (code.claude.com/docs/en/agents). Set spend limits before you fire-and-forget, not after the invoice.

The real bottleneck is review, and it's now yours

Here's the part the demos skip. When generation was the slow step, review was free — you watched the code appear, line by line, and approved it as it came. Background agents break that. The code appears while you're gone. Now you're a reviewer of work you didn't watch, at the volume of however many agents you dispatched.

The vendors clearly know this, because the most interesting 2026 shipping wasn't in generation — it was in review. Devin launched a whole review product in January that groups related changes, "detects copied code, bugs, and security issues," and added auto-merge and an "Auto-fix with Devin" button by April (docs.devin.ai/release-notes/2026). That tells you where the pain is.

But be careful what you wish for. The same comparison that priced these tools also notes that "every team we know requires human review before merge" and calls auto-merge "a foot-gun" (techsy.io). I agree. The point of an agent reviewing an agent is to triage your queue — to flag the three PRs that need your eyes and rubber-stamp the boring two — not to remove you. The day you let an agent approve another agent's work into main unsupervised is the day you've automated the production of subtle bugs.

So the skill that actually matters in 2026 isn't prompting. It's running a review queue without drowning. Concretely:

• Triage before you read. Cheap, mechanical signal first: did tests pass, did the type-checker pass, is the diff small. A PR that fails its own gate doesn't earn your attention yet.
• Read the diff, never the summary. The summary is the agent's intent. The diff is what happens. They diverge silently.
• Make "done" provable. If you can't write a check that confirms the task, you don't have a background-agent task — you have a thing you'll babysit anyway. Push the verification into the agent's run so it self-tests; Cursor's cloud agents "iterate until they've validated their output" (cursor.com/cloud), and that gate is worth more than any prompt tweak.
• Cap the queue depth. More agents is not more output past the point you can review. If PRs land faster than you clear them, you've built a backlog generator, not a force multiplier.

A day-in-the-life that actually works

Here's the loop I run as a solo builder. It's mundane on purpose.

Morning: I triage my own issue list into two buckets — agent-shaped (bounded, testable, boring) and me-shaped (judgment, architecture, anything touching money or auth). I dispatch three or four agent-shaped tickets, each to its own worktree or cloud sandbox, with a real description and a link to the issue. Then I close that window and go work on a me-shaped problem myself, in the foreground, the old-fashioned way.

I do not sit and watch them. The entire point is the async. Watching a background agent is just a synchronous agent with extra steps and a worse view.

Mid-morning, PRs start landing. I run the triage pass: gate status first, then small diffs before big ones. The two that passed cleanly and touch ten lines, I read and merge in five minutes each. The one that "succeeded" but rewrote more than I expected, I read carefully — that's where drift hides. The one that failed its own tests, I either reframe and re-dispatch with the new context, or pull down to local and finish by hand. An agent burning forty minutes on a broken test environment is just telling me my setup is the problem; I fix it once and the next run is clean.

I merge agent branches one at a time, rebasing as I go, not in a batch at end of day — that's how you avoid the Tuesday-afternoon conflict pileup. And I keep a hard rule: nothing auth-, billing-, or migration-related ships from a background run without me reading every line. That's not me-shaped because it's hard. It's me-shaped because the blast radius is large and the agent doesn't feel the consequence.

Net for the day: maybe six tickets closed where I'd have done two. Not because the agents are smart — some of those PRs were rework — but because the boring half got cleared in parallel while I spent my actual attention on the half that needed a human.

The grounded take

Background agents are real, they ship, and the parallel-cloud-VM-to-PR loop works well enough to change how a solo builder spends a day. That's not hype. What is hype is the implied "and then you don't have to do anything." You do. The work just changed shape — from typing code to specifying, gating, and reviewing it.

Treat them like a fast junior team that works while you sleep and produces a stack of PRs by morning: some excellent, some quietly wrong, all confident. The payoff is real if you build the review muscle to match the generation. If you skip that, you haven't bought yourself a team. You've bought yourself a queue.

Start with one agent, one bounded ticket, one provable definition of done. Get the triage loop working at depth one before you fan out to four. The generation was never going to be the hard part.