Team Workflows and Guardrails

One engineer using an AI coding tool is a personal productivity story. A team using them is an engineering-process problem. The moment three people point agents at the same repo, the questions change: whose conventions win, does AI code skip review, and what is the tool allowed to touch?

This is the last article in the topic, and it is about the boring part that makes the fun part safe: turning a solo habit into a team practice without lowering the bar on what ships.

From one engineer to a team

When you adopt a coding tool alone, the guardrails live in your head. You know which files matter, you read every diff, you would never let it run a migration unprompted. None of that transfers when a teammate opens the same repo.

So team adoption means moving the guardrails out of your head and into the repo, where every agent and person sees the same thing. Three surfaces do most of the work.

A shared rules file, so every agent starts from the same conventions.
The existing review and CI gates, applied to AI code with no exceptions.
Explicit tool and data permissions, so nobody has to remember what is safe.

Get those three right and the tool scales from one desk to the whole team without becoming a liability.

flowchart LR
    DEV[Engineer<br/>+ agent] --> RULES[Shared rules<br/>file in repo]
    RULES --> PR[Pull request]
    PR --> REVIEW[Human review]
    PR --> CI[CI: tests,<br/>lint, security]
    REVIEW --> MERGE{Merge?}
    CI --> MERGE
    MERGE -->|pass| MAIN([main])

Shared rules files, checked into the repo

Every good coding tool reads a project rules file: AGENTS.md, CLAUDE.md, a .cursor/rules directory, whatever your tool calls it. On a team, this file stops being a personal note and becomes shared infrastructure. Check it into the repo and review changes to it in pull requests, exactly like code.

The setup article covered what goes in a rules file for you. The team version is the same content with one shift: you are writing conventions the whole team agreed on, not your personal preferences. If a rule is contested, resolve it as a team first. The file records decisions; it is not where you litigate tabs versus spaces.

Keep it concrete and testable. Vague rules get ignored by models the same way they get ignored by juniors.

# Project conventions

- Language: Python 3.12, type hints on all public functions.
- Web: FastAPI. Never add Flask.
- DB access goes through `app/db/repository.py`. No raw SQL in route handlers.
- Tests: pytest, in `tests/`, mirror the source path. No test, no merge.
- Never edit files in `generated/` by hand; they come from `make codegen`.
- Secrets come from env vars via `app/config.py`. Never hardcode a key.

One repo-level file is the baseline. Most tools also support nested rules files in subdirectories, which is how a monorepo gives its frontend and backend different conventions without one giant file. Start with a single file at the root and split only when it gets unwieldy.

Why check the rules file in instead of everyone keeping their own?

Because an agent’s output is only as consistent as the rules it reads, and a team wants consistency across people, not per-person styles.

If each engineer keeps private rules, the same repo gets style-A from one agent and style-B from another, and review turns into a style war the tool created. A checked-in file means every agent starts from one source of truth, changes to it are reviewed, and a new hire inherits the conventions on day one instead of rediscovering them.

Review and CI: no fast lane for AI code

Here is the rule that matters most, and the one teams get wrong: AI-written code goes through the exact same review and test gates as any other code. Same PR template, same required reviewers, same CI, same coverage bar. You do not create a fast lane because a machine wrote it.

The temptation is real. The diff looks clean, the agent’s tests are green, and it is tempting to wave it through. Resist that. As the review article argued, the tool stops when it thinks it is done, not when the change is correct, and that gap does not close because the author was an agent. If anything, AI diffs deserve more scrutiny: they are large, confident, and plausible-looking, exactly the profile that slips past a tired reviewer.

Norms that hold up on a team:

Author is the human, not the tool. Whoever ran the agent owns the PR and answers for every line, same as if they typed it.
Disclose AI involvement in the PR. Not to shame it; to tell the reviewer the change may be broad and worth reading in full rather than skimming.
CI is the non-negotiable floor. Tests, linting, type checks, and a security scan run on every PR regardless of who or what wrote it. No pass, no merge.
Cap the blast radius. A 900-line diff across 30 files is not reviewable. Ask the author to split it, same as you would for a human.

The gates are the whole point. They are what let you use a fast, occasionally-wrong code generator without shipping fast, occasionally-wrong code.

Security: secrets, permissions, and data leaving the machine

An AI coding tool can read your files, run shell commands, and send code to a model provider. Each is a security surface. Set defaults once, at the team level, so nobody has to make the call under pressure.

Secrets. The tool reads your repo, so anything committed is fair game for it to load into a prompt. Keep secrets out of the repo, use env vars, and make sure your .gitignore and any tool-level ignore file both exclude .env, credential files, and local config. Where a tool supports a secret-scanning or ignore list, configure it so the agent never reads credential files even if one slips in.

