What do we forbid? The team policy, and the numbers that prove it worked
Most teams have the "should we use AI" meeting. Few write the policy down. One page, five numbers, and the question that settles it.
Most teams have the "should we use AI" meeting. Few have the "what is our team's AI policy, written down" meeting. The second one is the one that pays off, because it is the only place where the engineers' rules and the business's expectations are in the same document.
The list is shorter than you think
What the agent may touch, and what is off limits. Legacy code unless the task says migrate, generated code, anything with a compliance footprint. One line per exclusion.
What every AI-assisted pull request includes. The task it executed, the diff size, the commands that passed. If the PR cannot say which task file it came from, it did not come from one.
What never goes into a prompt. Customer data, credentials, anything under NDA.
Which tool is standard. So that rules, skills and instruction files are shared instead of per developer. The rules live in AGENTS.md; the standard tool's extras live in its thin file. Everyone else's tool reads the same rules.
Where the exceptions are written. Every rule above will get one: a classic @Input() kept on an upgraded component, a one-off script exempt from the size cap, a synthetic data sample allowed into a prompt because nothing in it is real. Each one gets a short , dated, with the reason, and AGENTS.md points at the folder, so the agent reads them too.
The exception is fine. The undocumented exception is the rule dying quietly.
That is the policy. One page. It takes a team an afternoon to write and it is the afternoon that decides whether the next year is the faster team or the dead project.
The numbers, or it stays a feeling
The business has one number today: the demo took an afternoon. The team has none, and a feeling of speed is not a number: in one trial in early 2025, experienced developers expected AI to make them 24% faster, and it made them 19% slower. So the second half of the policy is five numbers, per module, tracked for the fast way and the team's way side by side:
| Metric | How to get it | Why the business cares |
|---|---|---|
| Cycle time per change | ticket opened to merged, in working days (not 's commit-to-deploy lead time) | replaces the demo's afternoon with a real number |
| Review rework | lines changed in review divided by lines in the first PR | how much of "fast" was redone |
| Review load | comments and review hours per PR | the hidden cost of the big diff |
| Escaped defects | bugs in the module in the 30 days after release | ends the "it works on screen" argument |
| PR size | files and lines per PR | the lever the team controls directly |
Other teams have seen the fast way's pattern. Across 10,000 developers, high AI adoption came with 98% more merged pull requests, 154% bigger ones and 91% longer reviews. Small changes get their first review comments faster, and DORA found that working in small batches amplifies AI's positive effect on the product.
Rules: measure the fast way too, honestly, so it is a comparison and not an accusation. Report monthly, one page, no names. Propose it as help, "here is how we show progress to the board", not as defence.
Our guess is that the team's way is slower on the first module and faster by the third, with lighter reviews and fewer escaped bugs. DORA expects a similar early dip when teams adopt AI, but no one has measured our case. That is why we count. If that does not show up, the team's way needs to change too, and the numbers will say where.
Read AGENTS.md, package.json (its scripts), the lint and boundary configuration, docs/tasks/TEMPLATE.md and, if the repo has any, the descriptions of the last ten pull requests (gh pr list). Draft our one-page AI policy under these headings: what the agent may touch; what every AI-assisted PR includes; what never goes into a prompt; the standard tool and where its extras live; where exceptions are recorded. Where the repo already states a rule, cite the file and say whether a tool enforces it or only text states it. Where a rule exists only in people's heads, write "UNWRITTEN" and propose the line. Do not invent rules the repo does not hint at.
The "UNWRITTEN" list is the real output. It is the gap between the policy the team believes it has and the one the agent can read.
The question that settles it
When the demo is shown upstairs, and it will be, one question cuts through most of the meeting:
Do you want this to work only this year, or do you want it still safe and maintained in five?
Everything in this track follows from the answer. If the answer is five years, the policy above is the plan, the numbers are the proof, and the agent earns its speed. If the answer is this year, nothing in this series will help, and that is also an honest answer.
On Monday
- Write the one-page policy. An afternoon, the whole team, the five headings above.
- Start the five numbers on the next module, both ways, honestly.
- Put the policy in the repo next to
AGENTS.md, so the agent reads it too.
Exercise: run the prompt above on the demo repo. AGENTS.md, the lint configuration and docs/tasks/TEMPLATE.md already cover most of the headings.
Sources
- , Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, July 2025
- DORA, DORA's software delivery performance metrics
- Faros AI, The AI Productivity Paradox Report 2025, July 2025
- Sadowski et al., Google, Modern Code Review: A Case Study at Google, ICSE-SEIP 2018
- DORA, Introducing DORA's inaugural AI Capabilities Model, September 2025
- DORA, How to measure the business value of generative AI, June 2026
The closing part of the free series behind the Fast and safe: AI in your Angular codebase workshop. In the room, your team writes the longer version of this page before it leaves.
Fast and safe: AI in your Angular codebase
Let agents write Angular under rules, modernise legacy code without breaking production, and keep it secure, in three days, on an enterprise-shaped codebase.
See the agenda