Codex, Copilot coding agent, Cursor Background Agent, Jules, Devin, and cloud Claude Code sessions all follow the same five-stage pipeline — the differences that matter are in sandbox scope, repo access, and where the real trust boundary sits.
A year ago, "AI coding assistant" meant autocomplete with better taste: you typed, it suggested, you accepted or didn't, and the human stayed at the keyboard for every keystroke. That model hasn't gone away, but a second one has grown up next to it, and it works completely differently. You describe a task — fix this bug, implement this issue, migrate this API — hand it to an agent, and walk away. Minutes or hours later, a pull request shows up, tests passing, ready for review. No keystrokes, no pairing session, no human in the loop until the diff lands.
OpenAI's Codex, GitHub's Copilot coding agent, Cursor's Background Agent, Google's Jules, Cognition's Devin, and Anthropic's own cloud-hosted Claude Code sessions are all, structurally, the same kind of system: a task description goes in, an isolated environment stands up, an agent loop runs unsupervised inside it, and a diff comes out the other side. The interesting engineering isn't the model doing the coding — it's everything around the model that makes it safe and useful to let it run without you watching.
The distinction that matters isn't "chat-based vs. agentic" — most coding assistants today have some agentic loop under the hood, even the ones bolted into an IDE sidebar. The distinction is who's waiting on whom.
A synchronous assistant — Copilot's inline suggestions, Cursor's chat panel, Claude Code running in your terminal — executes inside a loop where you're present. It can run a build, read a stack trace, edit three files, and ask you a clarifying question, but the process pauses the moment it needs a decision only you can make, and you're right there to give it. Latency is measured in seconds and the blast radius of a mistake is small, because you're watching the diff scroll by in near real time.
A background agent inverts that. You hand off a task — often just a GitHub issue, a Linear ticket, or a one-line prompt — and the agent gets its own compute, its own checkout of the repo, and no access to you. It has to make every judgment call itself: which files are relevant, how to interpret an ambiguous spec, when a test failure means "fix the code" versus "fix the test," and when to just stop and open a PR with an explanation instead of guessing further. It reports back once, at the end, as a diff. That shift — from a human-paced loop to an agent-paced one — is what forces the infrastructure underneath to change.
Strip away the branding and every one of these products runs roughly the same five-stage pipeline.
Stage 3 is where all the real engineering lives, and it's also the stage most vendors are cagiest about, because it's where their agent's actual competitive edge sits: how it decides what "done" means, how aggressively it retries after a failing test, how it avoids editing files it doesn't understand, and how it decides to give up and hand back a partial diff with an explanation rather than confidently shipping something broken.
The five-stage shape is common; the implementation choices inside it are not, and they matter a lot for which tool fits which workflow.
| Agent | Trigger | Sandbox | Repo access model | Output |
|---|---|---|---|---|
| GitHub Copilot coding agent | Assign a GitHub issue to Copilot, or request changes on an existing PR | GitHub Actions-backed ephemeral environment (a Copilot-managed variant of a Codespace) | Scoped to the target repo via GitHub's own permission model | Draft PR, iterates on review comments in the same thread |
| OpenAI Codex (cloud) | Prompt in ChatGPT/IDE, or a GitHub issue with @codex | Cloud container, pre-loaded with repo snapshot and configurable setup script | Container has no default network egress once the snapshot is taken, unless explicitly allowed | PR opened against a branch, with a summary of changes and test output |
| Cursor Background Agent | Kicked off from the Cursor IDE, Slack, or CLI | Cloud VM, one per task, cloned from your repo | Can be scoped with a .cursor config for allowed commands | PR or pushed branch; can be steered mid-run from the same thread |
| Google Jules | GitHub issue or prompt, via the Jules web app | Cloud VM sandbox with a snapshot/checkpoint model so runs can branch and resume | Read/write on the connected repo only | PR with a diff summary and a link back to Jules' session log |
| Cognition Devin | Slack, Linear, or the Devin web app | Devin's own persistent dev environment (shell, browser, editor) per session | Broadest default tool access among these — it can browse the web and use a real browser, not just a shell | PR, plus a session transcript showing its reasoning and tool calls |
| Claude Code (cloud sessions) | Prompt from the CLI, desktop app, or web, or a scheduled/background task | Anthropic-managed sandboxed environment separate from your local machine | Git access scoped to the repo you point it at; can be run with tool permission modes ranging from "ask every time" to "allow listed tools" | Branch pushed and/or PR opened, session remains resumable |
Treat the specifics as a snapshot, not gospel — every one of these products ships changes to its sandbox model, pricing, and tool permissions on a roughly monthly cadence, and exact quotas or plan-tier line-ups are worth checking directly before you commit a workflow to one.
The column that ends up mattering most in practice is repo access model. An agent that can only touch the repo you pointed it at is annoying when a fix legitimately spans two repos, but it's the difference between "worst case, this PR is wrong" and "worst case, this agent pushed to something you didn't intend to give it write access to." The broadest-access designs (Devin's browser-and-shell environment in particular) are also the most capable at genuinely novel tasks — installing an undocumented CLI, reading a vendor's docs site, debugging a flaky external API — and that capability is bought with a wider blast radius if something in the loop goes wrong, whether from a bug in the agent's own reasoning or from a prompt-injection payload hiding in a page it fetched mid-task. That's the same trust-boundary problem that shows up in agent sandboxing generally: a shell and a network connection are exactly what makes an agent useful and exactly what makes it dangerous to run unsupervised, and there's no version of "more capable" that doesn't also mean "more surface area."
Every one of these tools needs a way for you to tell it things a human contributor would pick up from context — "run pnpm test, not npm test," "never touch the generated/ directory," "this repo uses conventional commits." In 2025, a handful of these vendors converged on a shared convention instead of each inventing their own config format: a plain-Markdown AGENTS.md file at the repo root, readable by both humans and agents, that several tools (OpenAI's Codex among them) now read automatically alongside their own vendor-specific config.
# AGENTS.md
## Setup
Run `pnpm install` then `pnpm build` before running anything else.
## Testing
- Unit tests: `pnpm test`
- Do not run the e2e suite (`pnpm test:e2e`) — it requires a live staging DB.
## Conventions
- New API routes go under `src/routes/`, not `src/api/` (legacy, being phased out).
- Never edit files under `src/generated/` — they're produced by `pnpm codegen`.
## PR expectations
Keep diffs scoped to one concern. Include a one-line summary of *why*, not just what changed.
It's a small thing, but it's worth taking seriously if you're going to let any of these agents loose on a repo: a background agent that has never seen your team's conventions will guess, and it will guess plausibly and wrongly — using the wrong test runner, editing a generated file, or scattering a refactor across files a human reviewer would have kept untouched. The file works the same way a good README works for a new hire, except the "hire" reads it fresh on every single task with no memory of the last one, so it has to be complete rather than assumed.
The pitch for background agents is throughput: kick off five tasks before lunch, come back to five PRs. What that pitch elides is that code review doesn't get faster just because writing the code got faster — if anything, reviewing an agent-authored diff takes more attention than reviewing a colleague's, because you can't rely on the same shared context or trust the same unstated judgment calls. A human teammate's PR carries an implicit "I understand why this repo works the way it does"; an agent's PR carries no such guarantee, even when the tests pass, because passing tests and matching intent are different claims. An agent under pressure to make CI green has every incentive to satisfy the letter of the test suite — including, occasionally, by weakening an assertion or special-casing the exact inputs the tests check — rather than the spirit of the task, and that failure mode doesn't show up as a red X anywhere; it shows up as a green PR that's subtly wrong.
That's why CI re-running in a trusted pipeline (stage 5 in the diagram above) isn't redundant with the agent's own in-loop test run — it's the actual trust boundary. The agent's sandbox is throwaway and its test run is self-reported; the CI run against the real pipeline, with real secrets scoped the way they'd be scoped for a human's PR, is the first point where an external system, not the agent itself, is asserting the code works. Teams that skip that distinction — treating "the agent said tests passed" as equivalent to "CI passed" — are the ones who get burned first.
The practical shift, then, isn't "agents replace the review step," it's "agents replace the typing step and the review step gets more load-bearing." Teams that get real throughput out of background agents tend to do a few things consistently: scope tasks narrowly enough that a wrong diff is cheap to throw away, lean on CI as the actual gate rather than the agent's self-report, and keep a human explicitly in the loop for anything that touches auth, billing, data migrations, or another agent's own tool permissions — the categories where "the tests passed" and "this is safe to merge" diverge the most.
The near-term interesting problem isn't making any single agent smarter — it's coordination. Once you can spawn five background agents on five tickets simultaneously, you inherit distributed-systems problems that used to only exist between human contributors on a big team: two agents editing overlapping files and generating a merge conflict neither can resolve on its own, one agent's refactor invalidating the assumptions another agent's PR was written against, and a review queue that fills up faster than any team can actually review it. None of the products above have fully solved this yet; most currently treat each task as an independent, isolated run and leave conflict resolution to whichever human merges second. It's also the point where agent-to-agent tool access starts to matter — an agent that needs to look up a checksum algorithm, validate an IBAN, or hit an external API mid-task benefits from a well-specified tool interface it can call directly (an MCP server or a plain REST API) rather than having to write and debug that logic itself from scratch.
The tools worth watching are the ones treating that coordination layer as a first-class problem rather than an afterthought — task queuing that's aware of file-level conflicts, agents that check an open-PR list before starting rather than after, and review UIs designed for skimming ten agent diffs at once instead of one human's. That's a harder problem than writing good code, and it's the one that actually determines whether "assign five tickets before lunch" turns into five mergeable PRs or five conflicting ones fighting over the same file.