What a Codex course should teach your engineers
How to judge a Codex course before you buy one, what a good syllabus contains, and when a team is better off skipping training entirely.

The test for any Codex course
Ask one question before you book: does the session run in our repository? If the answer is a demo project, you are buying a product walkthrough. Your engineers can get that from the documentation in an afternoon, and they will forget it within a week because nothing in their daily work changed.
The friction that stops teams is never "which button starts the agent". It is a seven year old build script, an untested module everyone is scared of, and a review culture that was designed around humans writing two hundred lines a day.
What belongs in the syllabus
- The loop. What the agent can see, when it decides, why it gets stuck. Without this mental model people either over-trust or refuse to use the tool.
- Repository preparation. Instruction files, exact test commands, exclusions, and the CI checks that make agent output verifiable.
- Task shaping. Turning a ticket into a prompt with a finish line. This is where the largest quality difference sits, and it is teachable in an hour.
- Reviewing agent diffs. Different failure modes than human code: plausible but unnecessary changes, silent scope creep, tests written to pass rather than to catch.
- Team rules. Approval modes, which repositories are in scope, what never goes near an agent.
A concrete exercise we use: take a real bug from the team's tracker, have everyone write a prompt for it independently, run all of them, and read the diffs side by side. People argue. That argument is the training.
How long it should take
One day gets a team to competent and consistent. Anything sold as a multi-week course on a single tool is padding, because the tool changes underneath the material faster than the material can be delivered. The durable content is about verification and review, and that is maybe three hours of it.
Recorded video courses have a specific weakness here. They cannot show you what happens when the agent hits your build. That moment is where people learn.
When to skip the course
If your test suite does not run reliably on a developer machine, fix that first. Agents work by iterating against a check, so a team with no working check gets fast generation of code nobody can validate. We have turned down engagements for exactly this reason. Training would have looked good in the room and changed nothing after.
Next step
Before you buy anything, run an internal dry run. Pick three engineers, give them a week with Codex on real tickets, and ask them to write down every point where they got confused or gave up. That list is your syllabus. Bring it to whoever you hire, including us, and refuse to be taught anything that is not on it.
If you want help putting this into practice, talk to us.
Related training topics
Related research

Codex vs Claude Code, from teams running both
Codex vs Claude Code without the benchmark theatre. Where each one wins in day-to-day work, and why most teams end up keeping both installed.

How to set up an AI coding workshop for your engineering team
How to set up an AI coding workshop: pick a format, scope it to your real repos and review habits, run hands-on labs, and leave with a shared playbook.

Sloppie Is a Linux Agentic Coding Environment
Sloppie is a Linux development environment that turns coding-agent work into review comments, diffs, and terminals.