1
You = Owner
Own the product outcome, priorities, risk tolerance, architecture boundaries, and the final merge decision.
Never outsource judgment.
01 · Mental model
Treat the plan as a hypothesis—not scripture.
ChatGPT may understand the architecture broadly while missing a generated file, hidden dependency, runtime constraint, or stale assumption. Codex sees the repository and execution environment more directly, but it can still optimize toward the wrong objective. The two tools must check each other.
Weak workflow
“Here is a huge prompt. Implement everything. Commit to main.” This maximizes activity and minimizes control.
Strong workflow
“Inspect → verify assumptions → reproduce → propose → implement bounded scope → test → review diff → report evidence.”
02 · The operating loop
Nine gates from idea to merge.
Every gate exists to catch a different class of failure. Skipping gates is acceptable only when the task is genuinely tiny and reversible.
0
Define the outcome
Describe the user-visible behavior or system property that must change. Do not begin with files or implementation.
Output: one-sentence outcome1
Collect evidence
Provide screenshots, errors, reproduction steps, affected routes, logs, examples, and known constraints. Evidence beats interpretation.
Output: reproducible problem statement2
Use ChatGPT to investigate
Ask it to map the flow, separate symptoms from causes, identify uncertainty, and challenge your preferred solution.
Output: diagnosis + confidence + open questions3
Make the architecture decision
Choose the target behavior, constraints, non-goals, compatibility rules, and rollback approach. Record why alternatives were rejected.
Output: short decision record4
Convert it into a task contract
Write requirements and acceptance criteria that are observable. Avoid dictating every line unless the exact implementation is required.
Output: Codex-ready implementation brief5
Make Codex verify before editing
Require it to inspect referenced files, confirm the reproduction, and report material conflicts between the plan and the repository.
Output: verified implementation approach6
Implement one bounded change
Prefer one root cause or one coherent milestone per branch/PR. Large outcomes should become a sequence of independently reviewable changes.
Output: focused diff7
Validate at three levels
Run static checks, targeted tests, and the actual user scenario. For UI, inspect responsive behavior, interaction states, and visual regressions.
Output: commands + results + residual risk8
Review independently, then merge
Use a fresh review pass focused on correctness, regressions, security, performance, and unnecessary complexity. You—not the agent—approve the merge.
Output: requirement-to-evidence matrix03 · Task sizing
Choose the workflow by blast radius.
Do not use the same process for a typo and an authentication refactor. The deciding factor is not how easy the prompt sounds; it is how many behaviors and dependencies can be affected.
| Scope | Examples | Best approach | Required control |
|---|---|---|---|
| Tiny | Copy edit, one test, isolated style fix | Direct Codex task | Diff review + targeted check |
| Focused | One bug, one component, one API behavior | Short ChatGPT diagnosis → Codex implementation | Reproduce first + regression test |
| Cross-cutting | Schema change, shared renderer, auth flow, migration | ChatGPT architecture brief → Codex plan → milestone PRs | Non-goals, compatibility, rollback, integration tests |
| Product-level | New subsystem, major redesign, platform capability | Decision records + multiple agents on independent workstreams | Dependency map, staged rollout, explicit merge sequence |
04 · Reusable prompts
Prompts should function like contracts.
The strongest prompt is not the longest. It is the one that preserves the outcome, constrains the blast radius, and makes completion testable.
A. Ask ChatGPT to analyze the repository
Inspect the repository and help me decide the correct fix before any code is changed. OUTCOME [Describe the user-visible or architectural outcome.] EVIDENCE [Errors, screenshots, reproduction steps, routes, logs, examples.] KNOWN CONSTRAINTS [Compatibility, performance, security, dependencies, release constraints.] YOUR JOB 1. Trace the relevant execution and data flow across files. 2. Separate symptoms from likely root causes. 3. Challenge my assumed solution and compare realistic alternatives. 4. Identify assumptions that are confirmed, uncertain, or false. 5. Recommend the smallest coherent implementation scope. 6. Produce observable acceptance criteria and a validation plan. 7. List material risks, non-goals, and rollback considerations. Do not give me a generic answer. Cite the actual files, functions, schemas, and flows you found.
B. Send the implementation contract to Codex
Implement the following outcome in this repository. IMPORTANT OPERATING RULE Treat this plan as an implementation hypothesis, not ground truth. Inspect the repository first. Verify every referenced file and assumption. If the repository materially conflicts with the plan, explain the conflict and adapt the implementation while preserving the outcome and acceptance criteria. OBJECTIVE [Required behavior or system property.] CURRENT BEHAVIOR AND EVIDENCE [Reproduction steps, screenshots, logs, failing tests, examples.] REQUIRED CHANGES [Behavioral and architectural requirements.] NON-GOALS [What must not be changed or redesigned.] CONSTRAINTS [Public APIs, schemas, dependencies, compatibility, security, performance, style.] ACCEPTANCE CRITERIA [Observable pass/fail conditions.] VALIDATION [Commands, targeted tests, UI scenarios, data cases, responsive states.] EXECUTION 1. Inspect and summarize the relevant implementation before editing. 2. Reproduce the problem when feasible. 3. Keep the diff focused and preserve unrelated behavior. 4. Add or update regression tests where practical. 5. Run the smallest relevant checks, then broader checks if justified. 6. Review the final diff for regressions, dead code, and unnecessary complexity. 7. Report: files changed, decisions made, commands run, results, and remaining risks. Do not commit or merge unless explicitly instructed.
C. Force an evidence-based final review
Review the completed change as if you did not implement it. Focus on: - correctness against every acceptance criterion - regressions and edge cases - API/schema/backward compatibility - security and authorization boundaries - performance and unnecessary work - error handling and observability - maintainability and avoidable complexity - missing or weak tests Return: 1. Findings ordered by severity, with exact file references. 2. A requirement → implementation → verification evidence table. 3. Commands actually run and their results. 4. Anything not verified. 5. A clear recommendation: merge, revise, or block. Do not summarize the diff unless it supports a finding.
05 · High-leverage tricks
Small habits that radically improve results.
Require reproduction before repair.
Without reproduction, the agent can create a plausible patch for the wrong failure.
Ask for assumptions with confidence levels.
“Confirmed / likely / uncertain” exposes where the plan is resting on guesswork.
Use AGENTS.md for durable rules.
Store test commands, package-manager policy, architecture boundaries, and dependency rules once instead of repeating them in every prompt.
Commit or stash before delegation.
A clean baseline makes it obvious what the agent changed and gives you a safe rollback point.
Ask for the smallest relevant test first.
Fast targeted feedback catches the immediate failure; broader suites come after the fix is credible.
For UI, specify invisible behavior.
Screenshots do not show focus, hover, loading, error, empty, keyboard, or mobile states. State them explicitly.
Split by root cause, not by screen.
One shared renderer bug may affect ten charts. Fix the shared cause in one PR instead of patching ten visuals independently.
Use parallel agents only for independent work.
Parallelism is leverage when boundaries are clean; it is conflict multiplication when agents touch the same contracts.
Use a fresh thread for review.
The implementing agent is biased toward defending its own solution. A fresh context catches more.
Demand an evidence matrix.
Every requirement should map to a code change and a verification result. Missing rows expose incomplete work.
06 · Review protocol
“Tests passed” is not enough.
A trustworthy completion report has four independent forms of evidence. Missing one does not automatically invalidate the change, but it must be stated honestly.
Static checks
Automated tests
Real scenario
Diff inspection
| Review question | What good evidence looks like |
|---|---|
| Did it fix the right problem? | The original reproduction now passes, not merely a new synthetic test. |
| What else could it break? | Call sites, shared contracts, schemas, and compatibility paths were inspected. |
| Is the change larger than necessary? | Unrelated formatting, dependencies, refactors, and generated files are absent or justified. |
| Can failure be detected later? | Regression tests, logs, error states, or monitoring cover the important path. |
| Can it be reversed? | The change is isolated, migration strategy is clear, and rollback does not destroy data. |
07 · Failure modes
Where AI-assisted development goes wrong.
Red flags that should stop the merge
- The agent says “fixed” but cannot show the original failure and successful retest.
- A small request produces a massive diff with unrelated cleanup.
- The implementation changes public APIs or schemas without explicitly acknowledging it.
- Tests were skipped because they were “not available,” but the agent did not inspect existing scripts or CI.
- The agent silently changes architecture because it was easier than preserving constraints.
- New dependencies are added when existing utilities already solve the problem.
- Documentation claims behavior that was not actually validated.
- Multiple root causes, features, and refactors are mixed into one unreviewable PR.
08 · Non-negotiables
The rules that protect your leverage.
Never merge from confidence alone.
Language models are optimized to produce coherent answers. Coherence is not proof.
Never let the prompt become the architecture.
The repository, runtime behavior, and product requirements outrank an earlier plan.
Never combine unrelated risk.
Feature work, schema changes, dependency upgrades, and visual redesigns should not share one PR without a compelling reason.
Never reward code volume.
The best implementation is the smallest change that reliably produces the intended outcome and remains understandable.
The optimal division of labor
You choose what matters. ChatGPT turns uncertainty into a decision and a testable contract. Codex verifies the contract in the real codebase, performs the implementation, and returns evidence. Then you judge the evidence and control the merge.
Built from practical engineering discipline and current OpenAI guidance:
Codex best practices,
prompting and workflow examples, and
AGENTS.md project instructions.