How to work with AI coding agents: explore, plan, test, review

Last checked: 21 Oct 2026. The guidance below comes from Cursor's Coding Agents course on Cursor Learn and the Cursor docs, Anthropic's Claude Code documentation and AI-native SDLC playbook, OpenAI's Codex documentation, and survey research from DORA and Stack Overflow.

A good routine for any AI coding agent is short. Have the agent explore the code before it changes anything, agree a plan, write the tests first, give it checks it can run, review its changes to your usual standard in small commits, and refuse to merge a fix you cannot explain. Anthropic, OpenAI and Cursor each publish guidance covering most of this for their own tool. This post sets the three side by side and notes where only one vendor documents a practice.

Why a routine helps

Anthropic builds its Claude Code advice on one constraint: "Claude's context window fills up fast, and performance degrades as it fills" (Claude Code best practices). Exploring separately, planning before code and starting afresh after a wrong turn all keep that context clean. Cursor says its own course patterns "apply to any AI model or product".

DORA's 2025 report, based on nearly 5,000 survey responses, says "AI doesn't fix a team; it amplifies what's already there", and that without strong automated testing, mature version control and fast feedback, more change volume leads to instability (DORA 2025 report). DORA is part of Google Cloud, which sells AI products, and a survey shows association rather than cause. In Stack Overflow's 2026 survey, "48% indicate they trust AI when they can easily validate the answers" (Stack Overflow Developer Survey 2026, a self-reported sample of 30,903 responses).

Explore before the agent changes anything

Cursor's chapter on understanding your codebase names the common mistake as "asking the agent to change code without first understanding what exists", for example an agent that writes a new utility function when one already exists. Anthropic recommends four phases (explore, plan, implement, commit) so that you "avoid solving the wrong problem". OpenAI documents a read-only workflow for explaining a codebase, with an example prompt asking Codex to summarise the request flow as numbered steps and list the files involved (Codex prompting guide).

All three tools can search in a separate context so the main conversation stays clear: Cursor and Claude Code each have a built-in Explore subagent, and OpenAI suggests subagents for exploration. A first prompt such as "Before changing anything, explain how validation works here and list the files involved" takes a minute and gives you an answer you can check.

Plan before building, and restart rather than patch

In all three tools Shift+Tab switches to plan mode. Cursor's Plan Mode researches the codebase, asks clarifying questions and produces a plan you can edit before building (Cursor docs). Claude Code's plan mode reads files and answers questions without making changes, although Anthropic's permission modes page describes one configuration where an edit attempted during planning can still run, so treat it as a separation of thinking from editing that does not guarantee nothing changes.

Read the plan critically. Anthropic's SDLC playbook (21 Aug 2026) asks for a plan that "names the files that change, the order of the work, and the tests that prove it", and tells the engineer to question what it could break. OpenAI suggests a prompt with a goal, context, constraints and a "done when" line, such as tests passing or a bug no longer reproducing (Codex best practices).

Not every change needs a plan. Anthropic's rule is "If you could describe the diff in one sentence, skip the plan," and Cursor says going straight to Agent mode is fine for quick or familiar changes.

When the build goes wrong

Cursor advises going back to the plan instead of correcting a wrong build through follow-up prompts: revert, refine the plan and run it again, which it calls "often faster than fixing an in-progress agent". If the agent keeps going in circles, it says, start a new conversation. Anthropic's rule of thumb is that after correcting Claude more than twice on the same issue, the context is cluttered with failed approaches, so clear it and start again with a more specific prompt. OpenAI's guidance is to keep one chat per coherent unit of work. Our advice: when a build has gone in the wrong direction, keep what you learned and discard the attempt.

Write the tests first

Cursor's Developing features chapter sets out test-driven development with agents in five steps. Write the tests and tell the agent you are doing TDD. Confirm they fail. Commit them, which "locks in your requirements for the agent to build against". Ask for code that makes all the tests pass without modifying them. Commit the code. Committing first means the agent cannot quietly change the tests to make them pass.

Anthropic's playbook gives the same step for bug fixes: reproduce the bug as a test, confirm it fails for the reason you expect, commit it, then ask Claude to make it pass without editing the test, because "A test that existed before the fix, and that the agent couldn't rewrite, is proof the bug is gone." OpenAI recommends tests as a separate step, confirmed failing before feature work, and reviewed by engineers for shortcuts or stubbed tests (OpenAI, Building an AI-native engineering team). OpenAI stops short of saying to commit the tests and keep them unchanged.

Telling the agent not to touch committed tests is still only an instruction, and none of these pages describes a mechanism that enforces it. Anthropic's playbook names two real controls: a hook that blocks edits to test files during a fix, or rejecting any diff that touches a test. We would use one of them as well.

Debug from a reproduction and runtime evidence

Cursor's Finding and fixing bugs chapter starts with a principle for people and agents alike: "If you can't reproduce the bug, you can't verify the fix."

Cursor's Debug Mode builds this in. The agent forms hypotheses, adds logging, asks you to reproduce the bug, analyses the logs, makes a targeted fix (often a few lines) and removes the instrumentation once you confirm the fix. Cursor suggests it for bugs you can reproduce but cannot explain, such as timing issues and memory leaks.

We found no equivalent mode in the Claude Code or Codex pages we read, but both describe the same discipline. Anthropic's example prompts ask Claude to "write a failing test that reproduces the issue, then fix it" and to "address the root cause, don't suppress the error". OpenAI says to give Codex a reproduction recipe and the files you suspect, and to have Codex re-run the repro steps after the fix. In any of the three tools, the evidence is failing tests, command output, stack traces and, for front-end bugs, a browser the agent can read.

