Coding agent

Checked 26 October 2026 · by A.Frick

In plain words

A coding assistant in an editor suggests the next line. A coding agent does more: you describe a task, and it works through it. Anthropic describes its Claude Code as an agentic coding tool that reads your codebase, edits files, runs commands and integrates with your development tools. Several vendors and open-source projects offer similar tools, in the terminal, in editors and on the web.

The usual loop is the one of any AI agent: the tool reads files to understand the project, makes a plan, changes code, runs the tests or the program, reads the errors, and tries again until it passes or you stop it. It uses tool use for file access and shell commands, and often MCP to reach issue trackers, design files or databases. Project files with standing instructions, such as a CLAUDE.md, tell the tool your conventions.

Why it matters

• Time: Chores such as writing tests, fixing lint errors, updating dependencies and writing release notes can be handed over.
• Cost: A coding agent reads many files and repeats steps, so it uses many tokens. On a chat plan it can eat the usage limit fast. Anthropic notes that Claude Code usage counts toward the same limit as its chat apps.
• Quality: The code can look right and still be wrong. Tests and your review are the safeguard.
• Control: The tool can run commands on your machine. Work in a version-controlled folder, approve risky commands, and keep it away from files with secrets, such as .env files with API keys.
• Security: Code, issues and web pages the agent reads may contain hidden instructions (prompt injection). Use least privilege and review what it does.
• Start small: Anthropic advises the simplest solution that works, and more agent autonomy only when it pays off.

Example

A test fails in your project. You write: "The test for the invoice total fails. Find the cause, fix it, and run the tests." The agent opens the test and the invoice code, spots a rounding error, changes one function, runs the test suite, sees a second failure, fixes that too, and reports the changes. You read the diff, run the tests yourself and commit.

Common misconceptions

• "It replaces the developer." It speeds up work, and someone must still define goals, review and own the result.
• "If the tests pass, the code is good." Tests only cover what they test. Weak tests pass weak code.
• "It is safe to give full access." Limit file and command access to what the task needs.