Train Safer AI Coding Habits

By Rogier Muller07.01.26

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 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.

Don't treat 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 AI coding governance: 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.

Don't accept 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.

Watch for 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.

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.