The agentic coding workflow
Coding agents are fast, but speed in the wrong direction is expensive. Teams that get great results all use some version of the same workflow: understand first, agree a plan, change code in small reviewable steps, and prove every step. It works the same in all five tools.
1. The idea
The workflow has four stages, plus a habit at the end:
- Map: explore the relevant code without changing anything, then write a short spec: what "done" means, the edge cases, and what must not change. You review the spec; it's the highest-value review you'll do.
- Plan: the agent proposes the steps (in plan mode, so it can't edit yet). You check the order, the migrations, the tests, and anything touching security or data.
- Slice: implement one step at a time: one slice, one diff you can actually read, one test run, one commit.
- Prove: run the real checks (build, tests, linters), look at the running app for UI changes, get an AI review and then a human review. A person owns the merge.
- Keep the knowledge: any rule you had to repeat goes into AGENTS.md; any repeated multi-step task becomes a skill (Modules 09 and 11).
2. How it works
Follow one real feature (splitting a stock batch into two lots) through the whole workflow: what you tell the agent, and what you check.
3. Try it yourself: review the agent's plan
An agent proposed this plan for "add a discount_code field to orders". Three steps have problems. Click the steps you'd push back on, then check your answers.
4. Why it matters at work
Prompts for each stage, which work in any of the five tools:
| Stage | Say this |
|---|---|
| Map | "Read how batches are received end to end: the API, service, database and screen. Don't change anything. Summarise the flow and list the files." |
| Spec | "Draft a one-page spec: user story, rules, edge cases, what must not change, how we'll test it. Ask me about anything ambiguous." |
| Plan | "Plan only, no edits. Steps of under 200 changed lines each, tests first where rules matter." |
| Slice | "Implement step 1 only. Run its tests. Stop and show me the diff." |
| Prove | "Run the build, the full tests and the linter, and show the output. What could be wrong that the tests wouldn't catch?" |
| Review | "Review this diff as a strict senior engineer: correctness, security, tests, conventions. Rank by severity." |
| Keep | "Add the rule we discovered to AGENTS.md, with one line explaining why." |
5. In your five tools
Two features make this workflow safe: a way to plan without editing, and a way to undo. Checked October 2026.
| Tool | Plan without editing | Undo |
|---|---|---|
| Claude Code | Plan mode: Shift+Tab until the status bar shows plan mode on, or claude --permission-mode plan | Checkpoints: /rewind (or Esc twice); and git |
| Antigravity CLI | /planning turns on plan generation; plans appear as reviewable artifacts | /rewind (also /undo); /diff to inspect changes; and git |
| GitHub Copilot (VS Code) | The Plan agent in the chat's agent picker | Restore checkpoint in the chat; and git |
| Cursor | Plan mode: Shift+Tab in the chat input | Restore on any checkpoint in the chat; and git |
| Codex CLI | /plan | Git (and /review before committing) |
Git is the universal undo. Commit after every green slice and you can always get back to the last good state, whichever tool you use.
6. Remember it
How this hook works: what “Map, plan, slice, prove” means
What the slogan means, phrase by phrase
- “Map”
- Explore the code read-only and write a spec. If the agent's summary of the code is wrong now, everything after it will be wrong.
- “plan”
- Agree the steps in plan mode before any file changes. Cheap to fix on paper, expensive to fix in code.
- “slice”
- One small step, one diff you can read, one test run, one commit. Never "implement the whole plan".
- “prove”
- Evidence, not the agent's word: build, tests, linters, the running app, an AI review, then a human review and a human merge.
Why this picture fits: it's how careful engineers already work. Agents make each stage faster, but they don't make any stage optional, and the hook keeps the order in your head when the agent is moving fast.
The story → the concept
| Stage | Agent does | You check |
|---|---|---|
| Map | Reads the code, summarises the flow, drafts a spec | Is the summary right? Edge cases and non-goals? |
| Plan | Proposes steps in plan mode | Order, migrations, tests, security and data |
| Slice | Implements one step, runs its tests | The diff: small enough to really read? |
| Prove | Runs all checks; reviews its own diff | The evidence; then you review and merge |
Watch it on an example
Feature: let warehouse staff split a stock batch into two lots.
- Map: the agent traces batch receiving through four files. You spot that it missed the expiry-date rule, before any code exists.
- Plan: five steps. You move "write the tests for the split rules" to step 1.
- Slice: five small diffs, each with green tests and a commit. Step 3 goes wrong; you roll back one commit, not the afternoon.
- Prove: the full suite, a screenshot of the new dialog in both themes, an AI security review, then your review and merge.
The trap it saves you from
"Build the whole feature" in one go: a 1,500-line diff nobody can review, built on an unchecked understanding of the code, merged on trust.
It still works when…
You automate (Module 13): CI agents follow the same stages, with the gates enforced by permissions, required checks and a human approval before merge.
7. Common mistakes
8. Hands-on lab (this is week 7 and 8 of the roadmap)
- Pick a real, small feature in your project, something a day's work or less.
- Map and spec in tool A: a read-only exploration, then a one-page spec you edit yourself.
- Plan in plan mode. Change at least one thing in the plan before approving it.
- Slice and prove: implement step by step, committing each green slice. Ask the agent what the tests wouldn't catch.
- Repeat in tool B from the same spec. Compare diff quality, time taken, and how often you had to correct each tool.
- Write your own AI coding rules: when to use agents, what must be reviewed, and what never goes in a prompt.
9. Self-check quiz
Which review saves the most time overall?
What does one "slice" look like?
You've corrected the agent on the same issue three times. Next move?
What's the undo that works in every tool?
10. Go deeper
| Resource | Time | Why |
|---|---|---|
| Best practices (Claude Code) | 25 min | Explore-plan-code-commit, context management and verification, from the tool's makers. |
| Common workflows (Claude Code) | 20 min | Recipes for exploring, debugging, refactoring, testing and pull requests. |
| Plan Mode (Cursor) | 10 min | How another tool implements the plan-before-coding stage. |
| Antigravity CLI best practices (Google) | 15 min | Google's guidance for its terminal agent. |