What are the best AI coding agents in 2026 for real repos?

I do not rank coding agents by how they complete a line in the editor. That product exists. It is autocomplete.

A coding agent is something else: you give it a job in a real repository, it uses tools, and it comes back with a branch you can review. If the output is only more chat, you still have a chatbot. I wrote what is a coding agent as the definition this list assumes.

Anthropic’s Building effective agents (19 December 2024) is blunt about why code is a good agent job: solutions are verifiable through automated tests, and the agent can iterate on those results. Pretty traces that miss the pull request are zeros. I score agents the same way I score any other worker in how to evaluate AI agents.

A coding agent is software you can give a job in a real repository. It should open a reviewable pull request, run inside a sandbox you did not invent, and iterate on the test suite you already have. I score those three and I do not score tab-complete.

How I score a coding agent

I grade an agent the way I grade a contractor: a clean pull request, an isolated environment, and tests it actually ran and then fixed. SWE-bench is a public exam on other people’s GitHub issues. The hire test is whether it can iterate on the suite you already ship.

Pull request hygiene is the first filter: a draft or reviewable PR, readable commits, a description that states what changed, and a path for comments to reach the same worker. A zip in chat is not a PR, and a force-push onto main is not hygiene. GitHub’s Copilot docs (2026) put the work on a branch you inspect, then let you open the pull request when you are ready.

Sandbox is the second filter. The model should not own your laptop, and every product on this list documents an isolation layer: a GitHub Actions VM, a cloud container, Seatbelt or bubblewrap, a vendor VM, or Docker. NIST’s AI Risk Management Framework (2023) puts measure before manage: an agent you cannot contain is not a production worker.

Tests are the third filter. Anthropic’s December 2024 essay names the mechanism: the agent edits, the suite speaks, the agent continues. If the product cannot run your build and your tests, it is guessing, and I do not care how fluent the commit message is if CI never ran.

SWE-bench is useful and it is not your repo. Jimenez and colleagues introduced it at ICLR 2024 as 2,294 GitHub issues from 12 Python repositories; in that paper Claude 2 resolved 1.96 percent of issues. SWE-bench Verified (August 2024) is 500 engineer-confirmed tasks; read swebench.com with the date on the page.

The eight, ranked

These eight products can take a job in a git repo and come back with a branch or a pull request. I put GitHub Copilot coding agent first on GitHub-hosted work. The rest follow on sandbox strength and whether tests are part of the loop.

I am ranking the agent, not the underlying model. Several of these products let you pick a model, but the loop is the product: where it runs, how it opens a PR, whether it can execute the suite.

YouTube

Open original

GitHub demoed the same end-to-end Copilot loop on 26 Aug 2025.

I left autocomplete off on purpose. Copilot in the editor, Cursor Tab, and Amazon Q inline suggestions are useful, and they are not this job. After you pick a product, how to run a coding agent in your repo is the desk procedure.

1. GitHub Copilot coding agent

GitHub Copilot coding agent sits on the pull request, which is where the work already lives. GitHub’s 2026 docs call the background worker Copilot cloud agent. It researches a repository, writes a plan, edits a branch, and lets you open the pull request when you are ready.

GitHub’s Copilot docs (2026) describe an ephemeral development environment powered by GitHub Actions. In that environment the agent can explore the code, make changes, and execute automated tests and linters. That is the loop I want: the suite runs where the change is made, not later on your laptop after you have already argued with the diff.

GitHub’s May 2025 Copilot coding agent blog is still the cleanest picture of PR hygiene. Assigning an issue always opens a draft pull request from a GitHub Actions VM. Starting from a prompt can stay on a branch until you create the PR, session logs stay on the run, branch protections still apply, and those pull requests require human approval before CI/CD workflows run.

Sandboxing is documented in two layers. Copilot cloud agent runs in the Actions environment, while Copilot CLI, in public preview per GitHub’s Copilot CLI docs (2026), adds local sandboxing (Seatbelt, bubblewrap, or ProcessContainer) and cloud sandboxing on Azure Container Apps. Local sandboxing is off until you enable it, and until then CLI commands run as you.

GitHub enables the GitHub MCP server and the Playwright MCP server by default for the cloud agent and for Copilot code review, which is how the agent reads issues and can drive a browser for checks. Put build and test steps in custom instructions. The documented hard limit is a 59-minute session, so keep it to one task, one branch, one PR.

I put it first because the artifact is already a GitHub pull request, the sandbox is already Actions, and tests are already in the documented loop. It only works on repositories hosted on GitHub.

