AI in the Team: Policy, Measuring Impact, Junior Growth and When Not to Use It

Version note: The files and commands in this post were tried in the Bookstore repository with .NET 10 and Git 2.54. Research and tool information is as of November 2026.

Guess First

Company management set a target: within three months, 80% of commits will be written with AI help, and every team's rate will be shown on a dashboard. What will Emre and Ayşe on the Bookstore team do to hit that target? After three months the rate on the dashboard has most likely gone up. But in the same period, which way do the time for changes to reach production, the number of rolled-back deployments and the queue of pull requests waiting for review go?

To guess, remember two findings from the first post: according to DORA 2025, AI adoption increases throughput but also instability; in METR's measurement, developers believed they were faster while they were slower. As the last post of the series, this one moves from individual use to the team: policy, measurement, juniors' growth and the places where not using AI works better.

A Team AI Policy: Short, Written and in the Repository

In a team without a policy, everyone applies their own rules: one pastes customer data into a prompt, another feeds company code to a web interface with a personal account, a third sets the agent to run every command without approval. Writing a policy is less about forbidding these than about setting the team's defaults. Bookstore's policy lives in the repository, next to the code:

# AI policy — Bookstore team

Last reviewed: 2026-11. Owner: tech lead. Reviewed every six months, or when a tool changes its data terms.

## Tools
- Company plans of the approved coding assistants only. No personal accounts or free plans for company code.
- Agents ask before running commands. Auto-approve only inside a container with no credentials.

## Data
- Never in a prompt or an agent's context: secrets, connection strings, production data, customer personal data.
- Example data comes from the seed (Ada, Alan, Grace; Dune, Emma, The Hobbit).

## Work
- The person who opens the pull request owns the code, whoever wrote it.
- Commits with substantial AI help carry the trailer `AI-Assisted: yes`; the PR template asks the same.
- A written plan (docs/plans/) first for work that touches the data model, more than one module, or security.
- AI review is a pre-filter. It never counts as a required approval.

## Extra care
- Authentication, authorization, payments, cryptography: two human approvals, one from someone who knows the area.
- Unclear requirement: clarify it with the Product Owner before asking an agent.

## Learning
- Learning tasks (new area, onboarding): try for 30 minutes first, write the tests yourself.
- Before accepting AI code, be able to explain every line to the reviewer.

## Measuring
- We watch change lead time, change fail rate, deployment rework rate and review time per pull request.
- We do not use lines generated, suggestion acceptance rate or "AI usage %" as targets.

There are no tool names in the file, on purpose. The tool list can change elsewhere; the policy says "company plans of the approved tools" and defines where data may go. This is also where the legal side starts: when Bookstore's customer data is sent to a cloud provider, that is a data transfer under KVKK, Turkey's personal data protection law No. 6698,, and if the provider is abroad it is subject to the conditions of Article 9 of that law (safeguards such as standard contracts, under the amendment in force since 1 June 2024). This is not legal advice; write the data section of the policy together with your company's legal team.

The line at the top of the file matters too: "reviewed every six months". Tools change every month, but changing team practice every month means a team where nobody remembers the rules. Keep the policy stable and update the tool list and settings separately.

DORA's Seven Capabilities in Bookstore

The DORA 2025 report proposed a model of seven capabilities that amplify AI's positive impact on organizational performance. Its finding is that the benefit of AI depends more on this environment than on the tool. This is how I map the seven capabilities to Bookstore, in my own words:

Looking at the table, the previous five posts of the series turn out to be small pieces of these capabilities. A team without an AI policy, that does not work in small batches and has weak tests, gets very different results from the same tools than the Bookstore team. That is exactly the report's "amplifier" finding.

Declaring AI Use in Pull Requests

The point of declaring AI use is not to blame anyone but to inform the reviewer: in a diff written by an agent, test changes and edge cases get a closer look. Bookstore has two places for this. The first is the pull request template:

## What and why


## How it was verified
- [ ] `dotnet test` (and `npm test` for web changes) is green locally
- [ ] Edge cases covered by tests:

## AI assistance
- [ ] No AI help
- [ ] AI helped with (code / tests / review / docs):
- [ ] I read every line of the diff and can explain it
- [ ] No test was deleted, skipped or loosened (or the reason is written above)

The "I read every line and can explain it" box is the practical form of the responsibility rule from the fourth post. The second place is the commit history. Git trailers, the Key: value lines at the end of a commit message, fit this well; AI-Assisted is a name we chose, not a special key Git knows about:

> git commit -m "06: team AI policy and PR template" -m "AI-Assisted: yes"

> git log --format='%h %(trailers:key=AI-Assisted,valueonly,separator=%x2C) %s'
e37343a yes 06: team AI policy and PR template
3d74070  05: package check script, secret hygiene rules
f32516c  04: move wishlist item to cart via ICartService; review instructions
5b4bb5f  03: wishlist module, migration AddWishlists
2137978  03 step 1: wishlist plan and failing tests
b7a95f6  02: context files
e92fbdb  01: isbn experiment
1031c70  main baseline

> git log --format='%(trailers:key=AI-Assisted,valueonly,separator=%x2C)' | sort | uniq -c
   7
   1 yes

Because the rule has just started, only one of eight commits is marked. That number is not a target; it is data for answering questions later, such as "are fix-up commits more frequent after AI-assisted commits?". The moment you turn it into a target, everyone starts adding the trailer to every commit, as in the opening scenario, and the data loses its meaning.

