Onsite or Virtual AI Coding Training

Pick the format by what your team needs to agree on, not by which one looks more serious. Go onsite when the team has to align on review rules, repo conventions, and tool boundaries faster than it can write them down. Go virtual when those habits already exist and you just need reps. Agentic coding training is the work of turning a coding agent like Cursor (Anysphere's AI code editor), Claude Code (Anthropic's coding agent), or Codex (OpenAI's coding agent) into shared team policy instead of a personal trick.

The format is the cheap part. The expensive part is what people carry back to the repo: a rule file, a review checklist, and a clear connector boundary. If a workshop produces those, it worked. If it produced a great demo and nothing committable, it did not.

Start with policy, not prompts

Most teams leave AI training remembering the clever prompt and forgetting the guardrail that made the output safe. That is the trap. The prompt is portable trivia. The guardrail is the thing that keeps a Friday merge from becoming a Monday incident.

So open the session with the rules, before any live coding. Pull up the repo conventions, the review standard, and the connector limits, and make the room read them out loud. Each tool has a home for this.

• Cursor: scoped .cursor/rules/*.mdc files plus a small AGENTS.md convention.
• Claude Code: a CLAUDE.md, hooks, and a review checklist.
• Codex: an AGENTS.md, a verification loop, and explicit sandbox or approval settings.

When teams start here, the first week gets quieter. Fewer "can I use this here?" questions, fewer surprise diffs, fewer arguments in review. A simple test: if the room cannot name the rule file by lunch, the session was too abstract and you should pull it back to the repo.

Practice on a real branch

A workshop that never touches a real branch leaves people with confidence and no muscle memory. Confidence fades by Wednesday. Muscle memory does not.

Give the team one real task against one real rule file with one real connector boundary, and make them ship it. For Cursor, split one bloated rule into a scoped .mdc tree. For Claude Code, add a compact CLAUDE.md fragment plus a hook that blocks unsafe paths. For Codex, run codex exec against a small change and require a verification loop before merge.

The payoff is boring in the best way: fewer handoffs, fewer "I thought the agent would know" moments, and faster review because the diff already fits the repo's shape. If nobody edits a real branch during training, the team practiced theater.

Treat MCP as a boundary, not a feature

The Model Context Protocol is the layer that lets an agent reach your tools and data. Teams tend to connect everything, then realize they have no idea what action path or data path they just opened. That is the moment to slow down.

Run a connector review before anything touches production work. Look at the server, the scopes, the consent path, and the tool descriptions. The MCP specification is explicit that tools can expose arbitrary code execution and that user consent and control matter, so read it with that in mind: Model Context Protocol specification.

This is one place where being in the same room pays off, because a boundary is easier to set when the security or platform owner is right there. Virtual works fine too, as long as that owner can join the call live. A rule of thumb: if a connector cannot be explained in one minute, it is not ready for broad use.

Make review the same across tools

Review quality goes tribal fast. One reviewer trusts the agent, another rejects everything on sight, a third only checks formatting. The fix is a shared review receipt that travels with every agent change, whatever tool produced it.

Keep it short. It should say what the agent changed, which rule or skill governed the change, what verification ran, and which connector was touched. Here is one your team can paste into a PR template:

## Agent review receipt
- [ ] What changed: <one line>
- [ ] Rule / skill that governed it: <file or name>
- [ ] Verification that ran: <tests, build, lint>
- [ ] Connector touched: <server + scope, or "none">
- [ ] Reviewer signed off: <name>

The artifact names differ by tool, but the receipt is the same. Cursor leans on .cursor/rules/*.mdc, AGENTS.md, background agents, and browser control. Claude Code leans on CLAUDE.md, skills, hooks, and MCP. Codex leans on AGENTS.md, codex exec, MCP, skills, and a verification loop. Make the work reviewable before you make it fast, and the receipt keeps paying rent.

Use the matrix to decide

Drop this into the kickoff doc or the workshop invite and fill it in with one repo owner, one reviewer, and one platform lead. It turns "onsite or virtual" from a vibe into a decision.

Onsite earns its travel cost when the team needs fast alignment, has mixed seniority, or carries a messy rule set that benefits from live cleanup. Virtual wins when the team is already distributed, the repo rules are stable, and the goal is repetition rather than discovery.

Common questions

Is onsite training always better than virtual? No. Onsite only wins when the team needs to align on rules, review, and tool boundaries faster than it can write them down. Once those habits are stable and the goal is repetition, virtual delivery gives you the same outcome without the travel cost, and it scales better across a distributed team.

What should every workshop produce? Four committable things: one scoped rule or memory file per tool, one review checklist, one connector boundary note, and one verification loop. If the session ends with a great demo but nothing you can commit to the repo, it did not change how the team works. The artifacts are the proof.

How do we govern MCP connectors safely? Review each connector before production use: the server, the scopes, the consent path, and the tool descriptions. The MCP spec warns that tools can run arbitrary code, so treat any new server like a new dependency. If you cannot explain what a connector does in one minute, it is not ready for the whole team.

Can one review process cover Cursor, Claude Code, and Codex? Yes. The artifact names differ, but a shared review receipt works across all three. It records what changed, which rule governed it, what verification ran, and which connector was touched. That keeps review consistent even when one engineer uses Cursor, another uses Claude Code, and a third uses Codex on the same codebase.

Who should be in the room for the kickoff? At minimum one repo owner, one reviewer, and one platform or security lead. The repo owner names the rules, the reviewer sets the bar, and the platform lead vets the connectors. With those three present, the matrix fills itself in and the team leaves with real boundaries instead of opinions.

Where to start

Fill in the decision matrix with your repo owner, reviewer, and platform lead this week, then plan the workshop around the result rather than the other way around. For the wider operating model, see our AI coding governance topic and how we run sessions in our methodology.