Codex practical workflow: review, edit, verify

Before I ask Codex to touch anything, I read the file it will modify. Not skimming — actually reading. What patterns does it use? How are errors handled? What naming conventions are in play? Five minutes of reading prevents the kind of subtle inconsistencies that make codebases rot over time.

I also check the linting and formatting config. Our project uses Prettier with single quotes and no semicolons. If Codex outputs double quotes with semicolons, my CI pipeline rejects it immediately. I include the formatting rules in my prompt so the output passes checks on the first run.

Look at the related test files. Understanding what is already tested tells you what Codex should preserve and what new cases might need coverage. This context prevents the model from breaking functionality that currently works — a regression that automated tests might not catch if they exist only for the old implementation.

I never ask Codex to make five changes in one request. Instead: one function, verify it works, commit, move to the next. If something breaks at change three, I know exactly which commit introduced the problem. I can revert that one commit instead of losing everything.

A forty-line change across two files is reviewable. A four-hundred-line change across fifteen files is not. I keep each request small enough to review in under ten minutes. If the task requires more than that, I break it into multiple requests.

Every commit gets a clear message: 'Add null check to handleProfileUpdate before accessing user.id' — not 'fixed bug'. Granular commit messages are free documentation. When you need to git blame three months from now, you will thank yourself.

Layer one: linter and type checker. Run them immediately after applying Codex output. They catch syntax errors, type mismatches, and style violations that you will miss during manual review. Make this a non-negotiable step, like fastening your seatbelt.

Layer two: automated tests. Run the tests for the specific module you changed plus any integration tests that depend on it. If you added a new feature, write tests that cover the main use case and at least one edge case before considering the change complete.

Layer three: manual smoke test. Open the application, navigate to the affected area, and try the normal user flow. Automated checks catch technical problems. Manual testing catches UX issues and runtime problems that only appear in the actual browser or environment. Both layers are necessary.