Home / Guides & Tutorials / The AI Coding Workflow That Ships: From …

CHAPTER 6 OF 7 · 8 min · 3 COPYABLE ASSETS

How to turn a plan file into working code with Claude Code (/plan and /implement)

Create a plan.md carrying every implementation detail (patterns, files, task order, validation), then execute it in a brand-new session with the /implement command.

TL;DW

The /plan command converts your exploration into a single plan.md artifact: summary, locked-in decisions, patterns to follow, the exact files to create or change, task order, and a self-validation strategy covering type-checks, linting, unit tests, and even browser automation. Then comes the critical move. You implement in a brand-new session with /implement path/to/plan.md. The plan carries all the context, the fresh agent brings unbiased eyes, and it writes the code, validates its own work, and hands back to you for code review.

Watch: FULL Guide to Becoming a Principled Agentic Engineer (Build Anything with AI)

▶ Watch this chapter on YouTube from 49:06

Lesson · 7 parts

After the subagent research, the agent presents a synthesis with real decisions to make. In production work you would chew through those carefully. On camera Cole delegates: go with your recommendations. Either way, the planning output must be a single artifact holding everything the implementing agent will need.

The invocation

/plan Go with your recommendations and create the plan for AT-22.

The command phases the agent through research, codebase exploration, then writing plan.md. Where the PRD stayed at requirements level, the plan lives in the weeds, and its structure is the contract.

Each ingredient exists to kill a specific failure mode. Locked decisions stop the implementing agent from re-litigating choices you already made. Patterns-to-follow stops it from inventing a second style in a codebase that already has one. The explicit file list keeps the diff surface small and reviewable. Task order gives the agent a spine for its internal todo list instead of improvising sequence. And the validation section decides in advance what 'done' means, so the agent finishes to a standard rather than to a feeling.

What every plan.md must contain

Summary plus user story
Decisions locked in during exploration
Patterns to follow from your existing codebase
Exact files to create or change
Task order for the agent's internal todo list
Self-validation strategy: type-check, lint, unit tests, optional e2e

Cole is comfortable handing all the coding to the agent for one reason. He never left the driver's seat: he shaped the exploration, answered the questions, iterated the plan. The agent then also writes the unit tests, integration tests, linting, and type checks, so that when control passes back to a human, far less remains to correct. The engineer stops being the bottleneck.

The generated plan shows the work summary, the locked decisions, the files to create and update, and a granular task list. That list is intentionally not ticket material; it is one implementation's internal checklist. Self-validation is spelled out too, and can extend to real end-to-end testing: the agent-browser skill can open the app, create polls, and vote like a user.

The counterintuitive core of the PIV loop: with the plan ready, do not implement here. The planning conversation has accumulated bias, and a fresh session gets clean eyes. Since plan.md carries every needed detail, there is no reason to stay in the old context window.

Two concrete things change with the fresh session. Context quality: the planning chat is full of dead ends, rejected options, and subagent noise, and none of it should influence code. Verification: the implement command makes the new agent re-check the plan's assumptions against the codebase before writing, which means a second pair of eyes reviews your plan for free.

This also mirrors how a real team works. The person who wrote the ticket is rarely the person typing the code, and the handoff artifact is what keeps that safe.

Fresh session, one argument

/implement .agents/plan-at22.md

Cole's /implement runs a couple hundred lines, because the plan drives the development. The command only encodes process: load the plan, cut a git branch, re-verify assumptions with a second pass, run the validation, and know when to hand control back. Whatever your team's engineering rituals are, they get encoded here.

Some people ship agent code straight to production. Cole does not: 'the engineer in me still wants to review all the code,' plus manual testing before any merge to main. Meanwhile the implementing agent builds its internal task list from the plan and moves fast. A simple, well-planned feature is quick work.

Study notes

Part 1 of 7 · 49:06 to 50:02

Run /plan: exploration becomes an artifact

Concept Planning output must be a single artifact, and for tickets that artifact is plan.md: the document the implementing agent will execute against with no other context available to it. Whatever is not in the plan does not exist for the implementer.

Why it matters The synthesis decisions the agent presents before writing are the engineering: real options with real trade-offs. On camera they get delegated for pace; on your work, these few minutes are where your judgment earns its keep, because every locked decision saves a wrong guess downstream.

Do this

Answer the agent's synthesis decisions, or delegate with the /plan invocation from the lesson panel.
Wait for plan.md to be created.

Part 2 of 7 · 50:02 to 51:08

Inside the plan: six required ingredients

Pitfall Naming collision alert: /plan here is Cole's custom command. Claude Code also ships a built-in feature called plan mode. Same word, unrelated machinery. If you ask a teammate why plan mode wrote a file to .agents, this paragraph is the answer.

Concept The document's structure is the contract between planner and implementer: summary and story for orientation, then the sections a PRD never carries. Where the PRD said what, the plan says how, down to file level, and the checklist in the lesson panel is the full inventory.

Do this

Open plan.md.
Check it against the six-ingredient checklist from the lesson panel.

Part 3 of 7 · 51:08 to 52:15

Why full delegation is safe here

