SRE O11Y AI Usage Agreement
Author: wbollock
Now that we are all powered agentically and have had a few years of using these tools, its worthwhile to have a discussion about using AI collaboratively within our team. This document is meant to be a shared agreement within our team on how we'd like to use AI in work we produce and that is shared internally or presented externally. This ranges from troubleshooting Gists to architecture documents to pull requests.
Our team has a good history of working well asynchronously, such as encouraging conventional commits and writing t-o-t proposals. Our written culture is one of my favorite parts of this team and helps us collaborate together across time zones. It also strengthens our decision making, forcing us to articulate our thoughts fully and discredit any inaccurate assumptions.
AI tooling leads to new challenges in that process. While I am nearly an AI maximalist (TODO, wording), I don't believe AI has a creative role in our collaborative writing process. I strongly believe in retaining a human touch for proposals and design documents. AI still has a place in some text creation and there can be a blurred line with human operators deciding how much or how little AI they want to involve in their work. Research, background knowledge, sanity checks, and editing (within reason) all are still fine AI use cases supplementary to producing a final written product.
To that end I've created a table of common scenarios and how much AI usage we should allow within our team for key rituals. Just to state the obvious, all individuals are still responsible for any artifact they create, regardless of AI involvement. You own any code or text you submit regardless of how it was created.
| Scenario | Maximum AI Usage Allowed | Notes |
|---|---|---|
| Pull requests (code) | Full | Code comments are fine to have AI written too |
| Troubleshooting Gist | Full | |
| Research | Full | Prompting for more ideas you might not have considered is a great AI use case. Don't forget to "trust but verify" AI claims. |
| READMEs in repos | Some | No one wants to read an entire AI written README, but some sections are fine to generate like feature flags or available metrics. |
| Editing your writing | Some | We should not have AI write an entire draft, then have a human only edit some sections. The reverse method can work well though. |
| Standup notes | Some | Have AI make a list of tickets or PRs you've done, but project leads should use their words for a project status update. |
| Jira tickets | Some | Engineers famously despise Jira tickets but managers need them. An AI created Jira ticket is certainly better than nothing and sometimes can be a good ticket. |
| Git commits and extended commit descriptions | Some | It largely depends on the codebase. As an example, if it is throwaway o11y-cli code, AI commit messages could be fine. For critical-path host_sd changes, we'll want human made commit messages. |
| Performance Review | Not Much | Have AI suggest goals for you based on your work, but not write your reflection. |
| Pull Requests (descriptions; commit messages) | Not Much | The OpenTelemetry repos have a requirement all PR descriptions are created by humans. We should at least be able to describe our changes to each other. |
| Architecture document, t-o-t proposal | None | |
| TODO convert to excalidraw. make "some" more descriptive |
Simply put, LLMs don't have good taste. Our collaborative writing system is essential for the o11y team to develop solutions we want to support and believe will represent a good experience for our customers. Authors should be able to articulate their position and show they put real thought into what they are proposing. Even if our writing is messy there is emotion behind it that is much more engaging to read compared to a similar AI piece.
It is a strange new world and I am totally okay with ~50 human written words describing a PR while the +/- 500 LOC diff is all AI generated. "AI-generated code feels like progress and efficiency, while AI-generated articles and posts feel low-effort." (footnote 1).
Writing something by hand also indicates you put in time and your "human attention tokens" to solving a problem. This is the scarcest resource we have and is a sign to your teammates you find the subject important. Reviewers of these design documents should similarly give back their own "human effort" (footnote 3), reading and reviewing with their "meat proxy" (footnote 2) brains no matter how imperfect they might be.
We are a collection of augmented human beings powered by AI tokens, and finding ways to enjoy working together when we could just prompt in silence is critical going forward.
(footnote 1) https://www.0xsid.com/blog/aidr
(footnote 3) https://tombedor.dev/human-attention-and-human-effort/
(footnote 2) https://gruhn.me/blog/2026-08-03/
https://alexhwoods.com/dont-let-ai-write-for-you/
Thats totally okay. We're all experimenting with the limits of these tools and there is a learning curve to deciding what to prompt, how, and when. I've certainly made errors in judgement offloading some thinking to AI and making others read text I didn't create.
In small bursts, AI written snippets are super helpful and can save someone else a prompt. During a busy on-call, offloading an alert investigation to AI is a great time saver and can help us look into low priority issues we might otherwise neglect in favor of looking at higher priority alerts. Using your own experience to dilute and condense an AI-led investigation into actionable steps is the new paradigm we should all aim for.
Probably. If you are submitting AI generated text under your own username, it is best practice to add an AI generated disclaimer to the text block. This can be added via a simple edit to your global AGENTS.md or individual skills. Soon Claude will also add invisible watermarks to AI generated text.
It won't, and maybe AI writing will get so good that we won't be able to tell with the reliable sniff tests we have today. Once em-dashes and sycophancy are relics of the past there could be increased suspicion that no human thought went into text we send to each other. We have to truly believe in this human-led method of remote collaboration for the system to work.
Recently SimpleEnglish has been a marked improvement to my AI's output. It at least reduces "AI fatigue" and can be helpful for your own chat sessions or when creating acceptable sources of AI output.