From plan to pixels
Last session you and Codex wrote SITE_PLAN.md together. Today that file earns its keep: by the end of this session there is a real index.html open in your browser, styled the way you described, and you'll have iterated on it three times based on what you SAW, not what you guessed. The build loop you run today is the same loop you'll run in every session after - and eventually on every project you touch.
The build loop 5 min live
Working with Codex isn't one big prompt and a prayer. It's a small loop, run many times: plan the next slice, let Codex build it, run the result yourself, review what you see, feed that back in. Small laps, compounding fast.
LiveReview is where YOU add the value3 min▶
Codex handles plan and build well on its own. The run and review steps are yours, and they're the difference between people who ship with agents and people who churn with them:
- Always run it yourself. Codex can verify code executes; only you can verify it looks and feels right. Open the page. Resize the window. Click the links.
- Ask before you approve. When Codex proposes a change you don't follow, ask "explain what this change does and why" BEFORE saying yes. You're not slowing it down - you're training yourself.
- Review the diff, not the vibes. After each change, Codex shows what it touched. Skim it. Even a beginner's skim catches "wait, why did it edit that file?"
The two-browser habit: experienced Codex users keep the terminal and the browser side by side and hit refresh after every lap. The feedback loop drops from minutes to seconds - and the shorter the loop, the braver your experiments get.
LiveIterating like a pro: name the fix, don't re-roll3 min▶
When the first result isn't right (it often isn't - that's the loop working, not failing), you have two moves. One of them wastes your credits and your evening:
The fluent move is naming the fix, not re-rolling. "Try again" throws away everything that was already right; a named fix keeps the 90% that worked and repairs the 10% that didn't. Point at what you see: colors, spacing, sizes, words.
Self-studyHow big should one lap be?2 min read▶
- One lap = one thing you can check. "Homepage skeleton" is a lap. "The whole site with all three sections, polished" is five laps pretending to be one.
- If the review step takes longer than the build step, your lap was too big - you can't hold that much change in your head at once.
- Commit the wins. Once a lap looks good, ask Codex to note what state you're in ("summarize what we built and what's next in a NOTES.md"). Session 5 upgrades this habit to real git commits.
AGENTS.md, first version 5 min live
Anything you find yourself repeating to Codex belongs in a file it reads automatically at the start of every conversation. That file is AGENTS.md, and /init writes the first draft for you.
Live/init and what belongs in v13 min · then Demo 1▶
Run /init in your project folder and Codex inspects what's there, then generates an AGENTS.md describing the project - purpose, structure, conventions it can detect. That draft is a starting point; the value comes from what YOU add. For the site project, v1 needs exactly four things:
- Project purpose: what this site is and who it's for - so every suggestion fits the mission.
- The plain-code boundary: no frameworks, no build step - stated once here instead of in every prompt.
- Design taste: the adjectives from your SITE_PLAN.md, so "make it look good" means YOUR good.
- File layout rules: which files exist and where new things go - stops the folder sprawling.
LiveAGENTS.md rule or one-off prompt? The sorting test2 min▶
| It's an AGENTS.md rule if... | It's a one-off prompt if... |
|---|---|
| It's true every session ("no frameworks") | It's about today's task ("build the homepage") |
| You've now typed it twice | You'll probably never say it again |
| It describes taste or standards | It describes a specific change |
| Forgetting it causes rework | Forgetting it costs nothing |
Self-studyThere's a hierarchy (preview of Session 3)2 min read▶
The AGENTS.md you made today lives at your repo root and governs this project. Two more levels exist:
- Global:
~/.codex/AGENTS.md- preferences that follow you across EVERY project (your name, your universal habits). - Repo root: what you built today - this project's rules.
- Subdirectory: an AGENTS.md inside a subfolder applies only there - useful when one part of a project plays by different rules.
More specific wins where they overlap. Session 3 goes to full depth, including what belongs at each level and how skills fit next to it.
Permissions, full depth 4 min live
Session 1 introduced the safety dial. Now that Codex is about to write real files for you, let's understand every notch on it - and when to turn it.
LiveThe three levels and the sandbox4 min▶
| Level | What Codex may do | Right for |
|---|---|---|
| Read-only | Look at files, explain, plan - touch nothing | Exploring an unfamiliar project, pure Q&A |
| Auto-edit in folder | Create and edit files inside the project folder without asking each time; commands still need approval | Active building - today's default for my-site |
| Command approval levels | Run commands, from ask-every-time up to broader trust for commands you've whitelisted | Once you recognize the commands it keeps asking about |
- The sandbox boundary is the real safety net: whatever the level, Codex works inside your project folder. Anything beyond it - other folders, the network, system changes - triggers an explicit ask. Your my-site folder is a walled garden.
- Promote as trust builds: start a project cautious, notice which approvals you always grant, then raise the level so the loop runs faster.
/permissionschanges it any time, per project. - Check where you stand with
/status- it shows the current model, permission level, and folder in one glance.
The pattern nearly everyone follows: week one, they read every diff and approve every command. Week three, file edits are auto-approved and they only gate commands. The dial exists precisely so trust can be earned in stages instead of demanded up front.
/init your project ★ 5 min · everyone runs it
In your my-site folder, run codex (or codex resume to continue last session's conversation), then run /init.
Read the generated AGENTS.md top to bottom. Notice what Codex figured out on its own from SITE_PLAN.md and the folder contents.
Add two personal rules it couldn't have guessed - your design taste line and your working-style preference (like the diff summary rule from the Part 2 example). Just tell Codex: "Add these two rules to AGENTS.md: ..."
Sanity check: ask "What rules are you following from AGENTS.md right now?" - hearing it recite your rules back makes the file feel real.
Build the homepage from SITE_PLAN.md ★ 12 min · everyone builds
Fire the build prompt - GCOB, with your plan as the context:
Follow its viewing instructions - usually just opening index.html in your browser. Look at YOUR homepage. Take a breath. That was your plan an hour ago.
Iteration lap 1 - color: pick a real accent color you love and name the fix: "change the accent color to [your color], everywhere it appears."
Iteration lap 2 - spacing: find the one place that feels cramped or too airy and say exactly where: "more breathing room between the intro and the section links."
Iteration lap 3 - words: rewrite the headline in your own voice and hand it over: "replace the headline with exactly this: ..." Refresh after each lap. Three laps, three visible improvements.
Break it on purpose ★ 5 min · follow along
Open index.html in any text editor and delete one closing tag - a </div> or </section>. Save. Refresh the browser: layout chaos.
Don't tell Codex what you did. Just describe the symptom like a normal person would: "The page suddenly looks broken - everything below the intro is squashed together."
Watch it diagnose: it re-reads the file, finds the unclosed tag, explains what happened, and fixes it. Refresh - healed.
Debrief: you didn't need to know what a closing tag was to get it fixed. Describing SYMPTOMS honestly is a real skill - and it's enough.
This week ◐ 30 min total
- Three more iteration laps on your homepage - one color/typography lap, one spacing lap, one content lap. Name each fix; no re-rolls allowed.
- Read your own index.html top to bottom and ask Codex to explain any line you don't understand ("what does this meta tag do?"). Twenty minutes of this is worth a week of tutorials - it's YOUR code, so the answers stick.
- Optional: install the Codex IDE extension in VS Code and open my-site there - same agent, same AGENTS.md, editor context included. Handy from Session 4 onward.
Three questions before you go 🎯 ◐ 90 seconds
1 · The build loop runs plan → build → run → review. Why does review get its own step?
Codex can check that code runs; it can't check that it matches your taste. Run it yourself, name what's off, feed it back - that's the loop working.
2 · "No frameworks, plain HTML/CSS/JS only" - where should that instruction live?
Standing rules go in AGENTS.md so every future conversation inherits them for free. One-off prompts are for today's task. Apply the twice rule.
3 · The homepage came back almost right but the header is too cramped. Best next prompt?
Name the fix, don't re-roll. A specific correction keeps the 90% that worked; "try again" throws it all away and gambles on a new draw.
Official sources covered
This session teaches the working content of OpenAI's official materials - docs at learn.chatgpt.com and free courses at OpenAI Academy.