• Assign an issue, use the agents panel, or mention @copilot on a PR.
• Assigning an issue always opens a PR. Starting from a prompt can stay on a branch until you create the PR. Either way it is a GitHub Actions VM.
• Put build and test steps in custom instructions so the Actions environment is not guessing.

2. OpenAI Codex

OpenAI Codex is the coding agent you can run in the cloud, in the CLI, and in the IDE. Codex cloud (OpenAI, 2026) gives each task an isolated environment. You review a summary and a diff, then open a pull request when the work is ready, which is PR hygiene with a human still holding merge.

The cloud path is built for parallel work. You connect GitHub or GitLab, create an environment with the dependencies and setup steps the repo needs, and start tasks from the web, from GitHub, from Linear, or from Slack. You are not pairing in a local window for every job; you come back to a diff.

The local path is explicit about sandbox modes. OpenAI’s Codex CLI docs (2026) describe read-only, workspace-write, and danger-full-access, with Seatbelt on macOS, bubblewrap on Linux, and the native Windows sandbox in PowerShell. Default on an untrusted directory is read-only, which is the right default.

On GitHub, @codex review posts a code review, and any other @codex instruction starts a cloud task using the pull request as context. OpenAI’s docs tell you to put review guidance in AGENTS.md, including missing tests. The Codex GitHub Action can run `codex exec` in CI; keep it on workspace-write, not danger-full-access, unless the job is already inside a dedicated VM.

I rank Codex second because the cloud container, the local OS sandbox, and the GitHub review loop are all documented. You still have to configure the environment so tests actually run.

• Create a cloud environment per repo. Put the install and test commands there.
• Keep AGENTS.md next to the code. Review guidelines belong in the tree.
• Use workspace-write for unattended local work. Avoid bypassing approvals outside a VM.

3. Claude Code

Claude Code is Anthropic’s agentic coding tool in the terminal, on the desktop, on the web, and in GitHub Actions. It understands the repo, runs git workflows, and can turn an issue comment into commits. The product is the loop, not a completion box.

Claude Code’s Bash sandbox is a first-class tool: Seatbelt on macOS, bubblewrap plus socat on Linux and WSL2, no native Windows sandbox. Claude Code itself runs on Windows, so for OS isolation you use WSL2 or a container. Writes stay in the working directory and session temp by default, network goes through an allowlist, and I refuse unsandboxed retries in a managed shop.

PR hygiene is covered in three places. Claude Code on the web (Anthropic, 2026) pushes a branch, lets you review the diff, and can open a full PR or a draft, while Claude Code GitHub Actions responds to @claude, implements changes, and pushes commits. The February 2026 Anthropic blog describes PR monitoring and auto-fix on CI failures; auto-merge is a grant I leave off until the score holds.

Put project rules in CLAUDE.md. Anthropic’s GitHub Actions docs say Claude follows that file when it creates PRs, which is how you tell it the test command and the files it must not touch. Skills can add a review pass that posts inline comments.

I rank Claude Code third because the OS sandbox is documented in depth and the GitHub Action is a real runner, not a sidecar chat. Local power is also the risk: if sandboxing cannot start, the default is a warning and unsandboxed commands. Set fail-if-unavailable in managed settings if you require the boundary.

• Run /sandbox in the repo and keep auto-allow only after you have seen the Config tab.
• Install the GitHub Action with /install-github-app, or copy the workflow by hand.
• Keep auto-merge off until a frozen set of jobs is boring.

4. Cursor Cloud Agents

Cursor Cloud Agents (Cursor docs, 2026) run on a dedicated virtual machine with a full desktop. They can edit, run commands, click through a browser, and open a pull request. Background agents in the older docs are the same idea: move the long job off your laptop and come back to proof.

PR hygiene is stronger than a branch dump. Cursor’s capabilities page says agents attach screenshots, videos, and log references so you can validate without checking out the branch, and you can opt in to posting those artifacts on the GitHub pull request. I still read the diff, because a video of a happy path is not a unit test.

Tests show up in two ways. Computer use lets the agent start the dev server and click the UI it built. Cursor’s 2026 docs also have the cloud agent retry GitHub Actions on PRs it created, with caps (human commit, follow-up, base already failing, or ten CI follow-ups), and you can comment `@cursor autofix off`.

Sandboxing is local and remote. Cloud agents are isolated VMs with network policy, and locally Cursor documents sandbox.json plus OS sandboxes on macOS, Linux, and Windows (February 2026 research post). Subscriptions let a cloud agent wait on PR comments or CI and continue in the same thread.

