Claude Code for Project Managers: A Delivery Loop for PMs and Tech Leads

By the PMDesk team · October 15, 2026 · Guide · 20 min read

When Claude Code or Codex agents do the building, the job of the PM or tech lead directing them comes down to four things: write requests clear enough for an agent to act on, make decisions quickly when the agent asks, review the output against what was asked, and track what is done and what is still open. This guide walks through each step with templates you can copy, and shows what belongs in files and what can stay in chat.

What changes when AI agents do the building?

Anthropic's 2026 Agentic Coding Trends Report puts it plainly: software development "is shifting from an activity centered on writing code to an activity grounded in orchestrating agents," and using AI well "requires active supervision and validation." That supervision is project management work, and it lands on whoever directs the agents: a PM, a tech lead, or a solo founder doing both.

On a normal team, people fill the gaps in a spec by asking each other. With AI-assisted product delivery there is often nobody to ask. The agent reads what you wrote, fills gaps with its best guess, and keeps going.

That shifts the PM's work in three ways:

• Writing is the main tool. The quality of the output tracks the quality of the request more closely than with any human team.
• You are the bottleneck, not the build. Agents finish a task in minutes and then wait for you. An unanswered question can stall a project for hours.
• Memory has to live in files. An agent session ends, a new one starts with no history. If a decision only exists in a chat scrollback, it is gone.

So the PM directing AI coding agents is less a coordinator of people and more an editor: of requests, of plans, of output.

The delivery loop, step by step

The loop has seven steps and runs once per feature or change.

1. Intake: client documents and requirements.
2. A written request the agent reads.
3. A plan with numbered tasks.
4. The agent executes.
5. You review the output and comment.
6. Changes become change requests.
7. You track progress and open questions.

1. Intake: start from the client's own documents

Requirements usually arrive as a mix of PDFs, spreadsheets, slide decks and meeting notes, often in a shared Box or Google Drive folder. Point the agent at the originals and ask it to read and summarise, then check the summary yourself.

Two rules help here. First, treat the client folder as read-only: the agent reads it in place, and anything it produces (summaries, question lists, analysis) goes into the project, not back into the client's folder. Second, ask the agent for a list of open questions as part of intake. Gaps found on day one are cheap; gaps found after a feature is built are not.

2. Write a request the agent can act on

A request is a short file that says what you want, why, and how you will know it is done. Keep it in the project, not in a chat message, so the next session can read it too. A template that works for most features:

# Request: Export orders as CSV

## Why
Finance re-keys orders into their accounting tool every Friday.

## What
- Button "Export CSV" on the Orders page.
- Columns: order id, date, customer, total, status.
- Respect the current filters on the page.

## Out of scope
- Excel format, scheduled exports.

## Done when
- A 500-order export opens correctly in Excel and Numbers.
- Tests cover an empty result and a filtered result.

## References
- docs/client/orders-spec.pdf, section 3

The "Out of scope" section does more work than it looks. Agents tend to be helpful in ways you did not ask for, and naming what you do not want is the cheapest way to keep a change small. "Done when" gives both you and the agent the same finish line.

3. Ask for a plan with numbered tasks

Before any code, ask the agent to turn the request into a plan file with numbered tasks: "Task 1: add export endpoint", "Task 2: add button and download", "Task 3: tests". Read the plan. Five minutes on a plan catches the wrong approach before it becomes four hundred lines of code.

Ask the agent to put the task number in each commit message ("Task 2: add export button"). That one habit gives you a progress record you can check without opening the code.

4. Let the agent execute, and stay reachable

While the agent works, your job is to answer when it asks. Agents stop for two reasons: they finished a turn, or they need permission or a decision.

If you run more than one project, or more than one session per project, this is where things slip. A good setup tells you which session is waiting without you checking each terminal in turn. We cover that in detail in how to manage multiple Claude Code sessions.

5. Review the output without reading every diff

You do not need to read every line the agent wrote. You need to know whether the result matches the request. Review in this order and stop as soon as something is wrong:

1. Does it run? Open the app or page and try the "Done when" checks yourself.
2. Did the tests the request asked for exist and pass? Ask the agent to show the test names and the run output.
3. Did it stay in scope? Ask for a list of changed files. A CSV export that touched the login code needs a question.
4. Read the written output. Plans, docs, release notes and summaries are where misunderstandings show up first, and they are quick to read.
5. Spot-read the risky parts only: anything touching auth, payments, data deletion or personal data.

