Codex beginner guide: first changes without chaos

My first Codex task was updating a utility function that formats currency values. Single file, no external dependencies, clear output I could verify by looking at it. That was intentional. I wanted to understand how Codex thinks before trusting it with anything critical.

Good first tasks: writing or updating unit tests, refactoring a standalone utility, updating documentation strings, adding input validation to an existing function. Bad first tasks: modifying authentication logic, touching database schemas, anything that sits in the hot path of your application.

Work on a feature branch in a development environment. If something goes wrong, you delete the branch and nobody notices. Starting on main with a critical file is how you end up explaining a production bug in standup tomorrow.

I asked Codex to add error handling to one of our API routes. I wrote: 'This file handles user profile updates. Add try-catch blocks to the three route handlers. Follow the existing error pattern in utils/errorResponse.ts. Do not change the business logic, only add error handling.'

Notice what I included: file purpose, specific scope, existing pattern to follow, and what to leave alone. That is the level of detail a new developer would need on their first day. Codex benefits from the same briefing.

Without that context, Codex makes reasonable-seeming choices that conflict with your codebase. It imports a library you do not use. It writes error messages in a different format. It handles nulls differently. None of these are bugs — they are just conventions that do not match yours.

I have a rule: never approve Codex output without reading every line, even for simple changes. Last month Codex updated a date formatting function and silently added a dependency on moment.js — a 70KB library we deliberately avoid. The diff looked fine at a glance.

What I check specifically: imports (did it add anything?), type annotations (did it use 'any' where it should not?), error handling paths (does it catch what needs catching?), and edge cases (what happens with null, undefined, or empty string inputs?).

After reviewing, run your test suite. If the changed code has no tests, write at least one before merging. This is not about distrust. It is about catching the integration issues that visual code review misses. Five minutes of testing saves an hour of debugging.