What a Codex bootcamp should cover, and what to skip

The failure mode of most training

Engineers sit through a demo on a toy todo app, nod, go back to a codebase with nine years of history and four abandoned patterns, and none of it transfers. The demo repo has no legacy. Their repo is all legacy. A Codex bootcamp that never opens the real codebase is a talk with extra steps.

So the first thing to check when buying training is whether the exercises run against your code. If the answer is a canned sandbox, expect the effect to fade in a fortnight.

What a Codex bootcamp should actually teach

The curriculum that holds up is narrower than most people expect:

• Writing AGENTS.md properly. Not a wishlist. The build command, the test command, the two conventions people actually argue about in review, and the directories to leave alone.
• Task sizing. Which jobs to hand over whole, which to split, and how to recognise the ones to do yourself.
• Reading a plan before code gets written, and correcting it in one sentence.
• Reviewing agent-written diffs. Different from reviewing a colleague, because the confident wrong answer looks identical to the right one.
• Approvals and sandboxing. What the agent may run without asking, and what it must never touch.

That is roughly a day and a half. The remaining half day is best spent on whatever your team keeps getting wrong, which you will only know once you watch them.

Skip these

Prompt engineering as a subject. Model comparison charts. Anything that will be outdated before the next quarter. A long session on configuration files nobody will edit twice. If a bootcamp agenda has forty minutes on "the future of AI in software", that is filler.

Also skip the leaderboard exercise where teams race to build something small. It rewards accepting output without reading it, which is the exact habit you are trying to prevent.

An exercise that works

Give each pair a real open bug from your tracker, ideally one that has been sitting there for months because it is boring. Have them run it end to end: set up a worktree, write the task, read the plan, let it work, review, run the tests, open the PR. Then have a different pair review that PR without knowing an agent wrote it.

The interesting part is the review. Reviewers routinely approve code that does not do what the ticket asked, because it reads well and the tests pass. Watching that happen live, with their own code, changes behaviour in a way no slide does. We have run this with over a hundred teams and it lands every time.

What to do next

Before you book anything, run the exercise above yourself with two engineers and a real ticket. You will learn where your team actually breaks, and you can hold any trainer to fixing that specific thing. Ask any provider two questions: does the training run in our repository, and what does the team do differently on the Monday after. If the answers are vague, keep looking.

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