TL;DR: A coding agent is a model inside a harness that can read files, run commands and edit code in a loop until a task is done. For a PM, five controls decide whether it is useful and safe: a project instruction file, planning before edits, permissions and a sandbox, background runs, and output a person can review. The products differ mainly in where they run and how you watch them; pick by the job (prototype, read a codebase, draft a spec, review a change) and by what your company allows near its code and data.
What a coding agent actually is
A chat assistant answers. A coding agent acts: it reads the repository, decides what to change, edits files, runs the tests or the app, reads the result and tries again. The model proposes each step; the harness around it decides what it may touch, what it remembers and when it must stop and ask. That surrounding software is why two tools on the same model can feel very different.
The five controls a PM should know
1. A project instruction file. A Markdown file in the repository tells the agent how the project works: commands to install and test, conventions, what not to touch. Claude Code reads CLAUDE.md, and its memory docs now say it can read a repository's AGENTS.md in place of one (checked 6 November 2026), so one shared file can serve several tools. AGENTS.md is an open format that several tools read; its site describes it as "a README for agents" and it is now stewarded by the Agentic AI Foundation under the Linux Foundation (as of October 2026).
2. Plan before editing. Asking for a plan first catches a wrong approach before it touches twenty files. In Claude Code's plan mode the agent reads files and proposes a plan but makes no edits until you approve it. For a PM, reading that plan is the cheapest review you will ever do.
3. Permissions and a sandbox. The agent should run with the least access the task needs: which commands run without asking, which need approval, which are refused, and whether network access is allowed. This is the setting that decides whether a prototype can leak data or delete something. Treat text the agent reads (an issue, a web page, a dependency's README) as untrusted input, because prompt injection applies to coding agents too.
4. Background and cloud runs. Some work runs while you do something else: OpenAI's Codex has a cloud surface alongside its CLI and IDE extension, and Google's Antigravity launched with a Manager surface for running several agents across workspaces. Background work trades speed for less supervision, so it needs the other four controls more.
5. Output a person can review. A diff, a test run, a summary of what changed and why, screenshots of the running app. Antigravity's launch post described agents reporting through Artifacts such as task lists, implementation plans, screenshots and browser recordings. Whatever the tool, the PM's question is the same: can I check what happened without reading every line?
How the main tools differ (as of October 2026)
Product surfaces change monthly. Check the current documentation before you standardise.
| Tool | Where it runs | Notable for a PM |
|---|---|---|
| Claude Code | Terminal and other surfaces | CLAUDE.md or AGENTS.md instructions, plan mode, MCP tools |
| OpenAI Codex | ChatGPT apps, CLI, IDE extension, cloud | AGENTS.md, cloud runs, code review support |
| Cursor | An AI code editor | Project rules and AGENTS.md, agent inside the editor |
| Google Antigravity | An agent-first development environment | Manager surface for several agents, Artifacts for review |
| App builders (Lovable, Replit, v0 and similar) | Browser | Fastest clickable prototype, least control over the code |
What a PM uses them for
- Prototypes with real model calls. A working prototype in an afternoon, with an evaluation script beside it (see the live prototyping round).
- Reading an unfamiliar codebase. "Where is the refund limit enforced, and what calls it?" answered with file references you can check.
- Specs and acceptance criteria. Turning a PRD into scenarios and tasks an agent or an engineer can build from.
- Reviewing changes. Asking an agent to explain a pull request against the spec before you sign off.
A rough cost check helps when choosing between building yourself and waiting for engineering time. If a prototype takes an afternoon of a PM's time with an agent, against two weeks in an engineering queue, the agent wins whenever the prototype's purpose is learning. It loses when the output must be maintained, because unreviewed prototype code becomes someone else's production problem (see prototype to production).
The risks that matter
| Risk | What goes wrong | Control |
|---|---|---|
| Secrets and data | Keys or customer data in the repository reach the agent or its logs | Approved tools only; no production data in prototypes |
| Destructive commands | The agent deletes files or runs migrations | Permission rules; sandbox; plan approval |
| Untrusted instructions | Text in an issue or a dependency redirects the agent | Treat read content as data; limit network access |
| Unreviewed code shipping | A prototype becomes production by accident | Handoff with tests and a named owner |
In the interview
Loops with a live build round, and many AI-native companies, ask how you work with coding agents. The answer that scores names a specific workflow (instruction file, plan, approve, build, test, review), shows judgment about permissions and data, and is honest about where agent-written code needs an engineer. Brand loyalty without a workflow scores poorly, and so does claiming the agent "just builds it".