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 (9)
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
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
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
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.