Train Safer AI Coding Habits

Train your team by making agent work observable, permissioned, and reviewable before you make it fast. Use short hands-on ai coding workshops where every developer practices the same workflow: plan, bound tools, run the agent, inspect evidence, and review the diff.

Agentic coding governance is the set of team rules that decides what coding agents may do, what they must record, and when humans must stop them. For Claude Code, Anthropic's coding agent, that means pairing normal repo habits with clear tool boundaries, small tasks, and boring review evidence.

Start with supervised autonomy, not tool sprawl

Give agents a narrow job before you connect every system they might need. A good first lane is something like updating tests for a known module, refactoring a single package, or adding one API validation path.

Agentic Orchestrator, DoorDash's open source terminal UI for long-running coding agents, is a useful signal here. Teams want a cockpit for work that runs longer than a chat turn: multiple agents, visible status, resumable sessions, and less tab-hopping.

The governance lesson is simple. A control surface helps you watch agent work, but it does not decide what the agent is allowed to touch.

The trap is treating orchestration as permission. A TUI can show five coding agents working at once; it cannot tell you whether all five should have write access to GitHub issues, production-like data, or migration scripts.

Run the training as a workflow, not a lecture

AI coding training for teams works best when the team practices the same muscle memory on the same repo. Keep the first session small enough that a skeptical reviewer can follow every decision.

Prerequisites:

• One non-critical repository with good tests.
• One task type the team already understands.
• Claude Code installed for participants who will run the exercise.
• A named reviewer for each agent-produced diff.
• Read-only MCP access unless a write path is explicitly part of the drill.

Step 1: choose one repo and one task class. Pick a task like adding missing validation tests to a TypeScript service. Do not start with architectural rewrites, dependency upgrades, or cross-service migrations.

Step 2: write the team contract. Put durable repo rules in the right project memory, such as concise Claude Code context for test commands, architecture boundaries, and files the agent should not edit. Keep task-specific instructions in the prompt, not in permanent memory.

Step 3: practice the slash-command workflow. If your team uses custom slash commands, make the path explicit: plan the change, run the bounded task, generate a review receipt, then open the PR. A command such as /review-agent-output can be as simple as asking for changed files, commands run, risks, and rollback notes.

Step 4: pair on a failure. Have one developer intentionally give the agent an overbroad task, such as improve auth errors across the app. The pair's job is to stop, narrow the scope, and rewrite the task into a reviewable slice.

Step 5: verify with a blocked action. Prove the setup works by asking the agent to do something outside the boundary, like editing a deployment file during a test-only exercise. The expected result is a stop, a note, and a human decision before any change continues.

This is the practical path to the related training topic: teach the repeatable operating model first, then add more tools. For a deeper companion workflow, see Train Teams on Coding Agents Safely.

Make long-running agents leave receipts

Long-running agent work needs a handoff, not a memory test. Require a short receipt before review so the human does not have to replay the entire chat to understand the diff.

For example, a GitHub PR from an agent should say which files changed, which tests ran, which assumptions were made, and which risky paths were not touched. In a payments service, that might include changed retry tests, the command used to run the billing package test suite, and a note that migration files were left alone.

The trap is accepting a polished summary without evidence. A receipt is useful only when it names commands, files, and unresolved risks.

Keep tool boundaries boring

Start every external integration as read-only unless the exercise requires writes. MCP is the common integration layer for connecting agents to systems like GitHub, Slack, Jira, internal docs, databases, and design files.

A simple permission note is enough for week one: GitHub read is allowed, issue writes are blocked, database access is read-only to sanitized development data, and deployment tooling is unavailable. If you use hooks, add one boundary that blocks destructive shell commands outside the repo or asks for approval before touching protected paths.

The trap is building a beautiful policy that nobody can remember. Prefer three rules developers can say out loud: no secret access, no production writes, and no unreviewed changes to release paths.

Copy the team rollout plan

Paste this into docs/ai-coding-rollout.md and adjust it for one repo. Keep it boring. Boring is how teams adopt safer ai coding practices without turning every PR into a committee meeting.

