An AI coding agent is a program, built on a large language model (LLM), that can carry out a programming task on its own: it reads your code, edits files, runs commands such as tests, looks at the results and keeps going until the job is done. The key difference from a chatbot is that it acts on your project instead of only answering questions about it.
This guide explains how coding agents work, what they can and cannot do, and how the main tools compare, in language that works for developers and curious non-developers alike.
What makes something an "agent" and not just a chatbot?
Anthropic's engineering post Building effective agents draws a useful line. It separates two kinds of systems:
- Workflows, which are "systems where LLMs and tools are orchestrated through predefined code paths."
- Agents, which are "systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks."
The same post puts it more simply: agents "are typically just LLMs using tools based on environmental feedback in a loop."
Three words in that sentence matter:
- Tools. The model can do things, not just write text. For a coding agent, tools include reading a file, editing a file, searching the codebase and running a shell command.
- Feedback. After each action, the agent sees what happened: the test output, the error message, the contents of the file it opened.
- Loop. It uses that feedback to decide the next step, and repeats.
A chatbot that writes a function for you to paste is not an agent. A tool that writes the function, saves it in the right file, runs your test suite, sees two failures and fixes them is.
How does an AI coding agent actually work?
Claude Code's documentation describes the loop in three phases. In How Claude Code works, Anthropic writes that when you give it a task, "it works through three phases: gather context, take action, and verify results." The phases blend together and repeat.
Here is what that looks like for a request like "fix the failing tests." The same Claude Code page lists the steps the agent might take:
- Run the test suite to see what is failing
- Read the error output
- Search for the relevant source files
- Read those files to understand the code
- Edit the files to fix the issue
- Run the tests again to verify
Nobody told the agent which files to open or which command to run. It worked that out from the goal and from what each step revealed.
Under the hood, every coding agent has the same three parts. Cursor's Agent overview lists them plainly: instructions (the system prompt and rules), tools (file editing, codebase search, terminal execution) and a model (the LLM you pick). Anthropic calls the layer around the model that provides the tools and manages what the model sees the "agentic harness."
What can a coding agent do, and what can it not do?
Coding agents are good at tasks where they can check their own work. Anthropic's post on agents explains why software suits them so well: "Code solutions are verifiable through automated tests," agents "can iterate on solutions using test results as feedback," and output quality "can be measured objectively."
Typical jobs include:
- Fixing a bug from an error message or a failing test
- Adding a feature that follows patterns already in the codebase
- Writing tests for existing code
- Refactoring across many files
- Explaining an unfamiliar codebase
- Writing commit messages and opening pull requests
Where they struggle:
- Vague goals. "Make it better" gives the agent nothing to verify against. A concrete goal with a check it can run works far better.
- Long sessions. The agent's working memory, called the context window, fills up as it reads files and command output, and performance drops as it fills. Our guide to context engineering covers how to manage this.
- Judgment about your wider system. Tests can show code runs; they cannot show it fits your product, your team's conventions or your security needs. That part is still yours.
- Untrusted input. An agent that reads web pages, issues or dependency files can be tricked by hidden instructions inside them. See prompt injection in coding agents.
What are the main AI coding agents today?
Many popular tools now ship an agent. They share the same loop but differ in where they run and how you talk to them.
| Agent | Made by | Where it runs | How the vendor describes it |
|---|---|---|---|
| Claude Code | Anthropic | Terminal, IDE, desktop app, browser | "an agentic coding tool that reads your codebase, edits files, runs commands, and integrates with your development tools" |
| Codex CLI | OpenAI | Terminal on your computer (Codex also comes as an IDE extension, a desktop app and a cloud agent) | "a coding agent from OpenAI that runs locally on your computer" |
| Cursor Agent | Cursor | Inside the Cursor editor | "Cursor's assistant that can complete complex coding tasks independently, run terminal commands, and edit code" |
| Gemini CLI | Terminal | "an open-source AI agent that brings the power of Gemini directly into your terminal" |
For deeper comparisons, see Claude Code vs Cursor and Codex vs Claude Code. Setup guides live at Claude Code setup, Codex CLI, Cursor Agent and Gemini CLI.
How do you keep a coding agent under control?
Because an agent runs real commands on a real machine, each vendor builds in guardrails. The names differ, but the ideas repeat.
Permission modes. Claude Code lets you choose how much the agent may do without asking. In Manual mode it asks before most actions that edit files, run shell commands or reach the network; Plan mode lets it read files and propose a plan without editing your source. See Claude Code permissions.
Sandboxes. OpenAI's Codex security docs say that by default "the agent runs with network access turned off," and that locally Codex uses "an OS-enforced sandbox that limits what it can touch (typically to the current workspace)." See Codex approvals and sandbox.
Checkpoints. Claude Code snapshots a file before the agent edits it, and Cursor's Agent creates checkpoints before significant changes, so you can roll back. Cursor's docs note that restoring a checkpoint "reverts files only; it does not remove messages from the conversation." See Claude Code checkpoints.
Your review. Every vendor still puts the final decision on you. Claude Code's security page says it directly: "You're responsible for reviewing proposed code and commands for safety before approval."
How do you give a coding agent good instructions?
Agents do better with clear goals, specific context and a way to check their own work. Anthropic's Claude Code best practices put it as: "Give Claude a check it can run: tests, a build, a screenshot to compare."
A weak prompt and a strong one:
weak: add tests for foo.py
strong: write a test for foo.py covering the edge case where the user is logged out. avoid mocks.
Beyond single prompts, most agents read a project instruction file at the start of every session: CLAUDE.md for Claude Code, and AGENTS.md for Codex and other agents (OpenAI's docs say "Codex reads AGENTS.md files before doing any work"). Our guides to CLAUDE.md and AGENTS.md show what to put in them. For repeatable procedures, Agent Skills package instructions into a SKILL.md folder the agent loads only when needed.
Where do your prompts and skills live?
Once you use an agent daily, you collect prompts and skills that work. Kipt keeps them as Markdown in a private GitHub repo you own, with {{name}} blanks for the parts that change, and installs every skill into Claude Code or Codex with one command: npx skills add https://github.com/<you>/<repo>.git --all -g. If you want to turn one prompt into a skill first, the free SKILL.md generator runs in your browser.
What should you read next?
If the idea of an agent is clear, the next step is learning how to work with one. Agentic coding covers the day-to-day workflow: explore, plan, implement, verify. Context engineering explains why the agent's working memory is the most important thing to manage. And prompt injection in coding agents covers the main security risk that comes with giving an AI real tools.