Agentcode

What can an autonomous coding agent actually do?

Jul 20, 2026 · 10 min read · By Devin Roydon, Engineering

An autonomous coding agent reads your repository, plans a multi-step change, edits the files that need to change, runs your tests, reads the failures, and iterates until the task is done or it needs a human. That loop is the whole difference between an agent and autocomplete: instead of suggesting the next line, it takes a goal and delivers a working implementation. What it does not do, if it is built responsibly, is merge that work on its own. The autonomy runs right up to the pull request and stops there, because the last decision belongs to a person.

The loop, in three phases

Every production-grade agent runs some version of the same cycle. Knowing it makes the category far less mysterious:

  1. Context ingestion. The agent reads the relevant parts of your repo, the structure, the existing patterns, the dependencies, and the code around the change, so its output fits how your team already builds rather than inventing a new style.
  2. Generation with test-driven iteration. It plans the change, edits the files, runs your tests, reads the failures, and corrects itself. This is the part that separates an agent from a chat window: it does not stop at the first draft.
  3. Pull request and CI. When the change is done and the tests pass, it opens a pull request so your normal review and continuous integration take over.

The shift that defined 2026 was the move from single-prompt answers to long-running execution loops. An AI coding agent now plans, acts, checks its own work, and keeps going, which is why it can finish a whole feature before you look at the first diff.

What it does well today

Autonomy pays off where the task is bounded and the result is checkable:

  • Whole features from a clear spec. Add a field end to end, build a documented endpoint, wire up an integration against a third-party API.
  • Bug fixes with a reproduction. Given a failing test or a clear repro, an agent can localize the fault, fix it, and prove the fix with a green suite.
  • Test backfill. Writing the tests for code that shipped without them, so you can change it later without fear.
  • Large mechanical migrations. The same change across dozens of files, where consistency matters more than creativity and a human is slow because it is tedious.

The pattern is that the agent is strong when success is defined and verifiable. Give it a target it can test against and it will use that target instead of guessing.

Agent vs autocomplete vs chat

The words get used loosely, so it helps to pin the difference to what each tool actually produces:

Tool typeUnit of workRuns your testsOpens a PR
AutocompleteThe next line or blockNoNo
Chat assistantA snippet on requestNoNo
Autonomous coding agentA whole feature or fixYesYes

Autocomplete and chat make an individual developer faster at typing. An agent changes what the developer does: instead of writing every line, you specify the outcome and review the result. That is a different job, and it is why an agent is worth the extra trust it asks for and the review gate it needs.

What it should not touch on its own

The limits are the same ones that make software hard for people, and no amount of model scale has moved them:

  • Undocumented business rules. A model cannot infer a rule that lives only in a stakeholder's memory.
  • Architecture that has to age well. The right structure depends on where the product is heading, which is context from roadmap conversations, not from your codebase.
  • Anything irreversible without review. Pushing to main, touching production data, changing auth or billing. These are exactly the places to keep a human gate.

An honest agent narrows its own autonomy here rather than bluffing through it. The measure of a good one is not how much it will attempt, it is how cleanly it stops and asks.

Where the autonomy has to stop

The scary version of an autonomous agent is one that quietly pushes broken code to production. You remove that risk structurally, not by hoping the model is careful. The gate is the merge: the agent can plan, edit, and test on its own, but a person approves what reaches the main branch.

Agentcode is built around that boundary. It runs autonomously through planning, editing, and testing, will not open a pull request on a failing build, self-reviews its diff against its own plan, and never merges on its own. The autonomy buys speed on the mechanical work while the review gate keeps a human on every change that ships. Agentcode also never trains on your code, and it works on both GitHub and GitLab. For teams with audit requirements, that reviewable trail doubles as evidence, which we cover in AI coding agents in regulated industries.

Where coding agents fit the wider agent landscape

Coding agents are one branch of a fast-growing family. The same plan-act-check loop now powers agents for support, data analysis, security, and operations, and a whole marketplace of AI agents has grown up around buying and deploying them. Coding agents are simply the branch where the work is unusually verifiable, because a test suite gives a crisp signal of success that most other domains lack. That verifiability is why the coding branch matured first, and why keeping a human on the merge is both cheap and worth it.

The bottom line

An autonomous coding agent can carry a well-specified task from a plain-language goal to a tested pull request without hand-holding, and that is a real change in how engineering gets done. It cannot, and should not, own the decisions that depend on judgment or the steps that cannot be undone. The productive setup is an agent that does the loop and a human who reviews the result.

How to start using one without regretting it

Adopting an agent goes wrong when teams either hand it too much on day one or bolt it on with no guardrails. A calmer path:

  1. Start on low-stakes, well-tested code. Give the agent tasks in a part of the codebase with good coverage, so its work is easy to verify and a mistake is cheap.
  2. Keep tasks the size of a pull request. One reviewable change is easy to check and easy to roll back. Sprawling tasks are where agents and reviewers both lose the thread.
  3. Require human approval to merge, always. Make it a rule, not a habit, so the review gate does not erode as trust grows.
  4. Watch what it gets wrong. The categories of mistake it makes on your codebase tell you which tasks to keep handing it and which to keep for yourself.

Compare the tools honestly on the best AI for coding, or see the loop yourself on how it works.

Try the demo

Watch the agent plan, edit, run tests, and open a pull request you review and merge.