Build with AI · Guide for product managers
Claude Code and Codex for product managers
Coding agents such as Claude Code and OpenAI Codex do not just answer questions about code — they read your project, run commands and make changes. That makes them powerful tools for product managers, and it changes what "being technical" means. This guide explains how they work and how to direct them well.
Guide 7 of 10 in the technical PM path
Chat assistant vs coding agent
A chat assistant (Claude, ChatGPT) answers in a conversation. You copy code in and out. It only knows what you paste.
A coding agent works inside a project. Depending on the tool and how you set it up, it can:
- read the files in your repository to understand the existing code;
- create and edit files;
- run commands — install packages, start the app, run tests;
- look at errors and try again;
- in some setups, work in a cloud environment and open a pull request for you to review.
Claude Code (from Anthropic) and Codex (from OpenAI) are two well-known examples; editors such as Cursor and VS Code have similar agents built in. Features, names and pricing change often, so check each tool's current documentation — the working principles below apply to all of them.
Why this matters for PMs
- You can prototype yourself. An internal tool, a clickable prototype with real data, a small MVP — without waiting for engineering capacity.
- You can understand your codebase. Ask an agent "where is the pricing logic?" or "what happens when a user cancels?" in a real repository and get an answer grounded in the actual code.
- You speak the same workflow as engineers. Repositories, branches, pull requests and reviews become part of your day.
It does not replace engineers on production systems. It changes what you can do before, around and alongside them.
How an agent actually works
Simplified, an agent runs a loop: read your request → look at relevant files → make a plan → edit files or run a command → look at the result → repeat until it thinks it is done.
Two consequences:
- Context is everything. The agent only knows what is in the files, your prompt and any instructions file (many tools read a project file such as
CLAUDE.mdorAGENTS.mdwith standing rules). Missing context leads to confident guesses. - "Done" is its judgement, not yours. Agents stop when the task appears complete. Your acceptance criteria are what turn "appears" into "is".
Setting up safely
- Work in a Git repository and commit before each task, so any change can be undone. See Git and GitHub for product managers.
- Keep secrets out of the chat and out of code. API keys go in environment variables (
.env, ignored by Git). - Review permissions. Most agents ask before running commands or editing files; loosen that only for actions you understand.
- Write a project instructions file with standing rules: the stack, how to run the app, "never commit secrets", "don't add dependencies without asking", coding conventions.
How to brief an agent
Treat the agent like a very fast new engineer who has never seen the product. A good brief has:
- Goal: the user-facing outcome, not the implementation.
- Context: relevant files, screenshots, error messages, links to docs.
- Requirements and acceptance criteria: including failure cases.
- Constraints: what not to touch, security rules, no new dependencies.
- Process: "plan first and wait for my approval", "make small commits", "summarise what you changed".
Goal: users can export their tasks as CSV from the Tasks page.
Context: tasks are loaded in src/pages/Tasks.jsx from the /api/tasks endpoint.
Acceptance criteria:
- Export button on the Tasks page; downloads tasks.csv with title, status, due date.
- Only the signed-in user's tasks. Empty list → file with just the header row.
- Titles containing commas or quotes are escaped correctly.
Constraints: no new dependencies; don't change the API response shape.
First explain your plan and the files you'll change, then wait for my OK.
Reviewing what the agent did
You do not need to read every line. Check:
- The summary vs the diff. Did it change only what it said? Look at the list of changed files.
- Acceptance criteria. Test each one yourself, including the edge cases you wrote down.
- Security basics. No secrets in code; permission checks on the server; no disabled validations.
- New dependencies. Each one should have a reason.
- Explanation. Ask it to explain the change "for a PM" and list risks and anything it was unsure about.
A second opinion helps: ask a fresh session (or another model) to review the diff for bugs and security issues.
When the agent gets stuck
- Give it the real error. Paste the full error message and what you did before it happened.
- Reduce the task. Split a big request into smaller steps.
- Reset instead of looping. If it has been "fixing" the same problem for a while, revert to the last commit and restate the problem with better context.
- Check the docs yourself. Agents sometimes use outdated or invented APIs; the official documentation is the source of truth.
Common mistakes
- Starting with "build me an app like X" and no brief.
- Accepting huge changes you cannot review.
- Letting the agent install packages and change configuration without asking.
- Pasting production credentials or customer data into prompts.
- Treating a working demo as production-ready — see vibe coding for product managers.
What engineers may tell you
- "Can you put that in a PR instead of sending me a zip?" Use Git and pull requests so changes can be reviewed.
- "The agent rewrote half the file." Ask for smaller, focused changes.
- "This library doesn't have that function." A hallucinated API; check the docs.
- "Add it to the agent instructions file." A standing rule belongs there, not in every prompt.
Try it yourself
Take a small repository — even a personal project — and ask an agent three read-only questions: "Explain the structure of this project", "How does a request flow from the UI to the database?" and "What are the riskiest parts of this code?". It is a low-risk way to learn both the codebase and how the agent reasons.
TechPMer's course sets up an AI coding agent in week 1, gets it working safely inside a Git repository in week 2, and then uses it to build and ship your own project through week 12.