Four Codex workflows that hold up under load

Reproduce, then fix

The strongest pattern we teach. Before asking for a fix, ask for a failing test that demonstrates the bug. The agent writes the test, you run it, and you watch it fail for the right reason. Only then do you ask for the change.

This costs one extra round trip and removes the most common bad outcome, which is a confident patch to code that was never the problem. If the agent cannot produce a failing test, that is information. Usually it means your description of the bug was too vague to act on.

Narrow the blast radius before you start

Sessions go wrong when the agent has the whole repo and a broad instruction. Point it at the files that matter and say what is off limits. A session that starts with "the bug is somewhere in the payment flow, only touch src/billing, do not change any migration" produces a diff a human can review.

Some workflows worth having as muscle memory:

• Ask for a plan first on anything touching more than three files, and read the plan before approving work
• Run the test suite yourself between agent turns rather than trusting a summary
• Keep one session to one task, and start fresh when the task changes
• Commit at every point the tree is green, so rolling back is one command instead of an argument

Codex workflows for the boring, high-volume work

The best return is not on novel features. It is on mechanical change at volume. A dependency bump across forty call sites. A logging convention applied consistently. A test suite migrated from one assertion style to another.

These jobs are tedious, verifiable, and low judgement. Run them in a dedicated branch, review the diff by pattern rather than line by line, and spot-check the places where the pattern had to bend. The failure mode here is the agent quietly skipping the three awkward cases and reporting success on the other thirty-seven. Grep for the old pattern afterwards. Every time.

Review before human review

Have Codex read the diff before you request review from a colleague. Not as a gate, as a cleanup pass. It reliably catches the debug statement you left in, the error path with no test, the function whose name no longer matches its behaviour.

It does not catch whether the change was worth making. That stays with you.

Ask for it adversarially. "Is this correct?" gets you agreement. "Find the three most likely ways this breaks in production" gets you a list you can act on. The wording of the request changes the output more than any setting in the tool.

What to try this week

Take the next bug in your queue and run the reproduce-then-fix loop end to end. Write down where the agent went wrong and what you had to tell it. That note, added to your repo instruction file, is worth more than any workflow diagram somebody else drew.

If you want help putting this into practice, talk to us.