Your team already has an AI working agreement

The question is whether it protects delivery flow.

Many teams ask whether they need an AI working agreement. They already have one. It is sitting in the first developer who asks ChatGPT for a refactor, the Product Owner who pastes a customer complaint into a model to reword it, the reviewer who accepts a model's comment without checking the surrounding context, and the agent that can read more of the repository than anyone on the team has discussed.

None of that was decided in a meeting. It was decided by whoever acted first, and the rest of the team inherited the default. The agreement exists. It is just unwritten, uneven from person to person, and invisible to the people responsible for delivery.

So the useful question is not whether to have rules. It is whether the rules you already have protect the way work moves through your team, or quietly work against it.

The unwritten agreement is already operating

Look at what your team decides every day without naming it.

Which tools are allowed. Someone is using a model, on some account, under some terms, and nobody has confirmed whether that is the free tier that trains on inputs or a business tier that does not. What data may go in. A customer email, a stack trace with internal hostnames, a snippet of proprietary code. Each of these has probably been pasted into a model by someone, and the boundary between "fine" and "reportable incident" is currently a matter of individual judgment. Whether generated code gets normal review. In some teams a pull request written with heavy AI help goes through the same review as anything else; in others it slips through faster because it looks finished. Whether AI use is disclosed on the work item at all. What test evidence has to accompany it. How much of the repository an autonomous agent may read, and whether it may write or trigger anything.

Every one of those is a rule. The team is following all of them right now. The problem is not an absence of rules. It is that the rules are implicit, inconsistent between people, and unavailable to anyone trying to reason about delivery. You cannot inspect a default you have never written down, and you cannot tell whether it is helping or hurting.

A written agreement does one thing worth the effort: it makes these defaults visible so you can check them against how work actually flows.

Adoption happens where AI meets the workflow

There is reasonable evidence that AI tools get adopted at the point where they fit an existing way of working, and stall where they do not.

Daniel Russo studied generative-AI adoption among software engineers with a mixed-methods design: a qualitative Gioia analysis of interviews with 100 engineers, then a PLS-SEM model validated on 183 software professionals (Russo, 2024, ACM TOSEM). Compatibility with existing development workflows came out as a predominant driver of intention to adopt. Not enthusiasm for the technology in the abstract, but fit with the work in front of people.

Stray, Barbala and Wivestad reached a compatible conclusion in a large public-sector organization, drawing on 13 interviews and 114 survey responses (Stray et al., 2025, FSE Companion). Workflow compatibility, organizational support, and the patterns other people around you already follow shaped how Copilot and ChatGPT were taken up. (The full text was not available for this piece, so I am relying on the reported summary rather than the detail.)

Both are self-report studies on non-representative samples, and neither measures delivery performance. Read them as evidence about where adoption enters, not proof of what it does to your cycle time. The practical read still holds: AI does not arrive as a policy. It arrives inside a specific workflow, whether that is code review, ticket writing, or a Product Owner drafting acceptance criteria, and it changes whatever sits around that step. That is where an agreement has to look, not at a company-wide statement about responsible use.

AI can move the queue

A tool policy tends to miss the queue. Faster output at one step does not mean faster delivery. It can mean more work arriving at the next step.

Song, Agarwal and Wen studied this on open-source projects using GitHub's proprietary Copilot data alongside public repository data, over project-months from January 2021 to December 2022, with a Generalized Synthetic Control method to estimate the effect (Song et al., 2024, arXiv). Copilot access was associated with about 5.9% more project-level code contributions. It was also associated with about 8% more coordination time, driven by more code discussion, and peripheral contributors saw the larger coordination-time increase.

This is open-source GitHub data in a preprint, not DACH enterprise delivery, so treat the numbers as directional rather than a benchmark for your team. But the shape of the finding transfers, and it matches basic queueing logic. If you raise the rate at which code is produced without raising the capacity that reviews, discusses, and integrates it, the extra output does not disappear. It waits. Reinertsen's flow work makes the same point in general terms: a queue forms wherever arrival outruns service capacity, and the cost of that queue is usually invisible on a status board.

So when an agreement lets AI speed up code generation, the question that belongs next to it is: which queue absorbs the extra arrivals, and can it? Review queue age, work-in-progress in the review column, and coordination time are the signals that tell you. If those grow after adoption, the team got faster at the wrong step.

Review rules need context, not a verdict on trust

The obvious place for the new load to land is review, and review is exactly where AI's output is easiest to misjudge.

Alami and Ernst interviewed 20 participants about AI-assisted code review (Alami & Ernst, 2025, CHASE). AI-assisted review was shaped by trust and by context. Model feedback could lower the emotional friction of review. A comment from a model does not carry the sting of a comment from a colleague. But it could also raise cognitive load, because the model produced more detail than the situation needed. The study ran in an artificial, anonymized review setting rather than a live team measuring flow, so hold it as insight into the mechanism, not a field result.

The mechanism is what matters for an agreement. A model comment reads as clean and confident whether or not it understood the surrounding code, the reason a pattern exists, or the constraint that is not visible in the diff. Clean phrasing is not evidence of correctness. If a reviewer treats a fluent suggestion as settled, the review step stops doing its job precisely when more output is flowing through it.

