Commentary / May 30, 2026
Shared Principles for Human and AI Collaborators
Shared expectations help people and AI agents turn fast work into accountable, verifiable collaboration.
Shared expectations turn fast work into a working relationship.
For much of my career, I have stared at a code diff and wondered how the work got so far from the request. A small change becomes a framework. A bug fix becomes a refactor across unrelated files. Someone says the task is done because they finished typing, not because they proved the result.
Coding agents make that old problem move faster. They can also make it easier to see.
I saw this recently in the workspace we use to develop and review articles. I had asked my AI to review drafts for weak reasoning, unsupported claims, and places where the argument needed more evidence. The skill could identify abstract or underdeveloped passages, but it often treated the diagnosis as the finished work. It might recommend “add an example” without checking whether the example needed to establish a particular link in the argument or whether it came from my actual experience.
After our copywriter reviewed five articles, I clarified the principle: criticism should be actionable and tied to the evidence the passage needs. When a firsthand example would strengthen the article, the review should identify the decision, signal, missing context, consequence, or repair the example must contain rather than merely requesting an anecdote.
On the next review, my AI’s prompts changed. Instead of asking generally for more detail, it asked for specific evidence: a low-stakes stability test, a work decision affected by missing context, and a personal incident traced from signal through consequence and recovery. The skill was not simply producing more comments. It was giving us a clearer way to verify that a revision would actually do the work the article required.
Expectations need a home
Teams have always carried operating principles. Some are written down. Others are learned during code review, incident response, or an uncomfortable conversation after a bad release. They help people make compatible decisions without asking for permission at every turn.
Agents need the same clarity. A file such as CLAUDE.md or AGENTS.md is not a magic prompt. It is a place to make working expectations visible: ask when a decision is ambiguous, keep a change scoped, verify before declaring success, and explain meaningful risk before taking an irreversible action.
The file format is not the point. The shared expectation is.
Adapt, do not copy
Other builders have helped popularize small, explicit instruction artifacts for coding agents.12 Their value is not that every team should copy the same rules. A rule only helps when the team understands the problem it is meant to prevent.
Before adopting a principle, ask:
- What failure are we trying to avoid?
- What local constraint does this rule need to respect?
- What evidence would tell us that it helped?
Those questions keep a team from replacing one kind of cargo cult with another. They also give an agent a useful job: compare a proposed rule with the project’s existing constraints and flag a conflict before the change becomes habit.
Treat principles as hypotheses
Written principles should evolve. A useful one makes a recurring expectation easier to follow and easier to review. A weak one adds ceremony, duplicates another rule, or creates a new ambiguity.
That is why the next question matters: do these principles reduce friction, or do they merely make the process feel more orderly?
We have begun examining our own collaboration records for recurring patterns: assumptions that should have been surfaced, scope that spread beyond the request, verification that never happened, and instructions that were too vague to guide the next task. The work is early. The goal is not to produce a score that replaces judgment. It is to learn which expectations need to be clearer and which rules are doing real work.
Shared principles create better collaborators when they remain connected to actual behavior. The evidence is in the next diff, the next review, and the next time a team avoids having the same preventable conversation.