What is a coding agent?

A coding agent looks like a chat box, but the chat box is only its control panel. Behind it is a software system that can inspect files, run commands, edit code, read the result, and decide what to do next. That distinction matters because the useful work—and most of the risk—happens outside the model.

The shortest useful definition is this: a coding agent is a model operating through a harness in a loop. The model proposes the next action. The harness supplies context, exposes tools, applies permissions, executes approved actions, records observations, and decides whether the loop may continue. Tests and human review judge the resulting state.

The model is the decision engine, not the whole machine

A language model accepts context and generates a continuation. That continuation may be prose, code, or a structured request such as “call the file-search tool with this query.” A model by itself does not open your repository or run a test. As the 2026 VS Code explanation of coding harnesses puts it, models produce text; the harness bridges that text to the editor and operating system.

Chatbot

The model mainly returns a message. It may retrieve information, but the user still carries out most consequential actions.

Workflow

Software follows a predetermined path: do A, then B, then C. A model may fill in steps, but code chooses the route.

Agent

The model chooses the next action from the available tools after observing what happened. The route can change while the task is running.

Autonomy is a spectrum. An agent that may only read files and suggest a patch has less authority than one that may edit, run commands, deploy, and post the result. The same model can behave like a careful assistant or a reckless operator depending on its tools, permissions, loop limits, and verifier.

The harness turns proposals into controlled actions

A harness is the software wrapped around the model. Microsoft’s agent-harness documentation describes it as the scaffolding that runs the tool loop, manages conversation history and context, applies approval and safety policy, and keeps work moving toward completion. A coding product’s quality therefore depends on more than which model it selected.

Goal

The requested outcome. “Make the tests pass” is a goal; the exact edits are deliberately left open.

Instructions

Rules for how to work: repository conventions, safety limits, commands to run, and preferences to follow.

Context

The information visible to the model for this round: the request, instructions, selected files, history, and tool results.

Model

The probabilistic decision engine that generates text and structured action requests from the current context.

Tools

Named capabilities with defined inputs and outputs, such as reading a file, applying a patch, searching the web, or running a command.

Environment

The world the tools can inspect or change: files, processes, Git state, a browser, a database, a network, or an external service.

Permissions

Policy that decides which proposed actions run automatically, require human approval, or remain forbidden.

Verifier

Evidence about the result: type checks, tests, screenshots, queries, diffs, evaluators, or human inspection.

Trace

The record of model responses, tool calls, observations, approvals, errors, and final state during one run.

Budget

The stopping limits: model tokens, tool calls, time, money, retries, or a maximum number of rounds.

The harness also decides what the model does not see. Context windows are finite. Long sessions may be compacted into summaries; large repositories may be searched rather than loaded whole. Context is a working set, not permanent memory and not a complete copy of reality.

The loop is where agency appears

The core mechanism is an ordinary feedback loop: assemble context, ask the model for a next step, execute any allowed tool call, return the observation, and repeat. Anthropic’s Building effective agents compresses the idea to models using tools in a loop based on environmental feedback.

while (roundsRemain) {
  const proposal = await model(context);

  if (proposal.kind === "final") {
    return verify(proposal, environment);
  }

  const decision = await permissions.check(proposal.toolCall);
  if (decision.kind === "ask") await askHuman(decision);

  const observation = await tools.run(decision.allowedCall);
  context = context.with(observation);
}

This sketch hides error recovery, cancellation, compaction, parallel work, and many security checks. It still reveals the important structure. The model proposes; the surrounding program controls execution. A tool error becomes new input rather than necessarily ending the task.

Turn, round, and run name different scales

Turn

The user-visible exchange that begins with one message and ends with the agent’s response.

Round

One pass through context assembly, model generation, optional tool execution, and observation.

Run

The complete execution for a task, often containing many rounds inside one visible turn.

This vocabulary explains why an agent can appear to do ten things after one message. Your turn started once. The harness ran many internal rounds: search, read, edit, test, inspect, and perhaps retry.

A coding task is a trace through changing state

Suppose the goal is “add an empty state to the projects page and prove it works on mobile.” A capable run may look like the sequence below. Notice that the agent does not begin by typing code. It first reduces uncertainty.

1. 01

   human

   GoalNames the desired user-visible state and asks for mobile evidence.
2. 02

   agent

   OrientSearches the repository, reads local instructions, and finds the page, tests, and style boundary.
3. 03

   tool

   InspectReturns the current component, data contract, and nearby empty-state patterns.
4. 04

   agent

   PlanChooses a small edit and predicts which checks should detect a mistake.
5. 05

   harness

   ApplyValidates a structured patch request, writes the change, and reports the resulting diff.
6. 06

   verifier

   Type checkRejects a missing discriminated-union branch with a concrete compiler error.
7. 07

   agent

   ReviseReads the error, updates the branch, and reruns the narrow checks.
8. 08

   verifier

   Browser checkRenders the zero-project case at a narrow viewport and captures what a person would see.
9. 09

   human

   ReviewJudges the copy, visual priority, and whether the evidence matches the requested outcome.

The trace is useful because it separates a polished final sentence from the work that actually happened. A claim such as “the page is fixed” is cheap. A trace containing the diff, a passing check, and a rendered narrow view is evidence.

Tools are narrow capabilities with contracts

A tool is closer to a function than to a magic power. It has a name, a description, input fields, an implementation, and a result. A search tool might accept { query, path } and return matching lines. A command tool might accept { command, workingDirectory } and return standard output, standard error, and an exit code.

Tool design changes behavior. Vague names, overlapping capabilities, or enormous results make selection harder. Clear schemas constrain mistakes and make requests inspectable before execution. More tools expand what an agent can do, but they also enlarge the decision space and the security surface.

