What is a coding agent vs Copilot vs a chatbot that writes snippets?

I can tab-complete a function, paste a block from a chat, or assign a GitHub issue and walk away. Vendors sell those three acts as the same product. They are not.

A coding agent plans, edits, runs tests, and stops on a finish line you can check. Autocomplete fills the current line, and a chat window pastes a block you still have to place. If you stay in every keystroke, you have a faster typist, not an agent.

A coding agent finishes a software job

A coding agent receives a goal with a test for done, a short list of tools, and a runtime that can stop it. It thinks, acts, looks at the result, and repeats. The output is a pull request or a passing suite, not a reply in a pane.

The tools are boring on purpose: read files, search the repo, edit, run tests, commit, open a pull request. The runtime owns retries, logs, and the stop, and the model chooses the next call inside those limits. If you still click every step, you built a slow assistant.

Anthropic’s Building effective agents, published 19 December 2024, draws the architectural line I use on desks. A workflow is a predetermined path. An agent is a model that directs its own tool use.

They say agents fit open-ended problems where you cannot hardcode the number of steps, and coding is the example they reach for because tests can act as ground truth at each turn. That is the loop. It is not a smarter complete, and it is not a chat that happens to know TypeScript.

• A goal you can test. “Make the auth nicer” is not a goal. “Failing test in auth.spec.ts passes, no other suite red, draft PR on a branch” is.
• Tools with names and limits. Read is not write. Write is not merge. Merge is not production.
• A loop the runtime owns. Retries, logs, and the stop rule do not live in the prompt.
• A budget. Steps, minutes, spend. Unbounded loops are how a demo becomes an invoice and a dirty tree.

The mechanics of those calls sit in AI agent tool calling. You declare named functions, the model picks a name and arguments, and your runtime runs the function. It returns a short true result, and the agent continues.

Without tools you have a chatbot. With thirty tools you have a wanderer. I start under ten, even on a repo.

Autocomplete is Copilot as a typist

GitHub Copilot’s inline suggestions are autocomplete: you type, gray text appears, and you accept with Tab, take the next word, or reject. You still sit in every decision. The loop never leaves your hands, and the job never leaves your ticket queue.

GitHub’s Copilot features docs (2026) call inline suggestions an assistive feature: gray text in supported IDEs as people work. Next edit suggestions predict the next place you are likely to change. Useful, and still not a coding agent.

Autocomplete does not own a job, run the suite unless you do, or open a branch. It stops because you moved the cursor, not because a finish line fired.

People call every Copilot surface an agent now: inline complete, chat, agent mode, cloud agent. Those are four different loops. Treat inline complete as a typist with good recall of your current file.

Copilot Chat in Ask mode is closer to a chatbot that writes snippets. You ask, it replies with code and an explanation, and you copy, insert a block, or keep prompting.

GitHub’s Copilot Chat docs (2026) put questions and suggestions in Ask mode, not autonomous edits. The pane can sit in the editor and still be a chatbot. Location is not the loop.

Agent-in-editor still needs you at the desk

GitHub’s agent mode in IDEs is a different loop. Copilot decides which files to change, offers edits and terminal commands for your approval, and iterates until the original task is complete. You are still in the session, confirming work as it happens.

You confirm commands, watch the working set, and can stop it, because the tree is yours. This is a coding agent in the narrow sense: tools, a task, a loop. It is not unattended.

GitHub’s Copilot docs split the two on purpose. Agent mode works in your local environment. Copilot cloud agent, formerly Copilot coding agent, works in a GitHub Actions-powered environment in the background.

Confusing them is how a team thinks they delegated a ticket when they actually pair-programmed with a pane. I use agent-in-editor when the job needs my eyes on the files as they change.

I stay in agent-in-editor on a refactor that can wreck a public API, or a migration where the second file needs a judgment the model should not own. The agent types. I still steer the tree.

The artifact is a dirty working tree I still have to commit. Plan mode, in the Copilot IDE docs, is a workflow in front of that loop. The plan agent researches with read-only tools, writes steps, asks open questions, and does not edit until you approve.

