The walking-stage cheat sheet

Why preflight matters

Week 1 assumes you can already operate Claude Code against a real repo competently — that running an agent on your working code is not a novelty for you. If that’s already true, skim this page and move on. If not, the six items below are the missing rungs.

None of them require special tooling beyond Claude Code itself and your existing dev environment. Each one is small. The point is to do them at least once on real work so that by Week 1, the basic mechanics aren’t in the way of the principle-and-routine work.

One framing for the whole list: stop doing manually anything an agent can do for you on your real codebase. Each item is one piece of the manual-to-agent handoff.

The six items

1. Don’t write code manually

Open Claude Code in your real repo (not a sandbox). Pick one PR-sized piece of work that’s in your queue. Brief Claude on what you want. Let it write the code. Iterate by talking to Claude in plain language, not by editing the files yourself.

Goal: ship one PR end-to-end where you wrote zero production code yourself.

What you’ll notice: the temptation to “just fix this one line’’ is strong. Resist it. The discipline this week is staying in the briefing role even when typing would be faster for this one change.

2. Don’t write specs / tests manually

Pick a feature in flight. Ask Claude to generate the spec, the unit tests, and the e2e tests. Refine by talking to Claude: “the spec missed this edge case,” “the e2e test needs to cover the partner-portal path too.” Let Claude rewrite. Don’t open the files in your editor to tweak.

Goal: one feature’s spec + unit + e2e tests, all generated and refined by Claude based on your verbal direction.

What you’ll notice: the specs and tests are often better than what you’d have written by hand — because Claude is methodical about edge cases you’d skim over.

3. Don’t scan logs manually

Pick a real bug or anomaly in your local dev or staging environment. Ask Claude to scan the logs, identify candidate root causes, and propose a fix. Iterate by giving Claude more context, not by reading the logs yourself.

Goal: diagnose one real bug end-to-end with Claude as the log-reader.

What you’ll notice: Claude reads more log lines per minute than you do, and cross-references across services in a way that’s tedious to do by hand.

4. Don’t cross-check systems manually

Pick a debugging task that spans 2+ systems — backend logs + frontend console + database state, for example. Ask Claude to cross-reference and report back. Don’t open three terminal tabs and a database client yourself.

Goal: one multi-system investigation where Claude does the cross-referencing and you read the summary.

What you’ll notice: the cross-system-cross-tab investigation pattern is one of the biggest hidden time sinks in traditional debugging. Handing it to Claude collapses the cost.

5. Don’t write migrations / run tests manually

Pick a migration in flight (database schema change, config change, anything that needs a forward + rollback path). Ask Claude to write the migration, generate the rollback, run your local test suite, and report what passed.

Goal: one migration shipped with Claude running the test suite and confirming green before you review.

What you’ll notice: the rollback path gets written more thoroughly than it usually does — because Claude doesn’t skip it for time.

6. GitHub admin handled by AI

Pick one work-stream. Hand off the git operations to Claude: branch creation, worktree setup, scaffolding the change, the rebase, the push, the PR creation. Don’t touch the git CLI yourself for routine ops on this work-stream.

Goal: one PR opened and merged where Claude owned every routine git operation.

What you’ll notice: branch / worktree / rebase mechanics that you’d normally do by hand are done faster and more consistently when an agent owns them. This becomes reflexive across multiple parallel branches in Week 2.

The “no IDE” insight

If you’ve been using Cursor, Windsurf, or VS Code with AI plugins, notice this: working through the six items above, you may not need the IDE at all anymore. You’re no longer changing code by typing. The text editor was the interface for the old mode of work.

Inspection still matters. The cleanest path: look at PRs (the diff view is the right size for what you need to review), or use a lightweight git client like SourceTree if you want to read code in flight. Understanding what’s going out is your first quality gate. But the IDE itself — the heavyweight editor with autocompletion, linting, refactoring tools — was built for a workflow you’re leaving behind.

This isn’t an instruction to uninstall your IDE. It’s a noticing: a lot of the IDE features you used to value stop mattering when the agent is the one editing.

Self-check — are you ready for Week 1?

You’re ready if you can honestly answer yes to most of these:

• You’ve shipped at least one PR where you wrote zero production code yourself.
• You’ve had Claude generate a real spec + tests for a feature, and the result was usable (not a toy).
• You’ve used Claude as your primary log-scanner on at least one real bug.
• You’ve handed a multi-system debugging task to Claude and read the synthesized report.
• You’ve done at least one git work-stream where Claude owned all routine git operations.
• You’ve noticed that some of the IDE features you used to care about don’t matter as much anymore.

If most of these are still “not yet,” spend another week or two on the items that aren’t reflexive before moving to Week 1. The course compounds on these being already-installed muscle. Skipping the preflight is the most common reason teams stall in Week 2 — not because Week 2 is hard, but because the substrate from preflight wasn’t there.

About time

Total time across the six items is roughly 10 hours of focused work, integrated into your normal week. Most engineers do this across 1–2 calendar weeks before starting Week 1. If you have less time, prioritize items 1, 3, and 6 — those are the foundations the other three build on.