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 53 · Start with rule 1
How this started
In 2026 I built CargoLint and Duly Qualified, and I used coding agents for most of the implementation. I worked the same way on both. I picked the stack, wrote a detailed architecture document, and turned it into a plan with stories. Then I built one ticket at a time and tested each task as it closed. For every screen, I built a walkable demo first and wrote the UI code from it.
That process worked well for me. The problems started when other people joined the CargoLint team. Pull requests got too big to review quickly. Work on different tasks collided, with merge conflicts and changes that broke other components. And each of us used the agent in a different way, with different instructions.
The first things we put in place were one instruction file and a constitution that every agent reads, a limit on pull request size, and an automated first review before a person looks at a change. Then I read the published studies and the setups other teams have written up, and I wrote down the rest of the rules.
The result is twelve rules. Each rule has a reason. Where a published study backs the reason, the number and its source are on the rule’s page, and where no number exists, the page says so. The playbook 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 that already ships software. Some teams are starting with agents together. Others already use them and want more control over how. The team keeps its existing roles. Each role takes on a few new responsibilities.
If you work alone, rules 2 and 3 are the ones you need. A larger organization would put a platform group where this playbook has a lead, and the playbook does not cover that.
What the rules can and cannot do
No rule here can stop a developer who wants to break it. The files live in the repository, and a developer who can edit code can also edit a hook. So the check happens at the pull request.
Every change goes through one. An automated reviewer reads it first, and a human reviewer approves it before it merges. Hooks and settings limit what the agent can do during a session. The review runs on the git host, so editing the rule files on a laptop does not change it. For a team of this size, where every pull request is seen, my read is that this is enough.
A team that wants more control 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.
Three findings behind the rules
Three published findings shaped the rules more than any others.
Review becomes the bottleneck.
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].
Bigger pull requests conflict more often.
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].
Felt speed and measured speed can differ.
In a 2025 randomized study by METR, experienced developers were 19 percent slower with AI while believing they were 20 percent faster [5].
The published setups I read have three practices in common. They cap pull request size, put an automated reviewer in front of the human, and sort changes by risk so the human queue only holds changes that need a person. Those are rules 6, 8 and 9. The other nine rules support those three.
How the rules fit together
Rules 1 to 5 happen before any code is written. Rules 6 and 7 cover building. Rules 8 to 10 cover review. Rules 11 and 12 keep the setup working over time. One idea runs through all twelve, and it comes from Anthropic’s guidance for Claude Code: text in an instruction file is advice, and hooks and settings are enforcement [13]. Every rule page says what enforces it.
Who owns what:
| Role | Owns |
|---|---|
| The lead | The constitution, the system design, the agent configuration, approval at the three gates within one working day, 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, and the tasks gate if the lead delegates it |
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
- 1Write the constitution firstThe stack and the rules that never change, on one page. About 2 minutes.
- 2One instruction file, under 200 linesOnly what the agent cannot learn from the code. About 2 minutes.
- 3Enforce the rules with settings and hooksAnything that matters is blocked by a script. About 4 minutes.
- 4Three gates before any codeRequirements, design, tasks, each approved by the lead. About 2 minutes.
- 5A walkable demo before any screenA clickable prototype the lead has walked through, kept after shipping. About 2 minutes.
Building
- 6One task, one worktree, one pull requestUnder 400 changed lines, in its own working copy. About 2 minutes.
- 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
- 8AI review first, and filteredAn automated first pass on every pull request, tuned until people trust it. About 3 minutes.
- 9Human review by risk tierLow, Standard or High on every task, and the tier decides who reviews. About 2 minutes.
- 10Done means the evidence is in the pull requestThe check passed, and the pull request shows it. About 2 minutes.
Over time
- 11Measure five numbers, baseline firstBackfilled from git history before anything changes, then one row a week. About 3 minutes.
- 12Protect the people who are still learningManual first, explain before merge, and a four-week rollout. About 2 minutes.
Appendix
- AInstall checklistTen steps, in order, each with a check that proves it worked. About 11 minutes.
- BOther tools, limits and sourcesCursor, Copilot, Kiro and Codex, what the playbook does not solve, and every source. About 2 minutes.
- CTightening the processOptional. Locks the rule files themselves, for teams that want more than review. About 3 minutes.
- 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
- 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
- 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
- 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
- 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/
- 13Anthropic, Claude Code documentation, "Best practices for Claude Code". code.claude.com/docs/en/best-practices
Get the kit
The folder this guide describes, ready to copy into a repository. Enter your email and I will send you the link.
Sent by Edison Sinani, 895 Don Mills Rd, Two Morneau Shepell Centre, Suite 900, Toronto, Ontario M3C 1W3, Canada. Every message carries this address and an unsubscribe link, honoured within 48 hours.
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.