Edison SinaniAI implementation architectBook a call

AI Team Playbook

How to run a small development team on AI coding agents

Twelve rules for a team of three to six developers and one lead. Each rule is one short page: what the rule is, why, how, and what enforces it. The files behind every rule are in a kit I send by email.

September 16, 2026 · This page about 5 minutes, all pages about 46 · Start with rule 1

Contents

The playbook

  1. Overview

Before code

  1. 1Write the constitution first
  2. 2One instruction file, under 200 lines
  3. 3Prose is advice, hooks are enforcement
  4. 4Three gates before any code
  5. 5A walkable demo before any screen

Building

  1. 6One task, one worktree, one pull request
  2. 7Every contract has a file and two tests

Reviewing

  1. 8AI review first, and filtered
  2. 9Human review by risk tier
  3. 10Done means the evidence is in the pull request

Over time

  1. 11Measure five numbers from day one
  2. 12Protect the people who are still learning

Appendix

  1. AInstall checklist
  2. BOther tools, limits and sources
  3. CTightening the process
  4. DRun the agent with no entitlements

Get the kit

What this is

I built two production AI systems on my own, with coding agents writing most of the code. That way of working is fast for one person and does not survive a second. Pull requests get bigger, the review queue gets longer, two agents on neighbouring files produce merge conflicts nobody saw coming, and nobody can say whether the team is faster. They can only say it feels faster.

This is the way of working I use now with teams. It is twelve rules. Every rule has a reason, and where a published study backs the reason, the number and its source are on the rule’s page. Where no number exists, I say so. It is written for Claude Code first, and the last page maps every file to Cursor, GitHub Copilot, Kiro and Codex.

Who it is for

A team of three to six developers and one lead, already shipping software, either adopting agents together or trying to get an existing adoption under control. Nobody gets a new title. What changes is what each existing role owns.

It is not for a solo developer, who needs only rules 2 and 3. It is not for a thirty-person organization, where the lead’s role becomes a platform group. And it is not for a team that wants a headline speed number to show a sponsor. The last of the twelve rules explains why.

What a rule can and cannot do

Nothing in this playbook stops a developer from breaking a rule. The files live in the repository, on each developer’s machine, and anyone who can edit code can edit a hook. Nobody prevents you from running a red light either. What stops you is what happens after.

Here, what happens after is a pull request. Every change goes through one, an automated reviewer reads it, and a human reviewer has a say before it merges. The hooks and settings keep the agent inside the lines during a session. The pull request and the reviewers keep the developer inside the lines, and they run on the git host, where a local edit changes nothing.

For a team of this size that is enough, because every pull request is seen. A team that wants more can tighten it. Appendix C shows how to put the rule files under the lead’s ownership, so no change to them can merge without the lead, and how to make the checks impossible to remove from inside a pull request.

What goes wrong when a team adopts agents

Three findings shaped the rules more than any others. Each names its source.

Review becomes the bottleneck, not writing code.

Across 22,000 developers over two years, moving from low to high AI adoption raised pull requests merged per developer by 16 percent, raised the median time a pull request spends in review more than five times, raised bugs per developer by 54 percent, and raised the share of pull requests merged with no review at all by 31 percent [1]. The year before, the same telemetry had already shown pull requests merged nearly doubling and pull request size growing 154 percent on teams with high adoption [2].

What agent adoption did to the pull request queueChange from low to high AI adoption, across 22,000 developers and two years of telemetry. Faros AI, 2026. 1
Pull requests merged per developer
+16.2%
Median time in review
+441.5%
Bugs per developer
+54%
Merged with no review at all
+31.3%

Small pull requests are not optional.

In 107,026 agent-written pull requests, the smallest tenth, with a median of two lines changed, would have conflicted on merge about 10 percent of the time. Pull requests of 46 to 185 changed lines conflicted 32 to 33 percent of the time [3].

Merge conflicts grow with PR sizeShare of agent-written pull requests that would have conflicted on merge. The smallest tenth of PRs has a median of two changed lines. 107,026 PRs. 3
Smallest tenth of PRs
about 10%
PRs of 46 to 185 lines
32% to 33%

Do not trust the feeling of speed.

In the best randomized study so far, experienced developers were 19 percent slower with AI while believing they were 20 percent faster [5].

