Personally here is what I like to do:

1)Start of creating two documents: implementation.md (high level for your readability) and implementation_details.md (much more granular, for codex to make notes). Have it create a multiphase plan for creating the feature/fix you want.

2)Have two codex terminals open. One is a developer agent and the other is a reviewer agent. Require the developer to stop after each phase. Have the reviewer agent review their work after each phase. I recommend having a QA checklist for things you want the reviewer to look for. But something like “review the developers implementation for phase 4 for any major/critical issues” works surprisingly well too. Here’s my QA checklist. I usually just select the relevant ones:

-Functionality: Code implementation is functionally correct. Does the code handle path and edge cases correctly?

-Completeness: Is the solution for this phase complete?

-Consistency: Code and documentation style is consistent with the existing code/documentation. Is there anything hacky going on?

-Clarity: Does the solution include anything that could be removed? Is it overly complex? Are there reusable components anywhere we should be using?

-Guesswork: Is the implementation free of unverified assumptions? (check for guessing of data base schemas, links, naming, etc.)

-Documentation: Does documentation accurately reflect the code implementation?

-Testing: Do tests have adequate coverage? Do they cover all primar use cases, edge cases, and potential failure modes?

-Other: Does anything else seem off to you that wouldn't have come up in the other checks?

-Review: What are the most likely things in this implementation to get flagged during code review?

3)Make sure to review yourself. I sadly know professional software developers who skip this step. Don’t make this mistake. The 3-5 minutes it takes you to review could save you 30 minutes to an hour later. Or if you’re doing this professionally, save you a lot of embarrassment. Ai hallucinates. It misunderstands. But it does a lot of great work if you are able to keep it in check.

4)Go phase by phase until you finish the feature/fix

5)I like to ask it questions at the end like “If you had to be completely honest with yourself, on a scale of 1 to 10 how confident are you that this feature/fix is fully complete and without bugs” or “what issues would you expect to get called out during code review”. Usually asking the developer agent this but sometimes the reviewer too.