What is a background coding agent? AI coding agents that open pull requests, explained

A background coding agent is an AI coding agent that works without you. You hand it a task. It implements the change in an isolated cloud environment, runs your checks, verifies the result in a real browser, and opens a pull request. Your involvement is the task going in and the review coming out.

This writeup is based on operating one. Over two weeks in July 2026, FactoryKit, our background coding agent platform, shipped 180+ features across three production products: itself, Hashnode, and Bug0. Somewhere in the middle of that stretch I stopped opening a local development environment. The numbers in this post come from those runs, not from benchmarks.

If you are evaluating this category, you probably arrived with some version of these questions:

• How is a background coding agent different from Copilot or Cursor?
• Can I trust a pull request no human wrote?
• What does one of these agents actually do for 20 minutes at a time?
• Should we build our own, the way Ramp and Uber did, or buy one?
• Which background coding agents exist today?

What follows is my attempt to answer them.

What a background coding agent is (and is not)

Autocomplete helps you type. An IDE agent helps you drive. A background coding agent works while you do something else. The difference is not the model. It is where the loop runs and who closes it.

There have been three generations of AI coding tools, and they get conflated constantly.

Generation	Where it runs	Who closes the loop	Examples
Autocomplete	Your editor	You, every few seconds	GitHub Copilot (2021)
IDE and terminal agents	Your machine	You, every few minutes	Cursor, Claude Code, Codex CLI
Background coding agents	A cloud sandbox	The pull request review	Devin, Codex cloud, Jules, FactoryKit

Three generations of AI coding tools. Each one moves the human further from the keystroke.

The models across these generations are often the same. Claude and GPT power tools in all three rows. What changes is the harness: how much of the loop the tool owns before a human needs to look. Agentic coding, as a practice, is the progression down this table.

An IDE agent is synchronous. It works, you watch, you interrupt. A background coding agent is asynchronous: the unit of work is a task, and the unit of output is a pull request. Nothing in between requires you. You will also see them called autonomous coding agents or cloud coding agents; the category is young enough that the name has not settled.

Here is what the input side looks like in FactoryKit. You pick the repos (one task can span several), pick the agent, and describe the change:

A task in FactoryKit: pick repos, pick the agent, describe the change. This is the entire input.

That agent picker is a detail I want to flag early because it surprises people: the coding agent (Claude Code, Codex, or Grok Build) is a per-task choice, not a platform commitment. Different agents have different strengths, and the factory does not care which one worked the line on a given task.

The pull request is the approval gate

Background agents do not remove code review. They move all of it to the pull request. That only works if the PR carries evidence, not just a diff.

Every background agent on the market "raises PRs". The phrase hides the question that matters: what arrives with the PR?

A diff alone shifts work onto the reviewer. Now you are reading machine-written code cold, wondering whether it even runs. The version of this that works is what I call an evidence-backed PR: a pull request that arrives with its own proof. The checks it passed. A self-review of the diff. And a recording of the change working in a real browser.

Here is one from a real run:

The QA recording attached to PR #58. The agent drives the app in a browser inside the sandbox; the recording ships with the pull request.

And here is how it lands in the repo:

One PR per changed repo. The evidence is in the PR body, where the reviewer already is.

I will not pretend evidence closes every gap. A recording proves the feature works; it does not prove the feature is what you meant, or that the approach fits your architecture. Review still catches intent and design. What the evidence removes is the cheapest and most common reason to distrust an agent PR: "does this even work?"

How a background coding agent works

Under the hood it is a pipeline: sandbox, clone, implement, check, fix, review, record, ship.

When a task starts in FactoryKit, a fresh isolated sandbox is provisioned in the cloud. The repos are cloned into it. The agent reads the codebase, implements the change, and then runs each repo's own checks: lint, types, tests, whatever the repo defines. If a check fails, it gets a bounded number of attempts to fix it (we allow 3). Then it reviews its own diff, and QAs the change by running the app and driving it in a browser, recorded. Only after all of that does the platform commit the work, push a branch, and open the pull request.

The run lifecycle. One structural detail matters more than the rest: the agent never touches git. It edits a working tree. The platform ships.

The agent cannot push, force-push, rewrite history, or open PRs. It produces a working tree; the host commits and ships it. Whatever the model does on a bad day, the blast radius is a directory.

Here is what a run looks like while it is happening:

Watching a run: the agent narrates while it works. Tool calls are intentionally hidden. The narration is the log a reviewer actually reads.

From our own runs across the three products:

Task complexity	Typical duration
Simple	~5 minutes
Moderate	10 to 15 minutes
Complex	20 to 30 minutes

A task can run up to five hours before we call it. Most of the time you are not watching any of this. You find out when the PR arrives.

Credentials are the question every security review of this category starts with, so here is the exact mechanism. The agent inside the sandbox holds a placeholder credential. When it makes a request to GitHub or to a model gateway, a network firewall swaps the placeholder for the real token in transit, and each token is scoped to the one repo it is for.

FactoryKit's platform credentials (model gateway keys, GitHub tokens) are injected in transit and never exist inside the sandbox. Environment variables your app needs to run do go into the sandbox, because your app cannot boot without them.

Who builds background coding agents in 2026

The strongest proof this category is real: Ramp and Uber each built one in-house before you could buy one.