Felt faster, measured slowerTime to finish a task with AI allowed, relative to without. 16 experienced developers on repositories they maintain, 246 tasks. METR, 2025. 5
Developers' own estimateMeasured
What the developers estimated
20% faster
What was measured
19% slower
slowerno changefaster

Every team that has published a working setup did the same three things. It capped pull request size. It put an automated reviewer in front of the human. It sorted changes by risk so the human queue only holds what needs a human. Those are rules 6, 8 and 9. The other nine rules are what make those three possible.

How the rules fit together

The first five rules happen before any code is written. The next two are about building. The next three are about review. The last two keep the whole thing working over time. One principle runs through all twelve, and it comes from Anthropic’s own guidance for Claude Code: prose in an instruction file is advice, hooks and settings are enforcement [13]. Every rule page says what enforces it.

Who owns what, in one table:

Role Owns
The lead The constitution, the system design, the agent configuration, approval at the three gates, review of every High risk change, the weekly numbers
Every developer The requirements, design and tasks for their own features, one worktree and one pull request per task, the automated review findings on their own pull requests
The reviewer of record, rotating each milestone Every change to the system design during that milestone

The twelve rules

One page each. Every page has the same shape: the rule, who owns it, the files in the kit, what enforces it, then why and how.

Before code

  1. 1Write the constitution firstThe stack and the rules that never change, on one page. About 2 minutes.
  2. 2One instruction file, under 200 linesOnly what the agent cannot learn from the code. About 2 minutes.
  3. 3Prose is advice, hooks are enforcementAnything that matters is blocked by a script, not asked for in a sentence. About 2 minutes.
  4. 4Three gates before any codeRequirements, design, tasks, each approved by the lead. About 2 minutes.
  5. 5A walkable demo before any screenA clickable prototype the lead has walked through, kept after shipping. About 2 minutes.

Building

  1. 6One task, one worktree, one pull requestUnder 400 changed lines, in its own working copy. About 2 minutes.
  2. 7Every contract has a file and two testsWhere two components must agree, a test on each side catches a silent break. About 2 minutes.

Reviewing

  1. 8AI review first, and filteredAn automated first pass on every pull request, tuned until people trust it. About 2 minutes.
  2. 9Human review by risk tierLow, Standard or High on every task, and the tier decides who reviews. About 2 minutes.
  3. 10Done means the evidence is in the pull requestThe check passed, and the pull request shows it. About 2 minutes.

Over time

  1. 11Measure five numbers from day oneA weekly baseline, started before anything else changes. About 2 minutes.
  2. 12Protect the people who are still learningManual first, explain before merge, and a four-week rollout. About 2 minutes.

Appendix

  1. AInstall checklistTen steps, in order, each with a check that proves it worked. About 8 minutes.
  2. BOther tools, limits and sourcesCursor, Copilot, Kiro and Codex, what the playbook does not solve, and every source. About 2 minutes.
  3. CTightening the processOptional. Locks the rule files themselves, for teams that want more than review. About 3 minutes.
  4. DRun the agent with no entitlementsOptional. A bounded identity and a bounded budget, set by the team and enforced by the tool. About 4 minutes.

References

  1. 1Faros AI, "The AI Engineering Report 2026: The Acceleration Whiplash", April 2026. Telemetry from 22,000 developers and more than 4,000 teams over two years. www.faros.ai/blog/ai-acceleration-whiplash-takeaways
  2. 2Faros AI, "The AI Productivity Paradox", July 2025. Telemetry from more than 10,000 developers across 1,255 teams. www.faros.ai/blog/ai-software-engineering
  3. 3Daniel Ogenrwot and John Businge, "AgenticFlict: A Large-Scale Dataset of Merge Conflicts in AI Coding Agent Pull Requests on GitHub", arXiv 2604.03551, April 2026. 107,026 pull requests. arxiv.org/abs/2604.03551
  4. 5METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity", July 2025. Randomized controlled trial, 16 developers, 246 tasks. metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
  5. 13Anthropic, Claude Code documentation, "Best practices for Claude Code". code.claude.com/docs/en/best-practices

If you want it installed with you

The lead's role in this guide is the job I do on a fractional basis. Advisory is a standing weekly call and async review of designs and pull requests within one business day. Fractional adds ownership of the technical roadmap.

Book a callAll four engagement shapes