# Team AI Coding Rollout Plan

Goal: adopt safer ai coding practices for one repo before expanding to more teams.

Repo:
Task class:
Training dates:
Owner:
Reviewers:

## Week 0: setup

- Pick one low-risk task class.
- Confirm test command and local setup.
- Add concise repo rules to project memory.
- Confirm no secrets are available to the agent.
- Configure read-only MCP access first.
- Name protected paths the agent must not edit.

## Permission table

| Surface | Week 1 default | Who can approve more access | Notes |
| --- | --- | --- | --- |
| GitHub repo | Read and branch write | Tech lead | PR still needs human review |
| GitHub issues | Read only | Engineering manager | No auto-closing issues |
| Database | No production access | Staff engineer | Dev or sanitized data only |
| Deployment files | Blocked | Release owner | Agent may suggest changes only |
| Secrets and tokens | Blocked | Security owner | Never paste secrets into chat |
| External docs | Read only | Tech lead | Prefer source links in receipt |

## Training exercise

1. Developer writes a short plan for the task.
2. Agent proposes files to inspect before editing.
3. Developer approves only the bounded task.
4. Agent makes the change on a branch.
5. Agent produces a handoff receipt.
6. Human reviewer checks the diff and evidence.

## Required handoff receipt

- Task requested:
- Files changed:
- Commands run:
- Tests passed or failed:
- External tools used:
- Assumptions made:
- Risks or TODOs:
- Paths intentionally not touched:
- Rollback note:

## Review checklist

- The diff matches the approved task.
- The agent did not edit protected paths.
- Tests or manual checks are named.
- Risky assumptions are visible.
- Generated code follows repo conventions.
- A human can explain the change without reading the full chat.

## Graduation rule

The team may expand to a second task class after five clean PRs with complete receipts and no boundary violations.

Common questions

• How can I train my development team to adopt safer AI coding practices?

  Train them with one shared workflow, not a list of warnings. Start with a two-week rollout: one repo, one task class, read-only integrations, paired reviews, and a required handoff receipt on every agent-generated PR. The copyable rollout plan above gives the team a repeatable exercise instead of a one-off demo.

• Is a terminal orchestrator enough governance for coding agents?

  No, an orchestrator is visibility, not policy. It can help teams supervise long-running agents and parallel work, but permissions, review rules, and stop conditions still need to live in the team's workflow. Treat the TUI as a dashboard over the operating model, not as the operating model itself.

• What should reviewers check when an agent writes the diff?

  Reviewers should check scope, evidence, and boundary behavior first. The minimum artifact is a handoff receipt that names changed files, commands run, external tools used, assumptions, and risks. After that, review the code like any other PR: correctness, maintainability, tests, and fit with repo conventions.

• How much autonomy should Claude Code get at first?

  Start with bounded autonomy inside one repo and one task class. Let the agent read broadly, edit narrowly, and ask before touching protected paths or external systems. A good early rule is five clean agent-assisted PRs with complete receipts before expanding permissions or adding more coding agents.

• Do hands-on ai coding workshops need to be product-specific?

  They should be workflow-specific, then product-aware. Teach the shared loop first: plan, bound tools, run, receipt, review. Then show how Claude Code commands, MCP connections, hooks, and skills map to that loop. This keeps the training useful even when a team also uses Claude or Codex.

Further reading

• Claude Code — getting started
• Claude — Agent
• OpenAI Developers — Codex quickstart
• Model Context Protocol — specification
• OWASP — Top 10 for Large Language Model Applications
• NIST — AI Risk Management Framework
• GitHub — openai/codex
• GitHub — anthropics/skills
• Google Search Central — helpful, people-first content
• Google Search Central — generative AI content guidance
• GitHub — DoorDash Agentic Orchestrator

Start with one bounded repo

Pick one repo, one task class, and one receipt format this week. Run the exercise twice before adding more agents, more tools, or more autonomy.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.