Ramp built Inspect, a background agent wired into their Linear workflow, running each session in a sandboxed VM. Their engineering post reports that "~30% of all pull requests merged to our frontend and backend repos are written by Inspect", a couple of months after adoption started. Uber runs agents against its monorepo at platform scale; per The Pragmatic Engineer's March 10, 2026 report, 92% of Uber developers use agents monthly and 11% of pull requests are opened by agents.

Both companies put platform engineers on sandboxing, credential handling, and review workflows before the first useful PR came out. In 2026 you can also skip that and buy one:

• Devin (Cognition): the earliest widely known background agent, runs parallel sessions in its own cloud VMs.
• OpenAI Codex: cloud tasks tied to a ChatGPT subscription, delegated from the Codex interface.
• Google Jules: clones your GitHub repo into a Google Cloud VM and opens PRs, with a free tier.
• GitHub Copilot coding agent: assign a GitHub issue to Copilot and it drafts the PR, native to GitHub.
• Cursor background agents: async runs launched from the Cursor editor.
• FactoryKit: the one we build. Multi-repo tasks, your choice of coding agent per task, and evidence-backed PRs with recorded browser QA.

Agent	Runs in	You trigger it from	Known for
Devin	Its own cloud VMs	Devin's web app	Earliest mover, parallel sessions
OpenAI Codex	OpenAI's cloud	ChatGPT / the Codex interface	Ties into a ChatGPT subscription
Google Jules	A Google Cloud VM	jules.google	Free tier
Copilot coding agent	GitHub Actions	Assigning a GitHub issue	GitHub-native
Cursor background agents	Cursor's cloud	The Cursor editor	Hand-off from the IDE
FactoryKit	An isolated sandbox per task	The web app	Multi-repo tasks, agent choice, evidence-backed PRs

These tools differ in real ways (where they run, what they verify, what they cost), and a serious comparison deserves its own post. The one-line version: they all raise PRs; they differ in how much you can trust one without re-doing the work.

What two weeks of running one looks like

Over two weeks in July 2026, FactoryKit shipped 180+ features across three production products. I stopped opening my local dev environment.

FactoryKit is built by a small team, and it builds itself: most changes to FactoryKit are FactoryKit tasks. Our git history reads like a task log because it is one. PR #58 in the FactoryKit repo is the task "The billing page title is wrong. It says FactoryKit twice", merged from a branch named factory/the-billing-page-title-is-wrong-it-says--b06169. Nobody wrote a commit message. The task was the commit message.

The same factory runs day-to-day development on Hashnode and Bug0, which are production applications with real users, not demo repos. Across the three, the two weeks ending July 26, 2026 produced 180+ shipped features.

Recent tasks in the dashboard. Each row ends the same way: a pull request.

My own workflow change was not planned; it just happened. Tasks go in from wherever I am. PRs come back with evidence. Review happens in GitHub, follow-ups are messages on the same task, and the follow-up commits stack onto the same PR. At some point during those two weeks I noticed I had not opened a local dev environment at all, and I have not since.

Where it works and where it does not. Standard web applications are the sweet spot: the browser QA loop assumes the change can be exercised in a browser. Mobile apps are not supported. And some tasks come back wrong the first time; the fix is a follow-up message, not a rewrite, and the conversation stays attached to the PR.

A background coding agent is the unit of an AI software factory

One agent is a tool. A fleet with checks and an approval gate is a factory.

The tools in this post get discussed one agent at a time. The teams getting real throughput run many in parallel, against the same repos, with the same checks, and one gate at the end. That is a production line, and a background coding agent is its unit.

The factory shape: the agents work the line, the PR gate stays human.

Ramp and Uber built this shape in-house because nothing purchasable existed at the time. That window is closing. The interesting question for most teams in 2026 is no longer whether the factory shape works. It is whether building one is a better use of your platform engineers than plugging one in. That question deserves its own post, with the math written out.

FAQ

What is a background coding agent? An AI coding agent that works asynchronously: you assign a task, it implements the change in an isolated cloud sandbox, runs the repo's checks, verifies the result, and opens a pull request for human review. You are not in the loop between task and PR.

How is a background coding agent different from a copilot? A copilot assists while you write code: it suggests, you accept, dozens of times an hour. A background coding agent replaces the writing session entirely and moves human involvement to the pull request. The practical test: close your laptop. If the work stops, it is not a background agent.

Are background coding agents safe to run on production repos? The mechanisms that make them safe are isolation and scope, not model behavior. In FactoryKit, each task runs in a fresh sandbox, the agent never has git access, platform credentials are injected in transit rather than stored in the sandbox, and every token is scoped to a single repo. Nothing merges without a human approving the PR.

How long does a background coding agent take per task? From our runs: ~5 minutes for simple tasks, 10 to 15 for moderate ones, 20 to 30 for complex ones. Tasks can run up to five hours before timing out.

Which background coding agents exist in 2026? Devin (Cognition), OpenAI Codex cloud tasks, Google Jules, GitHub Copilot coding agent, Cursor background agents, and FactoryKit. Ramp's Inspect and Uber's internal agents are the best-known in-house builds.

---

The fastest way to understand this category is to watch a task you wrote come back as a PR with a recording attached. Get your first task done right away.