Then you hand the plan to agent mode. That is Anthropic’s evaluator-optimizer pattern with a human as the gate. Useful, and still you at the desk on every turn that matters.

Agent-in-editor fails the way pairing fails. You accept a command you did not read, or the agent “fixes” a test by deleting the assertion, because you were in Slack for four minutes.

Unattended SWE agents work off your laptop

An unattended software-engineering agent takes a ticket, works in an isolated environment, and comes back with a branch or a pull request. You are not in the trace. You review the artifact when it is ready, the same way you review a colleague.

GitHub’s Copilot cloud agent is this shape. OpenAI’s Codex cloud is this shape: isolated environments, parallel tasks, review the summary and diff, then open a pull request when you are ready.

GitHub shipped Copilot coding agent as generally available on 25 September 2025. The 1 April 2026 changelog renamed it Copilot cloud agent. The current docs still describe the same job.

YouTube

Open original

GitHub walked the same background coding-agent loop on 18 Feb 2026.

GitHub’s loop is research the repo, write a plan, edit a branch, then optionally open a pull request. You can assign a GitHub issue to Copilot the way you assign a person.

Independently here means the environment is ephemeral and powered by GitHub Actions. The agent can explore the code, edit, and run automated tests and linters.

It is not your laptop and it is not your unsaved buffer. That is the point. It is also the risk: real commits on a real branch, with logs, and with a session GitHub caps at 59 minutes.

I treat unattended agents as junior hires with a sandbox and no merge right. They get well-specified issues in well-tested code. They do not get production deploy, secrets in the prompt, or a pass because the PR description is fluent.

Autocomplete vs agent-in-editor vs unattended SWE agent

If you cannot name the shape, you will buy the wrong one and then blame the model. Autocomplete fills tokens, and agent-in-editor edits the tree while I watch. An unattended SWE agent leaves the laptop and returns a reviewable artifact.

Copilot the brand spans all three. Copilot the loop does not. I keep the split on the desk so a ticket gets a worker, a pair, or a typist, not a slogan.

A snippet chatbot does not earn a column. It is Ask mode, or ChatGPT in a browser, or any model that emits a function you still have to file. The useful split is whether the software can change the repo without you pasting.

What GitHub Copilot coding agent actually does

GitHub’s Copilot documentation is specific. Copilot cloud agent can research a repo, write a plan, fix bugs, add incremental features, improve tests, update docs, and open a pull request. You start it from an issue, the agents panel, chat, or VS Code.

GitHub lists the benefits against IDE assistants in the same article. Local assistants are synchronous, and decisions die unless you commit. You still create the branch, write the message, push, open the PR, and iterate.

Cloud agent automates branch creation, commit messages, and pushing. The work is on GitHub, in commits, in session logs the team can see. That is the actual product: an audit trail, not a ghost in your buffer.

The limits are also specific. Copilot cloud agent can only change the repository you named when you started the task. It works on one branch at a time and opens exactly one pull request per task.

Each session has a maximum execution time of 59 minutes. It only works with repositories hosted on GitHub. GitHub Actions workflows do not run automatically when Copilot pushes.

Someone with write access has to approve the workflows, because those workflows can be privileged. Read that last limit twice. An unattended agent that can edit workflow files is an unattended agent that can request secrets.

GitHub’s review docs tell you to inspect proposed changes, especially under .github/workflows/, before you click Approve and run workflows. Draft is not merge, and a branch is not production. A workflow run is not a free pass.

You can give the agent more context without stuffing the prompt every time: repository custom instructions, Copilot Memory on some plans, MCP servers. GitHub’s MCP server and Playwright are enabled by default for cloud agent and code review.

Custom agents cover specialized jobs, hooks run shell at points in the session, and skills are folders of instructions and scripts. The kernel of it is still the same: named tools, a runtime, a stop.

I do not assign it architecture. I assign it the backlog items that stay rotting because they are boring and well-tested: logging, a missing test, a docs page that drifted from the flag.

What a chatbot that writes snippets actually does

A snippet chatbot receives a message and returns code in the reply. You are the filesystem, the test runner, and the git user. The model never saw your tree unless you pasted it, and it never ran a test you did not paste back.

