How to pick between Codex courses for a working team

Two kinds of Codex courses

The first kind teaches the surface. Install, sign in, here is the chat pane, here is how to approve a command, here are twelve prompt templates. It takes ninety minutes and your team could have got there from the docs. There is nothing wrong with it, but do not pay consulting rates for it.

The second kind starts from a repository and a backlog. It spends most of its time on the parts nobody writes docs about: how much of your codebase to put in front of the model, when to stop a run that has gone sideways, how to review a diff you did not type. That kind is harder to sell because the outline looks thinner. It is the one that changes behaviour.

Questions that separate them

• Do we work in our own repository, or a prepared demo project?
• What is committed at the end? A configuration file, merged pull requests, a written team convention.
• How much of the time is the trainer talking versus the room typing? Anything over half is a talk, not a course.
• Who teaches it, and when did they last ship production code with these tools?
• What does the course say the tool is bad at? A course with no limits section has not been run on a real codebase.

That last one is the sharpest filter. Anyone who has spent a month with an agent in a large repository has a list of grievances: context that silently truncates, confident refactors that break a test three packages away, review output that buries the one real bug under nine style notes. A course that omits all of that is a product demo.

Sequencing for a team of ten

Do not put ten engineers through the same day. Split by what they will actually do. A backend group working in a legacy service needs long-context handling and test-first workflows. A frontend group needs component-level iteration and visual verification. A staff engineer needs neither and instead needs the governance question: what merges, what gets flagged, how the team measures whether any of this helped.

We run the shared morning on repository setup, because that part is common. A checked-in AGENTS.md with build commands, test commands, and off-limits directories pays back within a week regardless of who is using it. Afternoons split by track.

Cost of the wrong choice

A bad course is not expensive because of the invoice. It is expensive because the team concludes the tools do not work for their kind of code, and that belief lasts a year. We have picked up teams whose previous training ran entirely in a greenfield Next.js sample, and whose engineers then decided agents were useless for a twelve-year-old Java monolith. They were not useless. The demo was just irrelevant to them.

What to do next

Before you compare providers, write one page: your stack, your repository size, your test situation, and the three workflows you want to be different in a month. Send that page with the enquiry. Any provider who responds with the same generic outline they send everyone has answered your question for you.

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