1. A TDD Loop: Write the Test, Let Claude Code Make It Pass
Write (or ask Claude Code to write) a failing test first, then explicitly instruct it to make the test pass without modifying the test itself. This turns Week 10's "give it something to verify against" into the strongest version of that idea: the test isn't just a check afterward, it's the actual specification of what "done" means.
> Here's a failing test for a discount calculator:
[paste the test]
Make this test pass. Do not modify the test file. If you think the
test itself is wrong, stop and tell me why instead of changing it.
That last sentence matters: without it, an agent under pressure to "pass the test" might quietly edit the test to match whatever it produced, which defeats the entire point. Making the constraint explicit closes off the shortcut and keeps the test as genuine, independent ground truth.
A vague feature request often turns into a precise one the moment you try to write a test for it — edge cases you hadn't considered tend to surface right there, before any implementation exists to get attached to.
2. Large Refactors & Multi-File Changes
For a change spanning many files, don't let the first thing Claude Code produces be one giant, unreviewable diff. Ask for a plan first — the list of files it thinks need to change and why — before it touches anything, then execute in reviewable chunks with verification after each one.
> Before making any changes: list every file you think needs to change
to rename `userId` to `accountId` across this codebase, and briefly
note why each one is affected. Don't edit anything yet.
# Review that list. THEN:
> Proceed with the first 3 files from that list, run the test suite
after, and stop before continuing to the rest.
This front-loads your review effort onto the plan — much cheaper to catch "wait, you missed the migration file" before 15 files have changed than after. Running tests after each chunk also means a mistake surfaces immediately, tied to a small diff, instead of buried somewhere in one massive changeset at the very end.
A commit after each verified chunk gives you a clean rollback point if a later step goes wrong — you lose one chunk's work, not the entire refactor.
3. Code Review & Git/PR Workflows
Claude Code is useful on both sides of a pull request: reviewing your own diff
before you open one (Week 11's /review command in action), and drafting
the commit message or PR description that summarizes it — grounded in the actual
diff, the same grounding discipline from Week 3 and Week 4.
> Look at the actual staged diff (git diff --staged) and write a commit
message: a one-line summary, then 2-3 bullet points on WHY this
change was made, not just what changed. Base it only on what's
actually in the diff.
> Now review this same diff as if you were a careful teammate — flag
any risk, missing test coverage, or edge case you notice.
Grounding the request in the real diff (rather than your verbal description of what you did) matters for the same reason Week 4's document-grounding did: it prevents the summary from drifting into what you intended rather than what actually changed. Always skim the drafted description against the real diff before using it — the same verification habit from every earlier week, applied here.
The same pattern works in reverse — point Claude Code at an incoming PR's diff and ask it to flag risks before you review it yourself. Treat its findings as a first pass that speeds up your review, not a replacement for actually reading the code.
4. Plan Mode for Risky Changes
For changes with real blast radius — database migrations, deleting code, anything security-sensitive — use plan mode: Claude Code proposes a complete plan (files, approach, tradeoffs) and makes zero edits until you explicitly approve it. This is the strongest version of Section 2's "review the plan before execution" idea, applied to changes where getting it wrong is expensive to undo.
LOW STAKES, SKIP THE FORMALITY:
- Renaming a local variable
- Adding a new, isolated utility function
HIGH STAKES, USE PLAN MODE:
- A database migration that could lose data if wrong
- Deleting a module you're not 100% sure is unused
- Touching authentication or permissions logic
- Any change you genuinely couldn't undo with `git revert` alone
This is the same cost/benefit shape as Week 8's extended thinking and Week 9's model tiering: extra review costs a bit of speed, and it's worth reserving for the cases where the downside of getting it wrong is large enough to justify that cost — not applied uniformly to every single change regardless of risk.
Weeks 10–12 covered installing Claude Code, configuring it (hooks, commands, subagents, MCP), and applying it to real engineering workflows. Weeks 13–14 zoom out from "using Claude Code" to the general shape of AI agents — which, as Week 7 already hinted, is largely this same tool-use loop, generalized.
5. Hands-on Exercise
Run a real TDD loop, a planned refactor, and a grounded PR description
Apply this week's three workflows to a real (or realistic) codebase.
Part 1 — Real TDD loop:
- Write one genuinely failing test for a small feature.
- Ask Claude Code to make it pass without touching the test file, and confirm it actually didn't.
Part 2 — Plan-first refactor:
- Pick a small multi-file change (renaming something used in 3+ places, extracting a shared helper).
- Ask for a plan first, review it, then execute in at least two separate approved steps with a test run between them.
If your project is small enough that a "large" refactor feels artificial, pick a change that touches at least 3 files on purpose, just to practice the plan-then-execute rhythm.
Part 3 — Grounded commit message & PR description:
- Make a real change and stage it.
- Ask Claude Code to draft a commit message and a short PR description from the actual diff.
- Check the draft against the real diff — note anything it got slightly wrong or overstated, if anything.
6. Knowledge Check
Four quick questions. Expand each to check your answer.
Q1
Why is it important to explicitly tell Claude Code not to modify the test in a TDD loop?
Why is it important to explicitly tell Claude Code not to modify the test in a TDD loop?
Without that constraint, an agent under pressure to "pass the test" could take the shortcut of editing the test to match whatever it produced, which defeats the entire purpose of the test as independent ground truth for what "done" means.
Q2
Why is reviewing a plan before a large refactor cheaper than reviewing the final diff afterward?
Why is reviewing a plan before a large refactor cheaper than reviewing the final diff afterward?
Catching a missing file or wrong approach in a short plan is far cheaper than discovering it buried inside one massive, already-completed diff spanning many files. Front-loading review onto the plan, plus running tests after each incremental chunk, catches problems earlier and smaller.
Q3
Why should you check a Claude-drafted PR description against the real diff before using it?
Why should you check a Claude-drafted PR description against the real diff before using it?
A drafted summary can drift toward describing what you intended rather than exactly what changed — the same verification habit that applies to any Claude-generated grounded content, from Week 3's citations onward, applies to summaries of your own code changes too.
Q4
What kind of change justifies the extra overhead of plan mode?
What kind of change justifies the extra overhead of plan mode?
Changes with real blast radius — data-loss-risk migrations, deleting code you're not certain is unused, security-sensitive logic, anything not cleanly undoable with a simple revert. Low-stakes, easily reversible changes don't need the extra formality.