What the tool is allowed to run. Agent mode can execute shell commands. Decide as a team what runs without a human clicking approve. A safe default: auto-approve read-only and local commands (ls, grep, running tests) and require confirmation for anything that mutates state or reaches the network (git push, rm, curl, migrations, package installs). Most tools expose this as an allowlist and a denylist.

{
  "permissions": {
    "autoApprove": ["read_file", "search", "run_tests", "npm run lint"],
    "requireApproval": ["git push", "rm", "curl", "db:migrate", "npm install"],
    "deny": ["read .env", "read secrets/**"]
  }
}

Data leaving the machine. Your code goes to whichever model provider the tool uses. Settle three questions before rollout: does the vendor train on your code (pick a plan or setting where they do not), where is the data processed, and does that satisfy your compliance obligations. For regulated data, check for a zero-retention or self-hosted option and get it in writing. This is a procurement conversation, not a per-engineer choice.

flowchart LR
    REQ[Agent wants<br/>to run a command] --> CHECK{On allowlist?}
    CHECK -->|yes| RUN[Run it]
    CHECK -->|no| ASK[Ask human<br/>to approve]
    ASK -->|approved| RUN
    ASK -->|denied| STOP([Blocked])

Measuring impact honestly

Someone will ask if the tools are worth the money. Answer with something better than vibes, but be honest that the easy metrics lie. Lines of code and PRs opened both go up with these tools, and neither tells you whether you are shipping value. A tool that generates twice the code can generate twice the code you have to maintain.

Better signals for tracking adoption:

Cycle time: from starting a task to merged. Captures the whole loop, including review, which is where AI code adds load.
Change failure rate and revert rate: are AI-heavy changes causing more incidents or rollbacks? If quality drops, faster is not better.
Review time per PR: watch this go up. More generated code means more to review, and that cost is real.
Developer sentiment: a short, honest survey beats a dashboard for whether the tools actually help.

Two failure modes to watch for, because they are quiet and expensive:

Over-trust. As the team gets comfortable, scrutiny drifts down. The diffs keep looking clean, so people read them less closely, right up until a plausible-but-wrong change ships. Keep review standards fixed regardless of the author.

Review fatigue. More code means more to review, and reviewers burn out or start rubber-stamping. If your review queue is growing and review time per PR is falling, that is not efficiency, that is skimming. The fix is smaller PRs and a hard line on unreviewably large diffs, not faster clicking.

Common beginner mistakes

Personal rules files: everyone keeps their own conventions, so the repo gets inconsistent output. Check one file in.
A fast lane for AI code: waving through diffs because they look clean. Same gates as everything else.
No command allowlist: letting agent mode run anything, so a curl or a migration fires without review.
Committed secrets: assuming the tool will not read a .env that is sitting in the repo. It will.
Measuring lines of code: rewarding volume when the goal is shipped, working, maintainable change.
Ignoring review load: celebrating faster authoring while the review queue quietly buries the team.

Questions you will face in production

“Should we ban AI coding tools until we have a policy?” Usually no; people will use them anyway, just invisibly. Better to make it explicit fast: check in a rules file, set the command permissions, confirm the vendor does not train on your code, and state that AI code goes through normal review. A lightweight written policy beats a ban that gets ignored.

“How do we stop the review queue from exploding?” Cap PR size and hold the line. The discipline you would apply to a human who opens a 900-line PR applies here, and it matters more because agents produce big diffs by default. Smaller, scoped changes keep review honest and cycle time real.

“Leadership wants a productivity number. What do I give them?” Give cycle time and change failure rate, not lines of code or PR count. Pair the numbers with a short sentiment check. If quality metrics hold and cycle time drops, that is a real win; if failure rate climbs, the tool is costing more than it saves and the number should say so.

What to remember

Team adoption means moving guardrails out of your head and into the repo
Check the rules file in; review changes to it like code, so every agent shares one source of truth
AI code goes through the same review and CI as any code; no fast lane
Set command allowlists and denylists so risky actions need a human
Keep secrets out of the repo and confirm what the vendor does with your code
Measure cycle time, failure rate, and review load, not lines of code; watch for over-trust and review fatigue

What to study next

That closes out AI coding tools. Under every one of them is the same machine: an LLM in a loop with tools, deciding what to read and change. To understand what they are actually doing when they plan a change, run a command, and observe the result, go back to the engine. Start with what an AI agent actually is; the coding tools are that loop pointed at your repo, and everything in this topic was a special case of it.