The 10-Line AI Working Agreement Your Team Never Wrote
Most organizations have an AI usage policy by now. Almost no team has an AI working agreement.
The difference matters. The policy is written by legal and answers "what are we allowed to do." The agreement is written by the team and answers "how do we work," which is the question that actually determines whether the tool helps. Policies get signed. Agreements get argued about, which is the point: the argument is the adoption work.
Here is a ten-line version that fits on one page. Steal it, cut lines, add your own, and expect two of them to start a fight. That fight is the deliverable.
1. We Disclose AI Assistance
One checkbox on the PR, no interrogation, no shame. Disclosure is for patterns, not blame.
1. AI assistance is disclosed in the PR. One checkbox. No interrogation.
2. "Done" Includes Verification
No generated code merges on local test runs. The checks pass in CI, where they can't be persuaded.
2. "Done" means CI green, not "worked on my machine."
3. Generated Code Gets a Real Review
By a human who could have written it. Rubber stamps are the failure mode this line exists to prevent.
3. AI-authored code is reviewed like any other code, by someone who could have written it.
4. The Data Line
No customer data, secrets, or regulated content into any tool. The allowlist lives in one URL everyone can find.
4. No customer data, secrets, or regulated content into AI tools. Allowlist: <one link>.
5. Dependencies Get the Same Door
Agent-introduced packages pass the same registry checks as human-introduced ones. The door does not care who is carrying the box.
5. Agent-introduced dependencies pass the same checks as human-introduced ones.
6. Almost-Right Gets Fixed at the Source
When output is nearly correct, we fix the prompt or the spec, not silently hand-patch the diff and move on. This is the line people fight about, because hand-patching feels faster and isn't. đź’¬
6. Almost-right output gets fixed at the prompt or spec, not hand-patched in the diff.
7. Somebody Owns the Agent Queue
One person per sprint, rotating: approvals, escalations, quota. Unowned queues become nobody's job, which means everybody's interruption.
7. One rotating owner per sprint for agent approvals and escalations.
8. The Customer-Felt Line
Anything a customer feels is never generated and shipped unreviewed: comms, billing, security paths. The second line people fight about, because it sounds like distrust of the tools. It is a statement about blast radius, not belief.
8. Anything customers feel (comms, billing, security paths) ships human-reviewed. Always.
9. We Count Rework, Not Just Velocity
Time spent fixing almost-right counts against the gain. A team that only tracks speed will look productive while going backwards.
9. We track rework alongside velocity. Fixing almost-right is not free.
10. This Agreement Is Re-Read Quarterly
Lines that stopped matching reality get changed, not ignored. An agreement nobody revisits is a policy with worse formatting.
10. Re-read quarterly. Lines that stopped being true get changed.
Print it, argue about lines 6 and 8, and change whatever loses the argument. The version your team writes will be better than this one, because it will be yours, and because the meeting where you fight about line 8 is the first honest conversation about AI risk your team will have had all year.
Which line is missing from yours?
References
- The checks that don't run unless someone makes them gates: 10 SDLC Checks AI Will Skip Unless You Make Them a Gate
Top comments (14)
I'd make line 6 require a learning loop rather than prohibit hand-patching. During an incident, a small reviewed fix may restore service faster and more safely than regenerating the change. Keep the reproduction and regression test, then update the spec or prompt before closing the follow-up. Otherwise the agreement can turn a useful rule about preventing recurrence into a reason to delay recovery.
Once you start this, line 10 will tell you what seems to be appearing again and again, and learning sets in. Here is the reality, learning seems common sense. I have tried for 20 years to make learning as part of the loop. It works for a team of 1 or a small team, it just does not for a larger team. Why? I didn’t get a consensus but came to the conclusion that “group thinking” gets in the way. I reconciled to “let people do a bunch of retro” and after 3rd time, point out what you saw 2 quarters ago as “do you guys see it’s appearing over and over” and voila. I know, I could have saved so much frustration on day 1, but I had to wait patiently
The gap you describe sounds like agreeing that a pattern exists without agreeing to change the work. Would a smaller experiment help: pick one recurring failure, give one team ownership of one change, and check the next comparable cases? That gives the next retro something specific to accept, revise or drop. It also distinguishes 'we discussed this again' from 'we tried a prevention measure and it didn't work.'
The themes I noticed are - lack of owner mindset in engineers, and this means, many are ready to complain but not ready to take the next step to remove the issues. This takes years to build in a team and this is where a good leader will intentionally leave vacuum for engineers to step up. Next is, many engineers go through rituals of retro but discuss "the problem of the day or week" instead of coming prepared. I recall one engineer was not happy with some sprint planning a week ago, and an entire quarter's retro, I heard him talk about that sprint planning for 10mins. So, I asked him - read the current sprint planning doc and tell me what you would change next week with his edits out for review. Its been 9 months, I never saw him complain about that again.
Yes, a small experiment is all we need - in our retros, I ask my team
Line 6 is the one I would keep front and center. When output is almost right, fixing the prompt or the spec saves the next person the same patch. One concrete habit that helps: keep a short note with the failed prompt, the fix, and the test that caught it, so the team can reuse the fix instead of rediscovering it.
Yes, fantastic idea! I love it! Humans remember mistakes and often get reminded friendly or unfriendly way. Persisting that is the best way for Ai agents to know to not do that again. Love it
Line 3 hits different when the team is one person lol. Who reviews the AI code 'by someone who could have written it' when the only someone shipped it at 1am half asleep? I'm curious if you'd tweak any of these for solo builders, because half my agreement would just be me arguing with myself in a PR comment
Yes, solo builder means - you have enormous freedom and also responsibility :) I hear you. I work solo on private projects. Here is what I usually do, I usually do a PR review with a LLM that's slightly more capable than the one wrote it. For critical areas, I would even use a higher spec LLM from a different vendor to review. For private projects, I use non-US (often Chinese LLMs) to write code. For critical areas, I do use a mix of Chinese higher spec LLMs and US vendors. Its all about trade off between cost of tokens and how much quality I care about. Nearly all my solo projects are OSS, sitting in GitHub with 1 or 2 stars :) So, that's what I would do. I have few popular plugins like superpowers and others that do specific PR and find issues. I use a combination of these. I rely more on the tests and specially field tests to catch issues. At work, all our code goes through formal 2 people review, preceded by a code review agent review
Line 8 holds up best when the team writes down which folders count as customer felt, like the billing module and the email templates, and makes a reviewer from that list required on any change that touches them. Then nobody has to judge in the moment whether a generated change is risky. The argument about line 8 happens once, over a list of paths, instead of on every pull request.
The difference you draw between a policy and a working agreement is the useful part. A policy is written for compliance, while an agreement is written for the people who have to decide on a Tuesday afternoon whether a change is ready.
Two lines stood out to me. Done means CI green is simple, but it removes the most common argument in review. Fixing almost right output at the spec rather than in the diff is the harder habit, and it is the one that stops the same mistake from returning next week.
PromptAlo's suggestion to list the customer felt folders and require a named reviewer there makes the agreement concrete. Odinaka's quarterly reread also matters, because a team that adds agents to new parts of the codebase quietly changes what the original ten lines covered.
Counting rework is the line most teams will resist and most need.
The quarterly re-read is the real fix, stale rules are worse than none
Exactly, it’s not 10 commandments or any Biblical mandates :) Rules can change, you can have fewer or more, it all depends on what the team needs. 10 seemed like a good number to start with, 3 seemed too few, and 50 seemed too high :)
the re-read is the whole thing. rules go stale otherwise.
Line 5 is the one I learned the hard way. I let an agent add an npm package I never looked at and it dragged in a pile of dependencies I'd never have approved. Now it gets the same check whether I typed the install or the agent did.