Tools, skills, and MCP solve different problems

Tool

An executable capability. It can inspect or change something and returns an observation.

Skill

Reusable instructions that teach the agent when and how to perform a kind of work. A skill may tell the agent which tools to use.

MCP

The Model Context Protocol, a standard connection through which hosts can discover tools, resources, and prompts exposed by servers.

A database query is a tool action. A checked playbook for diagnosing slow queries is a skill. MCP can be the connection that makes the database tool available to the harness. The names are related, but they are not interchangeable.

The environment gives the loop consequences

The environment is the state outside the model: your filesystem, Git working tree, running processes, browser, database, cloud account, and external services. Tools cross the boundary into that state. This is why a model response can be harmless in a chat window and consequential in an agent.

• Read. File contents, directory listings, Git history, logs, database rows, documentation, and browser state.
• Write. Patches, new files, configuration, database mutations, generated assets, and comments.
• Execute. Compilers, tests, package scripts, local servers, migrations, and arbitrary programs.
• Communicate. Network requests, issue updates, email, chat messages, deployments, and public posts.

The OWASP AI Agent Security Cheat Sheet treats excessive autonomy, tool abuse, prompt injection, memory poisoning, and unbounded consumption as system risks. A confirmation dialog helps, but it does not make a confusing action safe. The user must still understand the target and consequence.

Verification closes the loop with evidence

Coding agents work unusually well because software provides cheap feedback. Source files can be searched. Compilers and type checkers return exact failures. Tests can define expected behavior. Git exposes every edit. A browser can render the result. The agent can observe those signals and revise its next action.

• Static checks. Type checkers, linters, schema checks, and build tools reject classes of invalid programs without exercising the full product.
• Executable checks. Unit, integration, end-to-end, and property tests run the system against named examples or general laws.
• State inspection. Diffs, database queries, HTTP responses, file hashes, logs, and screenshots reveal the actual environment after the action.
• Human judgment. A person evaluates intent, product quality, ambiguous tradeoffs, and consequences that no automated check fully represents.

Anthropic’s 2026 guide to agent evaluations distinguishes the transcript from the outcome. The transcript is what the agent did and said. The outcome is the resulting world state. A booking agent can announce a reservation that does not exist; a coding agent can announce success while the build is broken. Grade the outcome.

The agent loop is a map of programming

A coding agent is a good first programming lesson because its parts are visible in conversation. The same structures appear in ordinary software, only with a deterministic function or algorithm often replacing the model.

Tool call → function call

A named operation receives arguments, performs work, and returns a value or error.

Tool schema → type signature

The contract says which inputs are allowed and what kind of result to expect.

Context → state

Information carried forward changes what the next step can do.

Permission check → conditional

The program chooses a path based on a value: allow, ask, or deny.

Agent loop → while loop

Work repeats until a stopping condition, error, cancellation, or exhausted budget.

Harness → runtime

Surrounding machinery schedules work, manages resources, enforces rules, and communicates with the environment.

Observation → return value

The result of one operation becomes input to the next decision.

Trace → log and debugger history

A record makes invisible execution inspectable after the fact.

Verifier → test

An executable claim checks whether a property of the result holds.

Programming is the practice of representing state, choosing operations, controlling repetition, handling failure, and checking outcomes. Vibe coding changes who types many instructions; it does not remove these structures. Learning their names lets you give better goals, notice dangerous assumptions, and diagnose the layer that failed.

Most failures belong to a layer

• Ambiguous goal. The agent optimizes a plausible interpretation that is not the one the user intended. Better wording or a human decision is required.
• Missing or stale context. The model never sees the local rule, relevant file, current documentation, or earlier decision needed for a good next step.
• Weak tool contract. The available actions overlap, hide important parameters, return too much noise, or cannot express the safe operation.
• Environment mismatch. The command assumes a different operating system, dependency version, credential, data set, or deployment configuration.
• Permission mismatch. The agent cannot take a needed action, or it has authority that should have remained behind review.
• Bad recovery loop. The agent repeats the same failing strategy, compounds earlier edits, or spends its budget without changing the evidence.
• Inadequate verifier. The available check passes while the real requirement remains untested, such as a responsive layout that only received a type check.
• False finish. The agent produces a confident final response before inspecting the state it was asked to change.

This layered diagnosis is more useful than “the AI is bad.” A stronger model may help a reasoning error. It will not repair a missing credential, a misleading tool description, or a test that checks the wrong behavior.

The human remains part of the control system

An agent can explore a large action space faster than a person can direct every keystroke. The human role moves upward: define the outcome, expose the right context, set authority, choose evidence, resolve ambiguity, and judge the tradeoff. That is still engineering work.

1. Name the result in observable terms: what should a user, test, file, response, or database contain?
2. State constraints that change the solution: security boundary, supported platform, compatibility, data ownership, and actions that need approval.
3. Give the harness access to the smallest useful toolset and the instructions that actually govern the workspace.
4. Ask the agent to inspect before editing and to make uncertainty visible when the answer changes the design.
5. Choose checks that observe the real requirement, then let failures feed the loop.
6. Review the diff, trace, and resulting environment rather than grading the confidence of the final paragraph.
7. Stop or redirect the run when new evidence shows that the goal, plan, or authority boundary is wrong.

A coding agent is therefore best understood as a programmable control loop with a probabilistic decision engine. Its harness determines what the model can see and do; its tools connect proposals to the world; its verifier supplies evidence; and its human sets the purpose and limits. That mental model will survive changes in model names, editors, and agent products.