Codex debugging and quality guide for beginners

When something breaks after a Codex change, do not describe the problem in your own words. Copy the full error output, including stack traces and error codes, and paste it directly into your debugging prompt. Codex diagnoses better when it sees the actual evidence.

Last sprint I asked Codex to fix a type error. I wrote: 'I am getting a TypeScript error about incompatible types on line 47.' Codex guessed wrong three times. On the fourth attempt I pasted the full compiler output: 'Type 'string | undefined' is not assignable to type 'string'. Type 'undefined' is not assignable to type 'string'. Codex fixed it in one go.

Also document what you did that triggered the failure. Which file changed? What input did you provide? What did you expect versus what actually happened? This context saves rounds of clarification that waste everyone's time.

When I make multiple Codex changes before noticing a problem, I use git diff to see everything that was modified. Then I revert changes one at a time, testing after each revert, until the failure disappears. This is git bisect by hand and it finds the exact commit that introduced the bug.

Reading a diff line by line with the error message open side by side works surprisingly well. Look for: logic errors, off-by-one mistakes, missing null checks, incorrect type assertions, or functions that were called with wrong arguments. These five categories account for most post-Codex bugs in my experience.

The worst debugging sessions happen when I skip this step and just start guessing. Twenty minutes of systematic binary search beats two hours of random experimentation. Discipline matters more than cleverness here.

Under deadline pressure, the temptation to skip reviews and tests is strong. I learned the hard way that the time saved skipping checks costs triple in debugging later. My minimum standard, even when rushing: one human reads every change, and all tests pass. No exceptions.

I keep a pre-commit checklist that takes under five minutes: change matches ticket requirements, no unrelated files were modified, linter passes, relevant tests pass. This lightweight process catches the majority of issues without adding meaningful overhead to delivery time.

Track your post-merge fix rate. If more than twenty percent of Codex-generated changes need follow-up patches within a week, something is wrong with either the prompt quality or the review process. I check this monthly and adjust when the trend moves in the wrong direction.