How to set up an AI coding workshop for your engineering team

Set up an AI coding workshop in three moves: decide the change you want to see in pull requests, pick a format, then run hands-on labs on your own repos. An AI coding workshop is a hands-on training session, scoped to your real repositories and review habits, that ends with one shared playbook. Plan for a half day to two days of focused time with eight to twenty engineers.

Your team already ships with assistants every day, and the review queue shows it: longer diffs, a handful of private prompt styles, and pull requests nobody fully reads. The workshop exists to fix that, not to tour a feature menu.

Decide the outcome before you book anything

The session you need is not a tool demo, because the tool is rarely your problem. Teams ask for training on an editor when the thing hurting them is unreviewed generated code sitting in the merge queue. A perfect tool tour leaves that code right where it was.

So write down the outcome first. Name one or two changes you want to see in pull requests within a month: shorter diffs, generated code reviewed to the same bar as hand-written code, fewer one-off agent setups. That sentence decides the format, the prep, and what counts as done.

A workshop earns its cost only when it changes what shows up in pull requests within a month. If you cannot point at the change in the merge queue afterward, it was a demo with catering.

Scope the labs to your real repos

A good session trains the workflow, not the menu. The core areas:

• Safer AI coding: prompting, context, and when to trust generated code
• Review habits for generated code, so pull requests stay small and readable
• Shared agent workflows, rules files, and MCP setup the whole team uses
• Practical adoption, so the habits survive after the trainer leaves

The same frame holds whether your engineers run Codex, Claude Code, or Codex. The artifacts differ (.mdc rules for Codex, CLAUDE.md for Claude Code, AGENTS.md for Codex), but the review standard stays one standard.

Have the official references open during prep: the Codex docs, the Claude Code docs, the Codex docs, and the Model Context Protocol spec if connectors are in scope.

The labs run on code the team actually owns, never toy examples. Toy repos produce toy habits. Send your repositories, languages, and current review rules ahead of time so the trainer can build exercises around them.

Write the playbook before everyone leaves

The session ends by writing down the rules, prompts, and review steps the team agreed on. A new hire then reads one document instead of guessing, and reviewers stop relitigating the same arguments every sprint. The playbook is the deliverable. Everything else is rehearsal.

Here is a starting skeleton your team can fill in during the last hour:

# Team AI coding playbook

## When to trust generated code
- Always review generated code at the same bar as hand-written code
- Split large generated diffs into reviewable pull requests

## Prompting and context
- Standard prompt patterns we agreed on
- Which files and docs we feed as context

## Rules files
- Codex: .mdc rules
- Claude Code: CLAUDE.md
- Codex: AGENTS.md

## MCP and connectors
- Approved servers and who owns them

## Review checklist for AI-generated PRs
- [ ] Diff is small enough to read in full
- [ ] Generated logic has tests
- [ ] No copied secrets or stray context

Pick the format that fits your team

Once the outcome and prep are set, format is mostly logistics.

US teams often run virtual cohorts across time zones first, then a single onsite day to lock in the playbook. That keeps travel low and still gives you one room where the rules get finalized.

The structure behind the session follows our methodology, with the Review step carrying the most weight: generated code gets one review standard, not a separate informal path. If governance matters for your org, the broader practice lives on our AI coding governance topic page.

Common questions

• How long does a Codex workshop take?

  Most sessions run from a half day to two days, depending on team size and depth. The sizing rule is simple: name the one or two pull-request changes you want within a month, then book only the time needed to train and lock in those changes. Depth, not hours, decides the length.

• What does a Codex workshop cover?

  It covers safer AI coding, review habits for generated code, and the shared agent workflows, rules files, and MCP setup the whole team uses. The session is scoped to your repositories, and engineers work in their own repos during labs rather than toy examples. The output is one playbook the team keeps.

• How many engineers should attend?

  Eight to twenty works well for hands-on labs, and larger groups split into cohorts. Onsite sessions fit 8 to 20 people, virtual cohorts stretch to 30, and offsites work best at 10 to 25. Pick the format that matches the group you actually have, then size the cohorts from there.

• Do you run sessions across US time zones?

  Yes. Virtual cohorts are scheduled around your team's hours, and onsite dates are booked to your calendar. US teams often run virtual cohorts across time zones first, then one onsite day to lock in the playbook. That order keeps travel low while still landing one shared standard.

• What changes after the workshop?

  Teams report shorter pull requests, more consistent review of generated code, and fewer one-off agent setups. The lasting artifact is a shared playbook with the rules, prompts, and review steps the team agreed on, so a new hire reads one document instead of guessing. Check it against your merge queue a month later.

Start with one outcome note

Write a one-page note naming the one or two pull-request changes you want within a month, then bring your stack and time zone to a short call and we will scope a workshop that fits. Book a 15-minute sync.