AI usage guidelines people actually follow

Tuesday’s questions

Many organizations now have an AI policy. It lives in a governance document and covers data security, licenses, and approved tools. It’s important, and it’s completely irrelevant to how your team actually works on a Tuesday.

Because the policy doesn’t answer the questions that decide code quality:

When do we use AI, and when don’t we? What does “review-ready” mean when the code is generated? How do we adopt new patterns the AI suggests?

Those are the questions a guideline has to answer. And as with all standards, the same principle applies as in Standards that actually stick (in Norwegian): it only gains value when it’s used.

Policy vs. practice

Policy is owned by the organization, is about risk, and is read once. Practice is owned by the team, is about quality, and is used every day.

The mistake many make is writing the practice in policy language. Ten pages. Formal phrasing. Stored where no one works. Then the same thing happens as with every standard no one uses: nothing.

One page. In the repo. Owned by the team.

An AI guideline that lives looks roughly like this, and it fits in one file, docs/ai-usage.md:

Understand before you merge

You are accountable for all code you open a PR for – regardless of who or what wrote it. If you can’t explain it, it isn’t ready.

Explain complex choices in the PR

Are central parts generated? Say so. Did you approve a choice you wouldn’t have made yourself? Justify it. “The AI suggested it” is not a justification.

New patterns are adopted together

AI will readily suggest patterns we don’t use. Some are better than ours. But they don’t get introduced in a single PR. They’re raised with the team, and end up as a TDR if we adopt them.

Use the team’s context

The context file in the repo – AGENTS.md, or your tool-specific variant – gives the assistant our conventions. Use it. Answers without context are answers for a different system.

Share what works

Good prompts for recurring tasks belong in docs/prompts/. A good prompt is the team’s property, not your secret.

That’s all. Five points.

Why so short?

Because length is inversely proportional to adherence. A one-page guideline can be read during onboarding, linked in PR comments, and quoted in review. A ten-page one can do none of this.

And because the short format forces the most important question: what are our principles, really? If you can’t get them onto one page, you don’t have them yet.

The most useful one-pager I have had on a team wasn’t even called an AI guideline. It was called “How to pass code review on the first try”: ten points, made of what kept coming back in review after review on most of the team’s AI-written PRs. The points weren’t decided. They were observed.

The guideline takes hold in the moments

The document is only the starting point. The guideline becomes culture through the small moments:

• when a senior says “good PR – and thanks for explaining the generated choice”
• when the review comment links to the guideline instead of pointing a finger
• when someone breaks it for good reason, and it becomes a discussion, not a reprimand
• when the retrospective asks: “do the points still work, or should we adjust?”

It’s the same mechanism as all culture: it’s built through practice, not decree.

What does NOT belong in the guideline

Just as important as the content is what you leave out:

• tool choices (they change too fast, they belong in TDRs)
• security and data handling (they belong in the organization’s policy)
• detailed prompt rules (they belong in the prompt library)

The guideline should answer one question: how do we use AI with quality, here? Everything else is noise that weakens it.

The unexamined practice

Your team uses AI every day, so the question isn’t whether you have a practice – you already do. The question is whether it’s deliberate.

A one-page guideline makes the implicit practice explicit, and only then can it be discussed, improved, and owned by someone other than whoever wrote it.