Claude Code for teams: rolling out AI coding assistants properly

Why individual speed doesn’t add up to team speed

Most engineers feel faster with an AI assistant, and for many tasks they are. But the evidence on team-level AI coding productivity is more mixed than the marketing. A 2025 randomized study by METR found experienced open-source developers took longer to finish tasks in their own repositories with AI tools, while believing they’d been faster. METR’s 2026 follow-up says developers are probably sped up more by newer tools, but that its data is too weak to say by how much. Google’s DORA research has reported that higher AI adoption was associated with worse delivery stability, alongside gains in individual flow.

The mechanism isn’t mysterious. Writing code was rarely the bottleneck. Review, integration, testing and deciding what to build were. AI makes the cheap part cheaper and can make the expensive part more expensive: bigger PRs, more plausible-but-wrong code to review, more duplicated logic. A rollout has to address the whole pipeline, not just the editor. If delivery was already slow before AI, the cause is usually elsewhere – see why is my engineering team slow.

Step 1: choose tools and set the data boundary

Pick one primary tool for the pilot rather than letting each engineer choose; shared conventions and shared learning matter more than marginal differences between tools. Claude Code is a terminal- and IDE-based agent that edits files and runs commands; Cursor is an AI-first editor with its own agent; Copilot lives inside existing editors. All of them offer business or enterprise plans with admin controls.

Before anyone connects the tool to your codebase, settle the data questions: which plan, whether code and prompts are retained and for how long, whether they can be used for training, where processing happens, and whether that’s acceptable under your customer contracts. These terms differ by plan and change over time, so read the vendor’s current terms rather than relying on someone’s summary. Consumer accounts on company code should be off the table.

Step 2: write conventions files

AI agents start each session knowing nothing about your codebase. Conventions files fix that, and writing them is the most valuable hour you’ll spend on the rollout. Claude Code reads CLAUDE.md files from the repository (and subdirectories); Cursor uses project rules in .cursor/rules; Copilot reads .github/copilot-instructions.md; and AGENTS.md is a shared convention most tools now read, Claude Code included. Pick one as the source of truth and point the others at it.

What goes in:

• Commands: how to install, run, test, lint and type-check – exactly, so the agent can verify its own work.
• Architecture map: the main modules, where business logic lives, which layers may call which.
• Conventions with examples: “use the existing ApiClient in lib/http, never fetch directly”; “money is integer cents”; “all queries go through the tenant-scoped repository”.
• Don’ts: files never to edit (generated code, vendored libraries), patterns that are deprecated, dependencies not to add without asking.
• Definition of done: tests added, types pass, no new lint warnings, migration reviewed.

Keep it short – a page or two – and specific. Review changes to it like code. When the agent makes the same mistake twice, the fix goes in the conventions file, not in a Slack message.

Step 3: permissions, secrets and sandboxing

An agent that can run shell commands runs them with the developer’s credentials. Treat that seriously:

• Permission rules in the repo. Claude Code supports allow and deny rules in a checked-in settings file, so you can let it run tests and linters freely, require confirmation for anything else, and deny reads of .env files and credential directories. Cursor and others have equivalent controls. Commit a team baseline.
• No production credentials on developer machines, and certainly none an agent can reach. Agents should work against local or staging data.
• Secret scanning in pre-commit hooks and CI (for example gitleaks or your platform’s built-in scanning), because agents will happily paste a key into a test fixture.
• Hooks for guardrails. Run formatters and linters automatically after edits, and block commands you never want run.
• Vet MCP servers and plugins. Each one is code running with your permissions and a channel for untrusted content to reach the model. Keep an approved list.
• Containers for autonomous runs. Longer unattended agent sessions belong in a dev container or sandbox with limited network access.

Step 4: change review rules before volume rises

The fastest way to lose the gains is a review queue full of large, plausible AI-written PRs. Set the rules before the volume arrives: the author owns and can explain every line, PRs stay small, sensitive paths need senior approval, test changes are reviewed as hard as code, and an AI reviewer runs as a first pass but never approves. The full policy template and what AI reviewers catch and miss are in the AI code review guide.

Step 5: measure impact honestly

Don’t measure lines of code, accepted suggestions or “percentage of code written by AI”. They go up regardless of whether anything got better. Measure the delivery system:

• Lead time for changes and deployment frequency – are things reaching users faster?
• Change failure rate and time to restore – is quality holding? These four are the DORA metrics.
• PR size and review time – is the review stage absorbing the extra volume?
• Rework rate – how often is recently merged code changed again within a few weeks?
• Developer experience survey – short, repeated, asking where the tools help and where they get in the way.

Take a baseline for at least a month before the rollout. Compare the pilot group with the rest of the team over the same period, and expect a dip in the first weeks while people learn. Self-reported time savings are useful for finding good use cases, not for proving ROI.

Where senior engineers matter more, not less

AI assistants shift the work toward the things seniors do best. Someone has to break a feature into tasks small enough for an agent to do well, write the spec and acceptance criteria, spot that a clean-looking diff puts logic in the wrong layer, and know which parts of the system can’t tolerate a subtle bug. Those are judgement calls, and AI makes the cost of bad judgement arrive faster.

Juniors need deliberate attention. An assistant can complete their tickets without them learning why the code works, which caps their growth. Pair them with seniors on agent sessions, ask them to explain AI-written changes in review, and have them write some critical code by hand.

A rollout plan that works

1. Baseline: capture DORA metrics, PR size and review time for a month.
2. Pilot: one team of volunteers, one tool, with an agreed data policy and permission baseline.
3. Conventions: write the conventions file in the first week; update it whenever the agent repeats a mistake.
4. Review rules: publish the policy and turn on the AI reviewer in comment-only mode.
5. Weekly show-and-tell: 30 minutes where people share what worked and what didn’t. This spreads good patterns faster than any training course.
6. Review at six to eight weeks: compare against the baseline, decide whether to expand, change tools or adjust the rules.
7. Expand team by team, each with an owner for its conventions file.

Common failure modes

• Seats bought, no conventions, no review changes – more code, same delivery.
• Measuring adoption instead of outcomes, then declaring success.
• Agents with access to production secrets or customer data on a laptop.
• Seniors opting out, so nobody experienced is shaping how the tools are used.
• Banning the tools after one bad incident instead of fixing the guardrail that failed.

Getting help

I use these tools on my own products, including Craaft, where AI agents and humans work the same kanban board through MCP and a REST API. If you want someone to run the rollout with your team – conventions, permissions, review standards and measurement, hands-on in the codebase – that’s the kind of work I do as an embedded engineering lead, starting with a two-week sprint.

Related

• AI code review: using AI reviewers and reviewing AI code
• An engineering lead for hire, embedded in your team
• DORA metrics for small teams: what to measure and how
• Developer productivity: why your engineering team is slow
• Is vibe coding bad? Where it works, where it breaks
• AI consulting services for software companies