Measuring Impact: What to Watch and What Not To

You do not need new metrics to measure AI's effect on a team; the metrics that already measure delivery performance are the best indicators. DORA's current definitions have five. On the throughput side there are change lead time, deployment frequency and failed deployment recovery time; lead time runs from commit to production. On the instability side there are change fail rate, the share of deployments that need immediate intervention, and deployment rework rate, the share of unplanned deployments caused by a production problem. How to measure them is covered in the eighth post of the CI/CD Fundamentals series.

For AI I add two indicators: review time per pull request and the number of changes requested in review. If code generation speeds up while review time grows, the bottleneck has moved; as we said in the third post, review capacity sets the number of parallel agents.

The misleading metrics are the easy ones: lines generated, suggestion acceptance rate, "AI usage percentage" and developers' own speed estimates. The first three look better the more code is produced; the fourth, as METR showed, can point the opposite way from the measurement. They are useful for tracking tool adoption, but as productivity targets they push behavior in the wrong direction.

Put cost in the same table. Agent sessions and AI review spend tokens or credits; as we saw in the fourth post, the average for Copilot code review's highest effort level is about 10 dollars per pull request. At the end of the month, ask "how much did we spend" and "what happened to lead time and change fail rate" together. Looking at only one of them leads to wrong decisions.

Juniors and Skill Loss

In a randomized trial Anthropic published on 29 January 2026, 52 software engineers (mostly junior) did a small task with Trio, a Python async library they did not know; one group used an AI assistant and the other did not. Right after the task they took a quiz without AI. The AI group averaged 50% and the hand-coding group 67%; the gap was largest on debugging questions. The AI group finished about two minutes faster, but the difference was not statistically significant. The authors also note that the sample was small and that the quiz measured understanding right after the task, not long-term learning.

The most useful part of the study is how results split by the way people used AI. Those who delegated the work entirely and those who had the AI fix their errors scored low. Those who asked only conceptual questions, asked for code together with an explanation, or asked follow-up questions to understand generated code scored high. So the problem is not AI itself but handing all the thinking over to it.

Bookstore's rules for juniors follow from this. On a learning task, try on your own for 30 minutes first and write the tests yourself. When you ask AI for code, get to the point where you can explain every line to the reviewer before accepting it; if you cannot, ask. When debugging, read the stack trace yourself and form a hypothesis before pasting the error into the model. The senior's role changes too: in a junior's pull request, review not only the code but also the answer to "why did you do it this way?". A diff the junior cannot explain is a diff the AI wrote and the junior merely forwarded.

When Not to Use It

For some work, not using AI, or using it only with extra checks, gives better results:

• Security-critical code: authentication, authorization, payments and cryptography. Mistakes are expensive, and plausible-looking but wrong code is at its most dangerous here. If AI is used, require two human approvals, one from someone who knows the area.
• Unclear requirements: an agent silently fills the gap with an assumption, like the Quantity field in the third post. Clarify with the Product Owner first.
• Very small changes: describing a one-line fix to an agent takes longer than writing it, and adds review cost.
• Learning tasks: if the goal is to build a skill rather than code, handing the work to AI removes the goal.
• A subtle change in a long-lived system with a high quality bar that you know best: that was exactly METR's 2025 setting.

The list does not say "AI is bad"; it says AI saves the most where its correctness is cheap to check, and the risk grows where checking is expensive or impossible.

In Production

A policy needs technical counterparts; a written policy that is not enforced gives a worse sense of safety than having none. In Bookstore every item of the policy has a control: secret scanning and push protection for secrets, eng/check-packages.cs and NuGetAudit for packages, CI for tests, a required human approval in branch protection for AI review, approved-command settings for agents. If an item has no control, either add one or state plainly that the item is only a recommendation.

Keep measurement at team level. A per-person "how much faster did AI make you" dashboard pushes people to act for the measurement and ends honest feedback. Asking one AI question in team retrospectives (where did AI save time this sprint, and where did it cost time?) often gives more reliable information.

Common Pitfalls

• Making AI usage a mandatory metric or target: the rate goes up while delivery performance stands still or gets worse.
• Reflecting tool changes in team practice every month: nobody knows which rule applies.
• Measuring productivity with line counts and suggestion acceptance rates.
• Writing the policy without setting up its technical controls.
• Letting juniors hand their learning tasks to an agent as well.
• Tracking cost and delivery metrics separately.

A Small Experiment

★☆☆ Write a draft of this post's policy for your team in no more than 15 lines, and next to each item note which technical control protects it. Which items have no control?

★★☆ From the last three months of pull requests, extract change lead time and review time per pull request (GitHub's pull request data or your platform's API is enough). How did both change before and after AI use became widespread?

★★★ Pick a learning task with a junior on your team. Have them do it first without AI, then do a second task of the same kind with AI, asking only conceptual questions. At the end of both, prepare a short, debugging-heavy question set and discuss the results together.

The series ends here. In six posts we built a tool-neutral framework: the right expectation, context for agents, working with a plan, review, security and the team. If you want to see a specific tool's settings, permission modes and workflows in detail, continue with the Claude Code and OpenAI Codex series; for using chat interfaces in daily work, the Working with Claude and Working with ChatGPT series; and for writing your own agent and MCP server, the AI Agents and MCP series.