Using Codex and AI Coding Agents Without Losing Control

OpenAI's Codex is a coding agent you run in your terminal; there are equivalents from several vendors. The defining difference is not the model — it is the loop. The agent can read files, write files, run shell commands, observe the results, and try again. It is given a goal and it works until it either succeeds or gets stuck.

• It reads your actual repository rather than a snippet you pasted.
• It runs your tests, sees them fail, and fixes the failure itself.
• It executes commands — which is exactly why sandboxing matters.
• It works in a diff you can read before it goes anywhere near your main branch.

• Always work on a branch. The agent should never be pointed at main.
• Keep sandboxing on. These tools run shell commands; network and filesystem restrictions are a real safety net, not ceremony.
• Start with a scoped task — one function, one file, one bug — not 'refactor the project'.
• Review the diff line by line before merging. The agent will be confident and occasionally wrong.
• Keep your own tests. The agent that can see assertions writes dramatically better code, and it catches itself when they fail.

An agent has your repository but not your intent. The brief carries the intent, so vagueness costs iterations.

• State the goal and the acceptance criteria. 'Tests pass and the function returns sorted results' beats 'fix the sorting'.
• Point it at the types and interfaces, not just the function. Types are the contract.
• Name the constraints: framework version, the libraries you are allowed to use, the style already in the file.
• Ask for a plan first on anything non-trivial, then approve before it writes code.
• Tell it not to touch unrelated files. Scope drift is the most common failure mode.

Goal: the parseDate function in src/lib/dates.ts fails on "2026-13-01".
Accept: it returns null instead of NaN, and there's a test for it.
Constraints: TypeScript, no new dependencies, match the file's existing style.
Do not modify any file other than src/lib/dates.ts and its test.

• Boilerplate, tests, type definitions, and migrations — it is excellent at work that is tedious but well-specified.
• Bugs with a clear reproduction and an obvious failing case.
• Getting oriented in an unfamiliar codebase: 'explain what this module does and where the entry point is'.
• Mechanical refactors across many files with a consistent pattern.
• Architecture, security review, and anything where the right answer is a judgement about your specific constraints. It will produce a confident guess.