For hard bugs, try more than one model

Cursor says that "For hard bugs, different models sometimes find different things" and lets you run the same debugging prompt across several models at once, each in isolation. In the IDE this is the /best-of-n command. Cursor advises keeping the approach with the strongest evidence. Its blog claims several models on one problem "significantly improves the final output, especially for harder tasks" (Cursor blog, 9 Jan 2026). That is Cursor's claim, and we found no independent study of it.

Anthropic and OpenAI document choosing among their own models and reasoning settings: Claude Code lets you switch model mid-session, and OpenAI suggests comparing models and settings on the same inputs (Codex model selection). Neither describes comparing across vendors. Our advice is to try a second model on a bug that has resisted the first and judge it on its evidence. It costs usage: in Cursor, for example, third-party models on some plans are billed at API list price outside the included pool (Cursor models and pricing).

Give the agent ways to check its own work

Anthropic puts verification first: "Give Claude a check it can run: tests, a build, a screenshot to compare." Without one, it says, you become the verification loop. It also asks Claude to show evidence, such as the test output or the command it ran and what it returned, instead of asserting success.

Cursor's Reviewing and testing code chapter lists tests, type checking and linting as verifiable goals and says "The more of these checks you have in place, the more confidently you can delegate work to agents." OpenAI tells you to ask Codex to create tests where needed, run the relevant checks and review the work before you accept it,. The useful checks are:

• the test suite, or the smallest relevant part of it;
• a type check and a linter;
• a build that has to succeed;
• for front-end work, a browser the agent can use to read the console and the page.

Put the commands in the repository's instruction file. Codex and Cursor read AGENTS.md, and Claude Code reads CLAUDE.md and can read AGENTS.md. Instructions are advisory, though, and Anthropic notes that hooks are deterministic. All three tools have hooks, and Claude Code and Codex both document using one to run a check when the agent's turn ends. Our post on rules, skills, subagents and hooks compares them.

Review agent changes to the same standard, in small commits

Cursor's rule is "Your standards for what gets merged should be the same whether the code was written by hand or by an agent." It warns that agent code can pass your tests while missing edge cases or duplicating logic (Reviewing and testing code). OpenAI says to treat Codex suggestions like any other pull request: run targeted verification, review the diffs and record decisions in commit messages (Codex approvals and security).

Keep changes small enough to review. Cursor recommends small, semantic commits, one logical change each, and suggests letting the agent build and then asking it to rework the commit history into reviewable pieces, checking that the final diff matches the original. OpenAI advises a feature branch and frequent commits so you can roll back in small increments. DORA's guidance on working in small batches warns against generating massive pull requests, because machine-generated code can take more effort per line to review.

Each vendor offers an automated first pass: Agent Review and Bugbot in Cursor, a /code-review command and a managed GitHub review service in Claude Code, and /review and GitHub reviews in Codex. Availability differs by plan, so check the vendor's page. All three leave the decision with a person. Anthropic cautions that a reviewer asked to find gaps will usually report some even in sound work, so ask it to flag only gaps that affect correctness. See our guides to calibrating Cursor Bugbot and to what Claude Code's security review leaves for a person.

Never accept a fix you cannot explain

Cursor names this failure directly: "If you don't understand the fix, you can't validate whether it's correct." It advises asking questions until you understand the fix and checking the root cause against your own evidence, because agents can give plausible explanations that are wrong. Anthropic's nearest line is "If you can't verify it, don't ship it." OpenAI says engineers own the final review and merge, which means "reading and understanding the implications of the change".

Our rule rests on all three: if the person merging cannot say what caused the bug and why the change fixes it, the change does not merge. The same applies to apps built with AI by people who are not engineers, which our risk guide for AI-built apps covers.

Where each vendor documents each practice

"Explicit" means the vendor's own page says it. "Adjacent" means a related but different statement. "Not found" means we did not find it on the pages we read, which does not prove the tool cannot do it.

Cursor documents the most practices explicitly, largely because its course is about method. Where only Cursor documents a practice, the reasons behind it apply to any tool. We found no independent study of exploring first, planning, debugging from a reproduction or comparing models, so for those the basis is vendor guidance and engineering practice.

Common questions

How should I start a task with an AI coding agent?

Ask it to read and explain the relevant code first, then agree a plan, then build. Claude Code, Codex and Cursor all have a plan mode for this. Skip the plan for a change you could describe in one sentence.

Should I write the tests before the agent writes the code?

Where the requirements are clear, yes. Write the tests, confirm they fail, commit them, then ask for code that passes them without changing them. Cursor documents this step by step and Anthropic's playbook describes it for bug fixes. The instruction is the control, so check the diff for test edits or block them with a hook.

What should I do when the agent keeps failing to fix a bug?

Stop patching. Give the agent a reliable way to reproduce the bug and runtime evidence such as logs, failing tests and stack traces, then start again from a clean conversation or from the plan with a more specific prompt. For a hard bug, run the same prompt on a second model and compare the reasoning.

How should we review code an AI agent wrote?

To the same standard as code a person wrote. Run tests, type checks and linters first, split the work into small commits, read the tests as well as the code, and use an automated reviewer as a first pass with a person making the decision.

What if I cannot explain the agent's fix?

Do not merge it. Ask the agent questions until you can say what caused the bug and why the change fixes it, or ask for the reproduction and the evidence behind the fix.

This method works with whichever tool your team has chosen. The harder part is making it the team's routine, with shared instruction files, checks the agent can run and a review standard everyone applies. If you would like help with that, see our work on AI coding tools for engineering teams and use Request a Quote on that page. Our pages on Claude Code, Codex and Cursor cover each tool in more depth.