When You Are Turning a Plan Into Code

A reference for the moments between a finished roadmap and a working first slice

How to Use This Guide

This is the Day 3.5 guide. It picks up the second the planning docs are done and the AI is about to start typing code. It is not about whether to use AI to build. It is about how not to lose the thread once it starts. Find the scenario you are in, read the two or three principles under it, and go run the next step.

When You Might Open This Guide

• You have a roadmap checked in at ai/roadmaps/ and you do not know what prompt to hand the AI first.
• The AI wrote code and you cannot tell whether it actually finished phase 1 or just most of it.
• The tests fail, the AI tries to fix them, and you are not sure if you should let it keep going or stop it.
• The AI invented a feature that was not in the roadmap.
• You are three fixes deep on the same bug and each fix makes things worse.
• You do not yet have a scripts/ folder and every time you test the app you click through the UI yourself.

When You Are About to Tell AI to Start Coding

Implement one phase at a time. Do not hand over the whole roadmap. Phase-by-phase keeps scope small enough that errors are catchable and reversible. A prompt that says “implement the whole thing” is a prompt that produces a mess only a full rewrite can untangle.

Source: Day 3.5 slides — What Happens Next (implementation flow)

The implementation prompt reads the roadmap, the architecture, and the coding style, in that order. Those three files are the contract. Without them the AI has to guess at conventions, and it will guess wrong in a way that is plausible. The prompt in the lecture literally names each file. Paste it until you have a muscle memory for it.

Source: Day 3.5 slides — The Implementation Prompt Pattern

Good signs at the start: AI reads multiple context files, asks clarifying questions, references roadmap tasks. Warning signs: AI starts coding immediately, invents features, asks no questions. Read these as literal checklist items in the first minute of the session. If you see warning signs, stop. Answering the question “is the context loaded” early is worth ten minutes of cleanup later.

Source: Day 3.5 slides — What Happens Next

If the AI is confused, it is almost always a context problem, not a prompt problem. Rephrasing does not help when the underlying aiDocs/ are thin. Better context is cheaper than a better prompt; go fix the doc that the AI is missing, then re-prompt.

Source: Day 3.5 lecture — "Context is king" principle (not covered on a dedicated public slide)

When AI Says It Finished and You Cannot Tell What Actually Got Built

Trust but verify. The verification step is not optional. After a phase completes, run the verification prompt. Ask the AI to cross-check the roadmap against actual code and report completed, missed, deviated, and extra items. No code changes, just the report. If you skip this, misunderstandings compound into the next phase.

Source: Day 3.5 slides — Did AI Build What We Planned? (Trust but Verify)

Deploy a sub-agent for verification, not the same agent that did the work. A second perspective reviews the work independently. The agent that wrote the code has motivated reasoning about how well it went; a fresh sub-agent does not. This is the quality gate between phases.

Source: Day 3.5 slides — The Complete Recipe (Step 3: Verify with a Sub-Agent)

Update the roadmap to reflect reality after verification. Check items off, add notes on changes from the plan, mark the phase complete if it is complete. The roadmap is a living document. When you come back for the next phase, the AI has to know where things actually stand, not where they were supposed to stand.

Source: Day 3.5 slides — Update Your Roadmap

Archive finished plans and roadmaps to ai/roadmaps/completed/. An active roadmaps folder with six completed docs in it confuses every future session. Move them out as soon as a phase closes.

Source: Day 3.5 slides — The Complete Recipe (Step 4: Archive When Complete)

When You Do Not Yet Have a CLI Testing Harness

When AI can test itself, you have the full loop. This is the line the lecture turns on. Without CLI scripts, testing requires a human: click through the UI, read the output, copy-paste errors back. That bottleneck slows everything down and burns your attention. With CLI scripts the AI runs the tests, reads the output, diagnoses failures, fixes code, and re-tests on its own.

Source: Day 3.5 slides — The Key Insight (AI can test itself)

The minimum viable set is build.sh and test.sh under scripts/. You do not need a test framework yet. You need two scripts that shell out to whatever you already have, set an exit code, and print JSON. That is enough for the AI to work against.

Source: Day 3.5 slides — The scripts/ Folder Pattern (minimum viable set)

What makes a CLI script AI-friendly: JSON output, proper exit codes, stderr for errors, self-contained, idempotent. Five rules. 0 for success, nonzero for failure. Data on stdout, error text on stderr. The script should set up its own environment and produce the same result on the second run as on the first.

Source: Day 3.5 slides — The Prompt (CLI script requirements: JSON, exit codes, stderr)

Cross-platform teams default to Node scripts instead of bash. Shell scripts are fine for Mac and Linux only. If any teammate is on Windows, rewrite the scripts as Node files; the child_process pattern in the lecture is five lines and portable.

Source: Day 3.5 slides — Cross-Platform Note

When Tests Fail and You Do Not Know Whether to Let AI Keep Going

Run the autonomous fix loop and step back. The prompt is “run test.sh, fix what fails, run again, continue until everything passes.” Then stop typing and watch. Stepping in on the first failure is how you lose the compounding benefit of the loop.

Source: Day 3.5 slides — When Tests Fail (autonomous fix prompt)

Let AI complete two or three full cycles before intervening. One cycle is noise. Two to three cycles tell you whether the loop is converging or spiraling. Students reach in too early almost every time, which resets the progress the AI had already made.

Source: Day 3.5 slides — When Tests Fail (step back and let AI work)

Stop the loop when the same error repeats three or more times, when fixes are getting more complex instead of simpler, or when more tests are failing than before. Those are the three intervention triggers. If none of them are hit, the loop is still working and you are not helping by stopping it.

Source: Day 3.5 slides — When to Intervene

The intervention prompt is not a fix. It is “stop, analyze, don’t change anything yet.” Ask what has been tried, what the root cause is, whether a different approach exists. No edits. You are pulling the AI out of tactical patching mode and back into diagnosis. The fix comes after, once the analysis is real.

Source: Day 3.5 slides — When to Intervene (intervention prompt)

If the context is polluted, start a fresh session. There is a point at which the current conversation has so many wrong turns in it that the AI cannot recover. The fix is not another prompt. It is a new session with a clean roadmap reference.

Source: Day 3.5 lecture — fresh-session-on-polluted-context guidance (not covered on a dedicated public slide)

The Complete Loop (Keep This Nearby)

This is the whole lab session in five rows. Run it once, start to finish, before you try to optimize any single step.

Go Deeper