Coding agents: how Claude Code, Codex, and Cursor actually work
An AI coding agent reads a project, chooses actions, edits files, and can run tests to check its changes. Claude Code, Codex, and Cursor offer this workflow through different interfaces and settings. They are best suited to tasks with a clear expected outcome and a result you can check: autonomy does not guarantee correct or secure code.
What a coding agent adds to text generation
A code suggestion is a proposal you still need to integrate. An agent also has tools to find a function, inspect where it is used, edit multiple files, and run a command. It then examines the result to decide whether to continue, make a correction, or hand control back to you.
This agentic loop turns a request into a sequence of operations. Anthropic describes Claude Code’s workflow as gathering context, taking action, checking the result, and repeating as needed. The model chooses the next steps; the software around it provides tools and manages context. This architecture is documented in the official explanation of how Claude Code works.
Consider a hypothetical example: a form accepts an empty email address. The agent could find the validation logic, examine existing tests, add a test that reproduces the bug, change the relevant code, and run the checks again. It could also target the wrong form or fix only the display while the server continues to accept the empty value.
The value therefore depends on a sequence you can verify. Was the right file changed? Does the test cover the reported bug? Does the expected behavior still hold elsewhere? The agent reduces the manual steps involved, but you still need to assess those questions.
The distinction from a simple conversation is explained in AI agent or chatbot: what’s the difference?.
Claude Code, Codex, and Cursor: environments for taking action
The official documentation consulted for this guide describes tools that can act on a project. You still need to examine the interface and configuration you are actually using: a product name alone does not tell you what permissions a session has.
Claude Code is available in the terminal, development environments, a desktop application, and the browser. The official Claude Code overview confirms that it can read projects, edit files, and execute commands. Its role extends beyond providing a chat window inside a terminal.
Codex offers, among other options, a command-line interface for inspecting a local repository, modifying files, and using tools installed on the machine. Its official documentation also describes reviewing changes and using it in automated workflows.
In Cursor, the agent combines a model, instructions, and tools. The Cursor Agent documentation describes searching the project, editing files, and running commands. The environment lets you track changes; its local checkpoints are separate from Git history.
These capabilities describe ways of working, rather than measured differences in reliability. To compare the products, see Claude Code vs. Codex and Cursor vs. Claude Code. This guide focuses on the workflow these agents share and the conditions needed to keep it under control.
Reading a repository does not mean knowing everything
A repository contains code, conventions, dependencies, scripts, and decisions that may never have been documented. The agent has to find the material relevant to its task. You should not assume it has read every file or identified every possible consequence of a change.
The context window is the amount of information the model can process in an exchange. Selected files, instructions, and command results all contribute to the available context. Before a broad change, ask the agent to identify the entry points and dependencies it has examined.
A short set of repository instructions can help it find its way. Include how to run the project’s checks, which parts are generated automatically, and which compatibility requirements must be preserved. These instructions should reflect the actual repository, without accumulating outdated rules.
Be clear about what instructions can enforce: a written rule does not technically prevent an action. Telling the agent not to read secrets does not replace restricting access to the files that contain them.
For a first task in an unfamiliar project, ask for exploration without edits. A useful result is a brief map of where the relevant behavior lives, how it is tested, and which uncertainties remain. The guide to AI agent instructions explains how to document this lasting context.
Choose tasks based on how you can verify them
The central question is how you will decide whether to accept the agent’s work. A narrow request with a reproducible example gives you more to check than a general request to improve something.
The following table offers a framework for delegation. It does not report measured performance: it identifies the evidence to request and the decisions that need human judgment.
| Task | Expected agent deliverable | Verification to request | Human decision to retain |
|---|---|---|---|
| Fix a reproducible bug | Targeted change and regression test | Reproduce the failure before the fix and pass afterward | Confirm the expected behavior |
| Rename an internal interface | Updated references and relevant documentation | Search for old references and run tests | Check external consumers |
| Add a limited feature | Code, tests, and an explanation of choices | Check the normal workflow and failure cases | Resolve business rules |
| Update a dependency | Required adaptations and a report | Build, tests, and compatibility checks | Accept changes in behavior |
| Change access permissions | Documented proposal | Authorization tests and a dedicated review | Approve the security model |
Repetitive tasks can be a useful starting point: adapting tests to a changed interface, correcting inconsistent documentation, or updating similar usages. Inspect an initial result before extending the change across the repository.
Avoid open-ended delegation for billing, permissions, or data migrations. An implicit rule may be missing from both the agent’s understanding and the tests. Make the decisions explicit, and separate technical preparation from authorization to apply the change.
Passing tests provide partial evidence
An agent that runs tests receives feedback on its work. Those tests still need to represent the requirement correctly. Passing results show that the checks performed succeeded in the environment used; they do not establish that every use case works.
For a bug, look for a test that fails before the fix and passes afterward. If the agent writes both the code and a test based on the same mistaken assumption, they can agree with each other while failing to meet your request. Review the added test as well as the implementation.
Anthropic recommends giving Claude Code a way to verify its output, such as tests, example outputs, or a visual reference. This recommendation appears in its official best practices.
Ask for a report that clearly separates:
- checks that ran successfully;
- observed failures and their suspected causes;
- checks that were not run, with the reason.
An unavailable dependency, missing test database, or unreachable external service limits what the agent can conclude. A code review may still be possible, but it should not be presented as verification that the software works when run.
Finally, inspect the differences between the files before and after the task. Look for changes outside the agreed scope, deleted tests, and errors that have merely been hidden. For a user interface, also try the actual workflow: a successful build tells you little about readability or accessibility.
Permissions determine how far mistakes can spread
A generation error becomes more costly when the agent can execute commands, access credentials, or call services. Before a session, distinguish what it can read, modify, run, and transmit. These capabilities depend on the environment as well as the model.
Codex documentation separates the sandbox, which defines technical execution boundaries, from the approval policy, which determines when an action needs review. Network access also has its own settings. Consult the official permissions and security documentation for the configuration you use.
Claude Code also offers several permission modes. Its documentation distinguishes, among other options, a mode with automated action review and a manual mode with approval requests. Check your session settings against the Claude Code security documentation, since behavior varies by interface and configuration.
When working on a repository, prepare a recoverable copy and test credentials with limited permissions. Explicitly separate producing a patch, publishing it, and deploying it. Permission to make a local change should not become blanket authorization to act on your services.
A repository or external documentation can also contain text that tries to redirect the agent. Prompt injection attempts to make content the agent encounters pass as an instruction it should follow. Restricting access and possible outbound actions limits the impact of a hijacked workflow; asking the agent to be careful in the initial message is insufficient.
Measure cost per accepted change
The access price covers only part of the budget. Before choosing a plan, check included usage, limits, how overages are handled, and whether model calls may be billed separately. Check the current terms when you subscribe.
Add the time spent preparing the task, reviewing the result, and correcting mistakes. A change generated quickly may require a lengthy review if its scope has expanded or its checks are inadequate. A limited, well-documented proposal is easier to assess and accept.
To evaluate the benefit for your project, choose a representative set of tasks. Record the requested outcome, accepted changes, rework required, and observed spending. Include abandoned attempts: they are part of the cost of using the tool.
Avoid measuring usefulness by the amount of code generated. A short fix may solve the problem; a broad rewrite may create more maintenance work. Focus instead on the quality of the accepted result and how easy it is to verify.
The same approach helps you decide when to stop a session. If the agent keeps trying fixes without narrowing down the bug, ask for a factual status report: behavior reproduced, hypotheses ruled out, and remaining obstacle. Revisiting the diagnosis may be more useful than continuing to generate code. How much does an AI agent really cost per month? explores the expenses to include in your budget.
Who benefits from these agents
For a developer who can read the project and its tests, an agent can handle some of the exploration, editing, and verification. You can then focus on assumptions, interfaces, and the consequences of the change. You still need to reserve time for that review.
For a freelancer or small team, start with a scope that is easy to check. An isolated maintenance task lets you assess the quality of the edits and the final report. Set acceptance criteria before increasing autonomy or connecting additional services.
For someone learning to program, an agent can explain an execution path and suggest a change. Ask it to connect its explanations to the relevant files, then verify the behavior yourself. Accepting code you cannot understand makes errors difficult to detect.
For a business owner or manager without technical support, a prototype can help clarify a requirement. Before exposing data or opening the service to users, assign responsibility for maintenance and arrange a qualified technical review. The visible result alone is insufficient to assess access controls, recovery after an incident, or dependencies.
The AI agent directory lets you explore other approaches. For day-to-day work, the guide to using a coding agent covers task breakdown, review, and acceptance criteria.
What to check before delegating
- A coding agent reads files, makes edits, and runs commands in sequence; its results must remain verifiable.
- Define the expected behavior, authorized scope, and required evidence before starting the task.
- Review tests and file differences, including when the agent says it has finished.
- Grant permissions appropriate to the task, and require separate approval for publishing or deployment.
- Evaluate cost per accepted change, including preparation, review, and rework.
Frequently asked questions
Can you build an app with an AI agent without knowing how to code?
You can have it produce a prototype, but you will need technical skills to check access controls, data handling, and application behavior. For a customer-facing service, arrange a technical review before launch. How easily software can be generated tells you little about the quality of what is delivered.
Can a coding agent work without an internet connection?
Running commands and running the model are separate processes. An agent can run tests in an environment with no network access while still using a remote model. Fully offline operation also requires a compatible local model and an appropriate configuration.
Why does a coding agent say it is finished when the program still fails?
It may have checked only part of the workflow, encountered an incomplete environment, or drawn too broad a conclusion from a result. Ask which commands it ran, what they returned, and which checks it could not perform. Its report should let you distinguish a proposed change from a fix that has actually been verified.
Do you need multiple subscriptions to use a coding agent?
That depends on the product, plan, and authentication method you choose. Before subscribing, check what the plan covers, its usage limits, and whether additional charges are possible. An interface subscription and API billing may draw on separate budgets.