Codex AI training that changes what a team merges

Start from the failure

Good Codex AI training opens with a broken run. A useful exercise is a task with a missing repository convention. Let participants inspect the failure, add the relevant context, and run it again.

That order matters. Teams who see the polished demo first assume the tool is magic and get quietly disappointed by Tuesday. Teams who see the failure first learn the actual skill, which is managing what the model knows.

The four things worth a full day

• Repository priming. A committed AGENTS.md naming the build command, the test command, the directories that are generated, and the ones nobody may touch.
• Task shaping. Turning a vague ticket into a brief with a definition of done that the agent can verify itself, usually by running tests.
• Interruption. Knowing within two minutes that a run is going wrong, and killing it rather than watching hopefully.
• Reviewing code you did not type. This is a distinct skill from reviewing a colleague's work, because there is no author to ask.

Everything else, the keyboard shortcuts, the model picker, the settings, can be read in the documentation. Do not spend a trainer's day on it.

Interruption is the underrated one

Most wasted time with agents comes from letting a bad run continue. The engineer has already spent six minutes, feels invested, and keeps nudging. Twenty minutes later they have a branch they do not understand and throw away.

If repeated corrections do not move toward a passing test, pause and inspect the diff. Save a patch or coherent checkpoint before retrying, and preserve unrelated work. Do not use git checkout . as a generic reset: it discards tracked working-tree changes. Decide which edits to keep or revert, then revise the brief around the missing evidence.

Measuring whether the training worked

Vanity measures are easy and useless. Lines of AI-generated code tells you nothing. Number of agent sessions tells you less.

For a trial, choose comparable tasks and record a baseline before training. Track:

• Time from ticket picked up to pull request opened, on a comparable class of ticket.
• Review round trips per pull request. Inspect why another review was needed instead of assuming a particular trend.
• Rollbacks and hotfixes. If this rises, investigate the defects and review process; the count alone does not establish the cause.

Be honest about what training cannot fix. If your test suite takes forty minutes and fails intermittently, agents will not help much, because the verification loop they depend on is broken. That is infrastructure work, and no amount of prompting technique substitutes for it.