It never ran the suite unless you did and pasted the log. It cannot stop on done because it cannot see done. It can only stop talking.

This is still the default for a lot of desks: paste the error, get a function, paste the function, get a new error. The thread looks like engineering. The repo did not change until a person changed it.

I use this shape when I need a name for an algorithm, a regex I will throw away, or a first sketch I will rewrite. I do not use it as a worker.

The failure mode is confident code for a different codebase. The snippet compiles in the abstract, imports a helper you do not have, and handles a case your API never exposes.

You spend the afternoon teaching the chat your tree one paste at a time. That is not a coding agent missing a tool. That is a chatbot doing what chatbots do: continue the conversation.

You can turn a snippet chatbot into an agent. Add tools, a runtime that can kill the loop, a stop rule a script can see, and a score on frozen jobs. The chat UI can stay, because people like chatting.

The loop has to change. Until it does, calling it a coding agent is a branding exercise. I wrote that split as AI agent vs chatbot because vendors will not.

What Anthropic described in December 2024

Anthropic’s Building effective agents, published 19 December 2024, is the source I send when someone asks for an agentic coding platform. They say find the simplest solution first. Many applications only need a single model call with retrieval, not a loop.

Use workflows when you can draw the path, and agents when you cannot and can still write what done looks like. That is the whole sequencing. Complexity is a cost, not a feature.

They name coding agents as a domain that fits, because code solutions are verifiable through automated tests and agents can iterate using those results as feedback. The problem space is structured. Output quality can be measured.

In their own implementation, a coding agent resolves SWE-bench tasks: edits to many files from a task description. In the appendix they say agents can solve real GitHub issues in the SWE-bench Verified benchmark from the pull request description alone.

They also say human review remains crucial for whether the solution fits the broader system. That is the whole claim I will repeat: SWE-bench is a benchmark of real GitHub issues. Anthropic used it as the example of a coding agent with tools in a loop.

I will not invent a score. Scores move, scaffolds differ, and a number without the harness is marketing. If a vendor quotes a SWE-bench percentage without the scaffold, the tools, and the split, I treat it as a slide.

The part I actually steal from that post is the tool work. While building their SWE-bench agent, they spent more time optimizing tools than the overall prompt. Relative filepaths broke after the agent left the root directory.

They changed the tool to require absolute paths, and the model then used it cleanly. That is agent-computer interface work. The description of the tool is the prompt, so be exact.

They also warn about cost and compounding errors. Agents can run for many turns. You need trust in the decision-making, sandboxed testing, and guardrails.

I read that as: do not point an unattended coding agent at a repo whose tests do not mean anything. If the suite is theater, the agent will optimize for theater. If the suite is real, the agent has ground truth.

What Codex reads before it starts

OpenAI’s Codex documentation treats AGENTS.md as the durable briefing, and Codex reads those files before doing any work. Global guidance lives in ~/.codex. Project files layer from the repository root down to the current directory, so the repo can speak before the model types.

Closer files override earlier ones because they appear later in the combined prompt, empty files are skipped, and combined size is capped. That is how you stop repeating the same correction in every session.

The official guide says to put working agreements in the global file: run tests after JavaScript changes, prefer a package manager, ask before adding production dependencies. The repo file holds how to build, test, lint, and what a pull request expects.

Nested AGENTS.override.md files exist for a payments service that must not rotate keys without telling security. OpenAI’s customization overview is even plainer: keep AGENTS.md small.

Use it for build and test commands, review expectations, repo conventions, directory-specific rules. When the agent makes a wrong assumption, correct it in AGENTS.md and ask the agent to update the file so the next run inherits the fix.

Treat it as a feedback loop, not a novel. Codex cloud is the unattended shape on that stack: isolated environments per task, parallel work. Start from the web, GitHub, GitLab, Linear, or Slack.

Review the summary and the diff. Request a follow-up or open a pull request. The environment has to reproduce what the repo needs: dependencies, tools, variables, setup steps.

If the environment is a lie, the agent will ship a lie that passed in a box you never run. I write AGENTS.md the way I write a runbook for a junior who will be alone on the repo.

Put commands that actually work, directories that matter, things that must not happen, and which tests mean done. A manifesto about craft gets ignored. A script in prose gets used.

