Codex training that survives contact with your repo

Why most Codex training does not stick

A typical session teaches the surface: how to start a session, how to approve a command, where the settings live. Engineers can read that themselves in an afternoon. Two weeks later the tool usage has dropped back to autocomplete, because nobody changed how the team works.

The habits that stick are the awkward ones. Writing a task description precise enough that an agent cannot misread it. Rejecting a diff that works. Keeping a change small enough to review. None of that is about Codex, which is exactly why a product walkthrough does not produce it.

What good Codex training covers

If you are evaluating a provider, or building it internally, these are the parts that change behaviour:

• Writing and maintaining AGENTS.md for a real repository, done live, on the team's own code.
• Reading a transcript rather than only the diff, so people learn to spot where the agent went wrong.
• Scoping: turning a vague ticket into a task an agent can complete without inventing requirements.
• Verification discipline. What command proves the change works, and making the agent run it.
• The refusal cases. Which tasks the team agrees will not be delegated at all.

Notice that only one of those mentions a product feature. That ratio is roughly right.

The exercise that teaches the most

Take a bug that was fixed in your repo three months ago. Revert the fix on a branch. Hand the failing state to an agent and have two engineers watch the run without touching anything.

Most of the time it fixes it. Sometimes it fixes it by weakening the test, and that is the moment worth the whole day. The room sees a green suite next to a broken product. After that, nobody on the team accepts a passing test as proof again. You cannot teach that with slides.

Run it with a second variation: give the same failing state to another agent with a one-paragraph AGENTS.md that names the test command and forbids editing tests. Watching the same task go from wrong to right on the strength of six lines of config is the argument for repo instructions, made better than any explanation.

Doing it without hiring anyone

You can run most of this yourself. Block one afternoon. Pick three real tickets, not toy problems. Have each engineer run one with an agent, then swap and review each other's transcripts. Collect the failure modes on a shared page and turn the top five into rules in AGENTS.md. Repeat in two weeks.

The reason teams bring us in is usually not knowledge. It is that the afternoon never gets booked, and that an outside voice can say "this pull request is too large to review" without it becoming a personnel issue. We are two trainers, Rogier in Amsterdam and Vasilis in Athens, both still writing production code, and we have run this with over a hundred teams. That is the honest pitch. If your team will actually book the afternoon, book the afternoon instead.

What to do next

Pick the reverted-bug exercise and schedule it for this week with three people. Whatever you learn in that hour should be the first thing any training you buy is asked to address.

If you want help putting this into practice, talk to us.