Day 17 of 21

Big-build planning - handle complex multi-file tasks safely

Goal: Day 3 taught you how to ask for a plan on a small task. Today you handle something bigger — a feature that touches multiple files across multiple phases. You will learn how a big-build plan looks different from a small one, how to spot when a plan is too large, and how to split it into phases you can approve one at a time.

What to do

See what a big-build plan looks like — and why it is different from Day 3

On Day 3 you asked for a plan that covered one file and one change. A big-build plan may cover five to ten files, interdependencies between them, and multiple phases. The danger with a big-build plan is approving it all at once — that gives Codex permission to change many things before you see any of it. Here is what a multi-file plan looks like, and what the warning signs are.

Example big-build plan — task: add a "Features" section to three pages

Phase 1 (safe to approve alone):
  File: src/components/FeaturesBlock.tsx
  Action: create a new reusable FeaturesBlock component with placeholder text

Phase 2 (depends on Phase 1):
  File: src/pages/home.tsx
  Action: import FeaturesBlock and add it after the hero section

Phase 3 (depends on Phase 1):
  File: src/pages/about.tsx
  Action: import FeaturesBlock and add it at the bottom of the page

Phase 4 (depends on Phase 1):
  File: src/pages/pricing.tsx
  Action: import FeaturesBlock and add it below the pricing table

Warning signs in any big-build plan:
- More than 3 files in one phase
- Vague actions like "update as needed" or "refactor for consistency"
- Phase 1 touches a shared file like a layout, nav, or global stylesheet
- Any phase mentions "install", "configure", or "setup"

Ask Codex to structure the plan as phases and save it before coding

If Codex gave you a flat list of changes, ask it to restructure into phases. Each phase should be independently reviewable — meaning if Phase 1 is done and Phase 2 fails, the site should still work with just Phase 1 complete. Once Codex produces a phased plan you are happy with, save the plan to a text file or your notes before approving anything. A saved plan is your reference point if something goes wrong mid-build.

Restructure this plan into phases. Each phase must:
1. Be independently deployable (the site works with just this phase done)
2. Touch no more than two files
3. Have a clear, specific action for each file
4. Be ordered from lowest risk (new files) to highest risk (changes to existing shared files)

After structuring, save the phased plan as text so I can review each phase before approving.
Do not start any work until I approve Phase 1 specifically.

Ask Codex for a risk map before approving any phase

Before you approve Phase 1, ask Codex to rate the risk of each phase. This gives you an honest picture of where the danger is. Low risk means the change is isolated — only one file changes and it is not shared across pages. High risk means the change affects a shared file, a global setting, or something that could break multiple pages at once. Always do high-risk phases last — and always in their own separate session.

For each phase in this plan, rate the risk as LOW, MEDIUM, or HIGH.
Use these definitions:
- LOW: the change is to a new file or a file only used on one page
- MEDIUM: the change is to a file used on two or three pages
- HIGH: the change is to a shared component, layout, global stylesheet, or navigation

For each HIGH-risk phase, tell me:
- What would break if this phase went wrong?
- Is there a safer order to do these phases?

Approve Phase 1 only — stop before Phase 2

With the phased plan saved and the risk map reviewed, approve only Phase 1. Be explicit in your approval — name Phase 1 and tell Codex to stop before Phase 2. Watch what Codex does. After Phase 1 is complete, check GitHub Desktop before continuing. The diff should match exactly what Phase 1 described. Only approve Phase 2 after Phase 1 has been reviewed and confirmed in the browser.

Approved: Phase 1 only.
Phase 1 is: [NAME WHAT PHASE 1 DOES — e.g. "create FeaturesBlock component"]
Stop completely after Phase 1. Do not start Phase 2 until I explicitly say "Approved: Phase 2."
After Phase 1, show me:
- Which files changed
- What specifically changed in each file
- Whether the site still works with only Phase 1 complete

Review Phase 1 before deciding whether to continue

Before approving Phase 2, do a full Phase 1 review. Open GitHub Desktop and read the diff. Preview in your browser if Phase 1 is visible. Ask yourself: does Phase 1 work on its own, If yes, commit Phase 1 with a message like "Phase 1: create FeaturesBlock component" and then proceed to Phase 2. If Phase 1 has an issue, fix it before approving Phase 2. Never stack phases on top of a broken earlier phase.

Expected result

You have a phased big-build plan saved as text, a risk map showing which phases carry the most risk, Phase 1 approved and committed as a standalone checkpoint, and a clear decision about whether to continue to Phase 2 or stop for today.

Key takeaway

Big builds are small builds repeated. The only difference is the number of phases. Save the plan before coding. Approve one phase at a time. Commit each phase before starting the next. Never approve Phase 2 if Phase 1 is not working yet.

Day 16 Day 18