I rank Cursor fourth. The VM and the PR artifacts are real, and CI follow-up is documented, but tests are a browser pass plus Actions retry, not your suite as the default loop.

• Commit .cursor/environment.json so the VM can install and boot the same way twice.
• Turn on artifact posting only if you accept public, unguessable URLs for images on GitHub.
• Tell the agent to keep the PR green until merge. That is not merge rights.

5. Devin

Devin is Cognition’s AI software engineer. Official docs (2026) split Ask mode, which explores and plans without editing, from Agent mode, which writes code, runs commands, browses, and creates pull requests. I start in Ask unless the job is already a ticket with a finish line.

The environment is a persistent snapshot, and each session boots a fresh copy of it. Repo setup is the unglamorous work: tools, secrets, the right branch. If the snapshot cannot run the tests, Agent mode will spend the session installing, so do that once, then give it the job.

PR hygiene is in the product, not an afterthought. Devin’s testing docs (2026) describe a testing mode after the PR exists: install, start services, plan from the diff, record a video, and send you the file, which I treat as evidence, not as a substitute for the suite. Playbooks can require `npm test` before the PR; do not use the “quick PR” playbook that tells Devin not to run tests on production code.

Devin Review posts on GitHub and GitLab, with auto-review when a PR opens and optional auto-fix that pushes commits to the PR branch. The CLI has a `--sandbox` flag for OS-level isolation and optional domain filtering. Docs say Windows does not support that OS sandbox, so the CLI refuses to start rather than run unsandboxed, which is the correct fail-closed behavior.

I rank Devin fifth. The vendor machine, the PR, and the test-plus-video loop are documented, and you pay for a setup that looks like a hire: index the repo, snapshot the environment, write playbooks. If you skip that, you hired a contractor and hid the build from them.

• Index the repo and finish environment setup before the first real ticket.
• Write a playbook that names the test command. Attach it to the session.
• Review the PR with Devin Review, then read it yourself. Two passes, one merge grant.

6. Google Jules

Jules is Google’s experimental coding agent. The getting started docs (2026) say it integrates with GitHub, clones your code in a virtual machine, installs dependencies, and modifies files. You write a prompt, it writes a plan, and you approve the plan before it edits, which is PR hygiene at the start of the job, not only at the end.

When the task completes, Jules summarizes files changed, runtime, and the branch, then you publish the branch or the PR, with Jules as commit author and, on a published PR, as the PR creator. From GitHub, a `jules` label on an issue starts a task if the GitHub app can see the repo, and Jules comments with a link to the pull request when it finishes.

The API makes the same loop scriptable. `automationMode: AUTO_CREATE_PR` opens the pull request when the session ends, but the default is no automatic PR, which you should keep until you trust the plan step. Jules also reads AGENTS.md at the repo root, so put the test command there; the getting started example is a test for a function, which is the right first job.

Sandbox is the cloud VM, so you do not run Jules as your local user. Environment setup scripts are optional and they matter, because if the VM cannot install the toolchain the plan will still look confident.

I rank Jules sixth. The cloud VM and the GitHub PR path are documented. Tests are still something you ask for, not something the product runs as the loop.

• Connect only the repos Jules should see. The selector is a grant.
• Approve the plan. If the plan skips tests, send it back.
• Keep AGENTS.md current so the VM is not discovering your stack from scratch.

7. Amazon Q Developer

Amazon Q Developer for GitHub is in preview. AWS docs (2026) describe two agents on the pull request: the development agent implements a feature or a fix from an issue and opens a PR with a summary, and the code review agent comments when a PR is opened or reopened, with threaded findings and suggested fixes you can commit.

You start feature work by adding the label `Amazon Q development agent` or by commenting `/q dev` on the issue; `/q review` starts a review. Automatic reviews do not re-run on later commits unless you ask, which is a gap, because a follow-up commit can break the suite. Comment `/q review` again after the agent pushes.

Sandboxing for the GitHub app is less spelled out than Copilot’s Actions VM. For the IDE feature-development agent, AWS described isolated execution in January 2025: a managed sandbox or a customer Docker image, driven by a Devfile, with no credentials for non-public internet. I still want that Devfile thinking on the GitHub path: tell the agent how the repo builds, or it will invent a path.

In the IDE, Amazon Q also ships `/test` for unit tests and `/review` for quality findings (AWS News Blog, December 2024). Those are useful, and they are not this ranking by themselves. I am ranking the GitHub development agent because it returns a pull request.