Why it matters Each plan ingredient kills a named failure: locked decisions stop the implementer re-litigating choices, patterns-to-follow stops style invention, the file list keeps diffs reviewable, task order gives the agent a spine, and pre-agreed validation defines done before the work starts rather than after it ends.

Concept Delegation is safe here for one reason only: the driver's seat was never vacated. You shaped the exploration, answered the questions, iterated the plan. The agent extends decisions you already made. Remove those steps and the same delegation becomes gambling with a nicer interface.

Concept Validation is delegated too: unit tests, integration tests, linting, and type checks are all written and run by the agent as part of implementation. The design goal is that human review receives work that is already mostly right, so your attention goes to judgment calls, not typos.

Do this

Confirm the plan's validation section lists tests, linting, and type checks before you proceed.

Part 4 of 7 · 52:15 to 53:41

Review the plan file

Concept Read the generated plan the way the implementing agent will: the summary, the locked decisions, the exact files to create and update, the ordered task list. If a file on that list surprises you, resolve the surprise now, while it costs a sentence instead of a revert.

Pitfall The granular task list is internal scaffolding for one implementation run. Promoting those micro-tasks into JIRA buries your board in noise the moment you do it, and the ticket already represents this work at the right resolution. Leave the scaffolding inside the plan.

Try it If the feature has any UI at all, add end-to-end validation to the plan before running it: the agent-browser skill can open the app, click through the flow, and screenshot the result. One line in the validation section now replaces a manual test later, permanently.

Do this

Read the file list and task order. Fix anything that touches files it should not.
Add agent-browser e2e validation if the feature has a UI.

Part 5 of 7 · 53:41 to 54:45

Implement in a BRAND-NEW session

Why it matters The fresh-session rule returns with a sharper rationale this time: the planning chat has accumulated bias in the form of dead ends, rejected options, and half-formed ideas. The implementing agent should meet the plan, not the mess that produced it. Clean context in, clean execution out.

Concept The handoff is one line in a brand-new session: /implement with the plan path. Because the document carries all context, the handoff also works across people and across time. Whoever, or whatever, runs implement does not need to have been present for planning.

Do this

Open a fresh session.
Run the /implement command from the lesson panel with your plan path.

Part 6 of 7 · 54:45 to 55:49

The implement command is tiny on purpose

Concept The implement command is deliberately tiny, a couple hundred lines, because the plan carries the substance. The command encodes only process: load the plan, cut a branch, verify assumptions, execute, validate, hand back. Whatever rituals your team has, this file is where they get encoded.

Why it matters The assumptions re-check is a free second review: a fresh agent validates the plan against the codebase before writing anything. Two independent readings of the same document catch what a single author misses, and you get that redundancy without adding a human to the loop.

Do this

Skim the implement command once so you know the process it enforces: branch, verify, validate, hand back.

Part 7 of 7 · 55:49 to 57:12

Validation ends with a human code review

Concept The last gate stays human: Cole reviews all production code himself, plus manual testing, before anything merges to main. Shipping agent-written code unread is a real practice in the wild; he names it and declines it, and this course does the same.

Why it matters Delegating the typing never delegated the responsibility. The diff review is where you exercise it, with the plan open beside the code, asking one question: does this implementation match the contract I wrote? Review against the plan, not against your memory of intentions.

Example On screen you can watch the payoff land: the agent turned the plan's task order into its internal todo list and is executing it without wandering. That speed is not the model being clever. It is the compounding return on every planning step you just learned.

Do this

When control returns, review the diff like any pull request.
Run the app yourself before merging.

Key terms

plan.md: The single artifact carrying everything an implementing agent needs: decisions, files, task order, validation.
Plan mode: Claude Code's built-in planning feature; unrelated to the custom /plan command used in this course.
Self-validation: Tests, linting, and type checks the agent runs on its own output before human review.

Key takeaways

The plan artifact contains everything implementation needs, which is exactly why implementation can and should happen in a different session.
Have the agent validate as much as possible (tests, linting, type checks) so less needs correcting when control returns to you.
Planning sessions accumulate bias. A fresh implementing agent gets clean eyes on the problem.
The engineer still reviews production code. Delegating the writing is not delegating the responsibility.

Watch out

/plan here is Cole's custom command, not Claude Code's built-in plan mode. Same word, different things.
The granular task list inside plan.md serves one agent's internal run. Do not promote those micro-tasks into JIRA tickets.

Check your understanding

Why must implementation happen in a different session from planning?

The planning session has built up bias, and a fresh agent gets unbiased eyes. The plan.md artifact carries all the needed context, so nothing is lost by switching.

Why is the /implement command so short?

Because the plan guides the entire development. The command only encodes process: load the plan, branch, verify assumptions, validate, hand back.

01 49:06 Step Run /plan: exploration becomes an artifact ▾

02 50:02 Concept Inside the plan: six required ingredients ▾

03 51:08 Concept Why full delegation is safe here ▾

04 52:15 Step Review the plan file ▾

05 53:41 Watch out Implement in a BRAND-NEW session ▾

06 54:45 Concept The implement command is tiny on purpose ▾

07 55:49 Concept Validation ends with a human code review ▾