For deeper code review, a second agent with a review prompt is a reasonable first pass, with you reading its findings rather than the whole diff.

When you find problems, collect them and send them together. Five comments in one message give the agent the full picture; five separate messages produce five partial fixes.

6. Turn changes into change requests

Requirements change after the first version ships. The client sees the CSV and wants a currency column. Do not edit the original request: add a change request (CR) under it, with its own short description and its own plan. The original request stays a record of what was agreed, and each CR shows what changed and when.

7. Track progress and open questions

Two lists keep an agent-built project honest:

• Progress: which plan tasks are done. If commits carry task numbers, this list builds itself.
• Open questions (to-dos): things that need a decision from you or the client, and work you deliberately deferred. When an agent asks something you cannot answer right now, ask it to record a to-do instead of letting the question disappear in the terminal.

What goes in files, and what can stay in chat?

The test is simple: if a future session, or a future you, would need it, write it down in the project.

A weekly rhythm for a PM directing agents

A loop needs a cadence, or review and tracking get skipped when building is going well.

• Monday: read new client material, update or write requests for the week, ask agents for plans. Review plans before any execution starts.
• Tuesday to Thursday: run execution. Check waiting sessions a few times a day rather than living in the terminal. Do reviews in batches, for example late morning and late afternoon.
• Friday: walk the to-do list. Answer what you can, send the client the questions only they can answer, mark deferred items as deferred. Check plan progress against what you promised. Write a short status note for the client from the plan, not from memory.

Thirty minutes on Friday prevents most "I thought that was done" moments.

How PMDesk supports this loop

PMDesk is a macOS desktop app built for this kind of work: one person, or a small group, directing Claude Code or Codex agents across several projects. It does not include an AI model; it runs the Claude Code or Codex you already use, under your own subscription. Here is how it maps to the loop:

• Intake: register the client's document folders (Box, Google Drive or any folder). You browse them in PMDesk and the agent reads files in place. PMDesk never writes there.
• Requests and CRs: write requests and change requests in PMDesk and hand one to an agent in one click, which starts a new session. Type @ in a request or comment to reference a project file or a client document.
• Plans and progress: the Tasks pane on the Terminal page shows plan tasks and the subagents Claude Code delegated to. A task is ticked when a commit mentions it, and the Requests page shows plan progress.
• Staying reachable: each project has its own tab with the agent in a real terminal, and sessions keep running in the background (5 at once by default, configurable). A "Waiting" badge on the session, the project tab and the sidebar shows when an agent has finished its turn or asks for permission, with an optional macOS notification. You can resume, rename or archive sessions from history.
• Review: read the Markdown and HTML the agent produces, comment on specific passages, and send all your fixes to the agent at once.
• Open questions: to-dos you or the agent add, sorted by priority, with a status and a link back to the session that wrote them.

Project data stays in the project folder on your machine. You can download PMDesk for Mac, and browse ready-made skills for agents in the skills marketplace.

FAQ

Can a non-technical PM use Claude Code?

Yes, for a large part of the work: writing requests, reading the agent's plans and summaries, checking the result against "done when", and tracking progress. Claude Code runs in a terminal, so expect a short learning curve, or use a tool that keeps the requests, plans and review outside the terminal. Code review on risky changes still needs someone who reads code.

What does a PM do when AI agents write the code?

The PM writes requests the agent can act on, answers the agent's questions quickly, reviews the output against the request, and tracks progress and open questions. Writing and decision speed matter more than in a human team, because the agent fills every gap in a request with a guess.

Can one person deliver a product with AI coding agents?

For many internal tools, client projects and small products, yes, as long as that person owns requirements, review and tracking. The agents handle most of the building. Plan for human review on anything touching security, payments or personal data, and keep decisions in files so new sessions can pick them up.

How do I review AI-generated code without reading every diff?

Check the result against the request instead: run the "done when" checks yourself, confirm the requested tests exist and pass, ask for the list of changed files to catch scope creep, and read the agent's plans and summaries. Read code in detail only where the risk is high.

How should I write a spec for Claude Code or Codex?

Keep it short and in a file: why the change is needed, what exactly to build, what is out of scope, how you will know it is done, and which documents to read. Then ask the agent for a plan with numbered tasks and review that before any code is written.

How do I manage multiple Claude Code agents as a PM?

Give each project its own session, keep requests and plans in files so any session can continue the work, and use a setup that tells you which agent is waiting for you. See our guide on managing multiple Claude Code sessions for the details.