That is something an agreement can pin down without moralizing about trust. Say what AI may do, what a human owns, and what has to be shown:

• AI may suggest, flag, and draft.
• A human decides anything that changes behavior, security, or an interface.
• A claim that needs checking, like "this handles the edge case" or "this is equivalent," needs evidence attached, usually a test, before it counts as reviewed.

The point is to keep review a decision made with context, not a rubber stamp on well-worded text.

Security and agency belong in the same document

The moment an AI tool can read your repository or act on your systems, the working agreement is also a security boundary, and it is worth being concrete rather than aspirational.

Two references frame this well enough for a team to use. The NIST AI Risk Management Framework (NIST AI RMF) sets the governance frame: AI risk needs to be governed, mapped, measured, and managed rather than assumed away. It is guidance, not proof of any delivery outcome, and on its own it stays abstract. The OWASP Top 10 for LLM Applications 2025 (OWASP GenAI) makes it specific: prompt injection, disclosure of sensitive information, supply-chain weaknesses, data and model poisoning, and excessive agency are named as the failure modes to design against. Also practice guidance rather than empirical outcome data, but the failure modes are concrete enough to write rules against.

For a team, that turns into a short set of boundaries the agreement can state plainly. No secrets or credentials into a model. No customer or personal data outside approved, contractually covered tools. No autonomous agent with write access to code, tickets, or infrastructure without an explicit, bounded scope. No autonomous merge or deploy unless someone has approved that specific authority in advance. "Excessive agency" is not a hypothetical; it is what you get when an agent's real permissions were never discussed and turn out to exceed what anyone intended.

The number of security exceptions your team has to raise, a secret pasted where it should not have been, an agent that reached further than expected, is itself a delivery signal. Each one is unplanned work, and a rising count says the boundary is wrong.

One workflow, one queue, seven questions

An AI working agreement does not need to be long, and a company-wide document usually is not the right unit anyway. Write it for one workflow at a time, the one where AI is actually changing how work moves, and answer seven questions for that workflow.

1. Which workflow are we changing? Name the specific step: code review, ticket refinement, test writing, incident triage. Not "AI use" in general.
2. Which queue should shrink? State the delivery cost you expect to fall: time to first review, rework, a recurring blocked decision.
3. Which queue might grow? State where the extra output could pile up. Usually review or coordination, per the arrival-versus-capacity point above.
4. What may AI read? Which data, which parts of the repository, under which tool and account terms.
5. What may AI write or trigger? Suggestions only, or commits, comments, tickets, deployments, and within what bounded scope.
6. What must be visible on the work item or pull request? Disclosure of AI use, and the test or evidence that backs any claim a human has to rely on.
7. What signal will make us revise this? Name it in advance: review queue age, coordination time, rework rate, blocked decisions, security exceptions. Decide which number, watched over what period, means the agreement is wrong.

That last question is the one most teams skip, and it is the one that keeps the document honest. An agreement without a revision trigger is a statement of intent. An agreement tied to a signal is a control you can actually adjust.

The value is in naming it first

The document is not the point. A page of rules that nobody checks against real numbers is one more artifact.

The value is that writing it forces the team to say out loud what the new operating rules already are. Who can paste what, whose review still counts, what an agent is allowed to touch. And it forces the team to name, before the fact, the delivery signal that would prove those rules wrong. Do that, and you get to correct the flow deliberately.

Skip it, and the rules still exist. You just read them later, off the queue that grew while nobody was watching it.

Sources

• Alami, A., & Ernst, N. A. (2025). Human and machine: How software engineers perceive and engage with AI-assisted code reviews compared to their peers. In 2025 IEEE/ACM 18th International Conference on Cooperative and Human Aspects of Software Engineering (CHASE). IEEE. arxiv.org/abs/2501.02092
• National Institute of Standards and Technology. (2023). Artificial intelligence risk management framework (AI RMF 1.0). nist.gov/itl/ai-risk-management-framework
• OWASP. (2025). OWASP top 10 for LLM applications 2025. genai.owasp.org
• Reinertsen, D. G. (2009). The principles of product development flow: Second generation lean product development. Celeritas Publishing. search.worldcat.org/title/435994279
• Russo, D. (2024). Navigating the complexity of generative AI adoption in software engineering. ACM Transactions on Software Engineering and Methodology, 33(5), Article 135. doi.org/10.1145/3652154
• Song, F., Agarwal, A., & Wen, W. (2024). The impact of generative AI on collaborative open-source software development: Evidence from GitHub Copilot [Preprint]. arXiv. arxiv.org/abs/2410.02091
• Stray, V., Barbala, A., & Wivestad, V. T. (2025). Human-AI collaboration in software development: A mixed-methods study of developers' use of GitHub Copilot and ChatGPT. In Companion proceedings of the 33rd ACM International Conference on the Foundations of Software Engineering (FSE Companion '25). ACM. doi.org/10.1145/3696630.3730566