How I pick the shape for a ticket

I do not pick a vendor first. I pick the loop: the ticket either needs a typist, a pair, or a worker who returns a PR. Then I pick the tool that implements that loop, because the brand is not the job.

Copilot can be all three, which is why teams get lost, and Codex can be local or cloud. A raw chat window is almost always the snippet chatbot. The question is who sits in the trace, and what done looks like.

1. 01

   Write the finish line on the ticket

   A passing test, a draft PR, a file path. If you cannot write it, you do not have a coding-agent job. You have a conversation. Keep it in chat or write the spec first.

2. 02

   Check whether a script would do

   If the change is mechanical and the path is known, write the script. Anthropic’s 2024 post says the same: do not add an agent when a simpler system works. Agents trade latency and cost for flexibility you may not need.

3. 03

   Pick who sits in the loop

   I stay in autocomplete when I already know the design. I stay in agent-in-editor when the blast radius is the working tree and I need to steer. I leave the laptop for unattended work only when tests are real and the grant is branch-and-PR, not merge.

4. 04

   Lock the tools to the grant

   Read, edit, test, commit. Not merge. Not production secrets. Not workflow files unless a person will inspect them before Actions run. The runtime enforces this. The prompt does not.

5. 05

   Score the artifact, not the thread

   Score whether the named test moved, whether the PR exists, and whether anything else went red. A fluent session log of a missing file is a zero, even when the vendor dashboard looks busy.

I reuse this on every new coding tool. The brand changes and the three columns do not. If a demo cannot tell me which column it sits in, I already know it sits in chat.

What I still review

Human review is not a vibe. GitHub’s own Copilot review docs assume a person looks at the pull request. You can mention @copilot to ask for changes, or check out the branch and edit it yourself, because the initiator is not a second pair of eyes.

If branch protection requires approvals, the person who assigned the issue to Copilot may not count toward the required number. That is a product decision that encodes a fact: the initiator is not a second reviewer.

Anthropic said the same in December 2024, after the SWE-bench paragraph. Automated tests help verify functionality. Human review remains crucial for alignment with broader system requirements.

Tests do not see product intent, the API you meant to keep stable, or the footgun in a public type. The agent can be green and still wrong.

I review three things: the diff against the finish line on the ticket, the tests the agent added or deleted, and the grants. Did it touch workflows, secrets, lockfiles, or generated files it should not have.

I do not review the chat. The diary of the session is not the merge.

I also review the environment. Copilot cloud agent can be customized with setup steps, and Codex cloud needs a reproducible environment. If the agent passed tests that never run in CI, you merged a story.

If CI is the only suite and the agent could not run it, you merged hope. Make the suite the agent runs the suite you ship. Otherwise you are grading a different product.

When I do not hand the ticket to an agent

There are tickets I still will not hand to an agent, and the refusal is the product. If a person has to own the design, the agent does not get the keyboard first. Ambiguous work stays with a human until the finish line is a test, not a feeling.

If the blast radius is production data, the agent does not get write. If the tests do not catch a real miss, the agent does not get the repo. I keep the longer version as when not to let an agent write code.

• Ambiguous product work. If two reasonable diffs would both “work,” I need a person to choose.
• Auth, payments, and anything that mints a credential. Split the grant or do not use an agent.
• Repos without a suite you trust. The agent will ship comments and hope.
• Changes that must land in several repositories at once. Copilot cloud agent cannot do that in one run.
• Work you cannot review. If nobody on the team can read the diff, you do not have a review.

Unattended does not mean no owner. It means the owner is not the next token. The owner designed the runtime, the eval, and the grants.

I will let an agent open a PR on a well-tested bug while I do other work. I will not let it merge, and I will not let it own the incident if the PR was wrong. That ownership stays with the person who assigned the issue.

Start with autocomplete if you are still learning the file. Move to agent-in-editor when the task is a job but the blast radius should stay local. Move to an unattended SWE agent when the ticket has a finish line a script can see, and when you have time to review the PR like a colleague’s.

Skip the snippet chatbot unless you want a sketch. Name the loop out loud so the team knows which grant they are giving.