I rank Amazon Q seventh. Issue-to-PR is the right shape, and the review agent lives on the same host, but the GitHub-path sandbox is thinner than Copilot’s Actions VM, and `/test` lives in the IDE, not in the PR loop. Data for the GitHub integration is processed in the United States per the 2026 user guide, so if that is a blocker, stop here.

• Install the GitHub App for selected repos, not the whole org, until the preview earns it.
• Write issues the way you would write a ticket for a contractor: finish line, files, tests.
• Re-run /q review after new commits. Do not assume the first pass still holds.

8. OpenHands

OpenHands is the open-source agent I put on this list because the sandbox is the product. Docs (2026) run agents in Docker, on a remote agent server, or on OpenHands Cloud, and the Cloud API returns a sandbox id you can see. You can host the boundary yourself.

PR hygiene on GitHub is a label and a mention. Give the Cloud app access to the repo, then label an issue `openhands` or comment `@openhands`; it comments that it is working, opens a pull request if it decides the issue is resolved, and comments again with a summary and a link. Permissions are short-lived tokens, eight hours, with contents and pull requests read and write.

Tests are yours. OpenHands does not pretend to know your suite, so you put the commands in the workspace, in a skill, or in the prompt.

The October 2024 OpenHands resolver post described a GitHub Action that attempted issues labeled `fix-me` and opened a PR or reported failure. I still freeze a task set and score the PR.

I rank OpenHands eighth among these eight. Docker or Cloud is a real sandbox and the labeled issue opens a PR. You bring the test command, so that is a complete loop only after you wire it.

• Start with DockerWorkspace or Cloud so the agent is not editing your host checkout.
• Connect one repository. Label one issue. Read the PR before you give it the backlog.
• Pass the test command in the initial message until you have a skill that always runs it.

What I left off this list

I left off products that complete lines, chat about a file, or run an agent without a sandbox I can name. Tab-complete is not a coding agent, and a plan mode that never opens a pull request is not a coding agent. A research demo that only reports SWE-bench is not a worker on your desk.

Windsurf Cascade can edit files and run terminal commands in the IDE, with allow and deny lists. That is an in-editor agent whose documented loop is the workspace, not an isolated VM that returns a PR.

Aider is tightly integrated with git, auto-lint, and `--test-cmd`, and it runs on your machine unless you wrap it. I use it as a local pair, not as Copilot’s Actions VM.

SWE-agent, from the Princeton group behind SWE-bench, still exists, and the project now points people at mini-SWE-agent, which clones a GitHub repo into a sandbox and tries to close an issue. That is research infrastructure. If you are merging to production, use a product with PR review and a stop rule your org can operate.

I also left off anything I could not pin to official docs for pull requests, sandbox, and tests. If a vendor only publishes a homepage, it does not go on this list. I can describe a mechanism without a number, and I will not invent a review.

Pick one for your repo

Pick the agent that already speaks your host. GitHub-hosted work starts with Copilot coding agent. A ChatGPT shop starts with Codex, a Claude shop starts with Claude Code, and OpenHands is the sandbox you host when a vendor VM is not allowed.

Cursor, Devin, and Jules are right when you want a vendor VM and a pull request waiting when you return. Amazon Q is the AWS-shaped version of issue-to-PR. Do not pick two on day one: pick one, freeze ten jobs, and keep merge as a human grant.

Then run a small eval. Ten issues you already closed, replayed cold, with the same finish line: tests green, draft PR, description a reviewer can use. Log every tool call and compare against last week’s agent; pretty traces that miss the file are zeros.

1. 01

   Write the finish line

   Name the artifact: draft pull request, suite green, description that lists the tests run. If a script cannot see it, a person will stay in the loop.

2. 02

   Lock the sandbox

   Vendor VM, Actions runner, Docker, Seatbelt, bubblewrap. If the product can run unsandboxed by default, change the default first.

3. 03

   Point it at the existing test command

   Put the command in AGENTS.md, CLAUDE.md, custom instructions, a Devfile, or a playbook. Do not let the agent invent the flags.

4. 04

   Score the pull request

   Freeze ten jobs. Count merges, review comments, and CI fails. Promote the agent on that score, not on a demo.

5. 05

   Keep merge as a human grant

   Draft is not merge. Branch is not production. Auto-merge stays off until the week is boring.

Most teams fail this in the same three ways: they buy autocomplete and call it an agent, they skip the sandbox, and they never run the suite. The fix is dull: write done, contain the run, score the PR. I wrote how to run a coding agent in your repo as the desk version.