InterviewKata
AI engineering · Module 08 of 21 · Level 2: Working with AI

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

A good surgeon doesn't start cutting the moment you walk in. They examine you, agree the procedure with you, operate in careful stages, check vital signs after each, and write up the notes for the next doctor. Skipping any of those makes surgery faster and much more dangerous.

The workflow has four stages, plus a habit at the end:

  1. 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.
  2. 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.
  3. Slice: implement one step at a time: one slice, one diff you can actually read, one test run, one commit.
  4. 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.
  5. 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

The yellow gates are where you check. Most of the time saved by agents is lost when one of those gates is skipped.

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:

    StageSay 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."
    The three-corrections ruleIf you've corrected the agent on the same thing three times, stop. Either the spec is unclear (rewrite it and start a fresh session) or the task is faster to do yourself. An agent is a fast junior engineer with a perfect memory for syntax and none for your intent.

    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.

    ToolPlan without editingUndo
    Claude CodePlan mode: Shift+Tab until the status bar shows plan mode on, or claude --permission-mode planCheckpoints: /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 pickerRestore checkpoint in the chat; and git
    CursorPlan mode: Shift+Tab in the chat inputRestore on any checkpoint in the chat; and git
    Codex CLI/planGit (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

    Memory hook: "Map, plan, slice, prove"Understand before changing, agree before building, change in small steps, and never merge without evidence.
    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

    StageAgent doesYou check
    MapReads the code, summarises the flow, drafts a specIs the summary right? Edge cases and non-goals?
    PlanProposes steps in plan modeOrder, migrations, tests, security and data
    SliceImplements one step, runs its testsThe diff: small enough to really read?
    ProveRuns all checks; reviews its own diffThe evidence; then you review and merge

    Watch it on an example

    Feature: let warehouse staff split a stock batch into two lots.

    1. Map: the agent traces batch receiving through four files. You spot that it missed the expiry-date rule, before any code exists.
    2. Plan: five steps. You move "write the tests for the split rules" to step 1.
    3. Slice: five small diffs, each with green tests and a commit. Step 3 goes wrong; you roll back one commit, not the afternoon.
    4. 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

    Merging on the agent's word"All tests pass" is a claim until you've seen the output. A person reviews and owns every merge.
    Skipping the specWithout agreed edge cases and non-goals, you'll discover them one correction at a time.
    Giant diffsIf you can't review it properly, you can't approve it. Slice smaller.
    No commits between slicesThen one bad step means losing everything since the last commit. Commit every green slice.
    Losing what you learnedA rule you explain in chat today is gone tomorrow. Put it in AGENTS.md.

    8. Hands-on lab (this is week 7 and 8 of the roadmap)

    1. Pick a real, small feature in your project, something a day's work or less.
    2. Map and spec in tool A: a read-only exploration, then a one-page spec you edit yourself.
    3. Plan in plan mode. Change at least one thing in the plan before approving it.
    4. Slice and prove: implement step by step, committing each green slice. Ask the agent what the tests wouldn't catch.
    5. Repeat in tool B from the same spec. Compare diff quality, time taken, and how often you had to correct each tool.
    6. 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?

    Fixing a misunderstanding in a one-page spec takes minutes; finding it in finished code takes hours.

    What does one "slice" look like?

    One step, one readable diff, one test run, one commit: easy to review and easy to roll back.

    You've corrected the agent on the same issue three times. Next move?

    Repeated corrections mean the brief is unclear or the task isn't a good fit. A fresh session with a better spec usually wins.

    What's the undo that works in every tool?

    Checkpoints differ by tool; a commit history works everywhere and survives sessions.

    10. Go deeper

    ResourceTimeWhy
    Best practices (Claude Code)25 minExplore-plan-code-commit, context management and verification, from the tool's makers.
    Common workflows (Claude Code)20 minRecipes for exploring, debugging, refactoring, testing and pull requests.
    Plan Mode (Cursor)10 minHow another tool implements the plan-before-coding stage.
    Antigravity CLI best practices (Google)15 minGoogle's guidance for its terminal agent.