L5Lesson 1Free

Run the proof loop

Tests, build, route, screenshot, or manual check

After this, you'll be able to choose the right proof loop for a Codex task and read failure output before asking for another edit.

Before you start

Complete Keep network and secrets controlled first.

The idea

A Codex change is not done when the patch exists. It is done when the proof matches the task. The proof loop is the evidence that the change works and did not break the nearby system.

One blank code-change card sits apart from test, build, route, and screenshot proof cards.

LoopMove through Run the proof loop, check proof, then fix only the weak part.

Here is the before and after: before, Codex is guessing from a loose request. After, you can choose the right proof loop for a Codex task and read failure output before asking for another edit.

Now try it use the exercise prompt on one real repo task. Keep the output small enough to check before you accept the change.

You are ready when the Codex action, boundary, and proof all match the task.

Try it (12 min)

Watch out for

Running the build only when a targeted test exists.
Running a targeted test only when the change affects routing or shared types.
Accepting a screenshot without knowing the page state.
Ignoring failed proof because the code looks right.

Paste this into Claude

Build a proof loop for this Codex task:

Task: [describe change]
Files likely touched: [paths]
Risk: [copy, UI, API, data, auth, billing, infra]
Available commands: [test, lint, typecheck, build, route check, unknown]
Manual check available: [page, screenshot, API call, none]

Return the proof loop Codex should run, in order. Include what each step proves and what it does not prove.

What a good response looks like

Run npm test -- profile, npx tsc --noEmit, npm run build, then open /profile and save a changed display name. Tests cover helper behavior. Build covers compile and route generation. Manual check proves the browser flow. Still unverified: production auth provider.

What good looks like

The proof loop matches the task risk
Commands are concrete
Manual checks are named when route or UI behavior matters
The answer names what remains unverified

When this breaks

Breaks when the proof command passes but does not cover the changed behavior.
Breaks when Codex fixes a test by weakening the assertion instead of fixing the bug.

AI can help with this

Use Codex to help you you can choose the right proof loop for a Codex task and read failure output before asking for another edit. Start with the exercise prompt and your real input. Ask for one draft, then check it against this proof: The proof loop matches the task risk. Accept only the version you can verify yourself.

The edit moves through the selected proof command and reaches the golden dot only after passing.

You can now

You can choose proof by task risk

You can name what each command proves
You can require route or screenshot proof for UI work
You can record remaining uncertainty

Key takeaways

Proof is the finish line. Ask Codex for change, proof, and remaining uncertainty before you inspect the diff.

A patch without proof is unfinished.
Proof must match the changed behavior.
Manual checks matter when UI or route behavior changes.
Unverified items should be stated, not hidden.

Go deeper

Was this helpful?

Up nextReview diffs before commit

Build the Checkpoint and Replay Review diffs before commit

← Back to Codex Fundamentals

Build a proof loop for this Codex task: Task: [describe change] Files likely touched: [paths] Risk: [copy, UI, API, data, auth, billing, infra] Available commands: [test, lint, typecheck, build, route check, unknown] Manual check available: [page, screenshot, API call, none] Return the proof loop Codex should run, in order. Include what each step proves and what it does not prove.

Run npm test -- profile, npx tsc --noEmit, npm run build, then open /profile and save a changed display name. Tests cover helper behavior. Build covers compile and route generation. Manual check proves the browser flow. Still unverified: production auth provider.