A policy people will actually follow

Two failure modes, both common

Ban it. People use it anyway, on personal accounts, without telling anybody, and now nothing is reviewed and nobody knows what left the building. A ban converts a manageable risk into an invisible one.

Say nothing. Everybody does something different, sensitive code goes to whatever service somebody signed up for, and the first time anyone thinks about it is during a customer’s security questionnaire.

The useful thing is one page, written once, that a person under deadline pressure can follow. Length is the enemy: a three-page policy is a policy nobody has read.

The page

# Using AI coding tools here

## Approved tools
<name>, on the company account. <name>, self-hosted.
Anything else: ask in #eng-tools first. One message, not a review board.

## Never pasted into an external service
- Customer data of any kind, including "anonymised" samples
- Credentials, tokens, private keys, connection strings
- Code from `payments/` or `identity/`
- Anything a client contract marks confidential (list: docs/contracts.md)
For those, use the local model. Setup: docs/local-model.md

## Ownership
You own every line you submit, whatever produced it.
If you cannot explain a line in review, do not submit it.
"The model wrote that part" is not a defence.

## Review standard, by risk
- Money, auth, permissions, deletion, personal data, external writes:
  every line understood by the reviewer. No deadline override.
- Everything else: normal review.

## Always
- Read the whole diff before opening a pull request.
- Verify any new dependency exists and check its publisher. (2 minutes)
- Say in the description if a change removes a check, widens an exception,
  skips a test or loosens a type — and why.

## Never
- Let an agent run with production credentials in the environment.
- Auto-merge on a bot approval.
- Use these numbers to assess a person: lines, commits, PRs,
  acceptance rate, percentage generated.

Why each section is there

Approved tools exists so people do not have to guess, and so the answer is one message rather than a procurement process. A slow approval path guarantees shadow usage, and shadow usage is the outcome you were trying to avoid.

The data rules are the part with legal consequences and they have to be specific. “Do not share confidential information” is not actionable; a directory list is. Note that the rule points at a permitted alternative, because a prohibition with no path is a prohibition people route around at 6pm on a Thursday.

Ownership is the cultural core and it is one sentence. Everything else in this course depends on it holding.

Risk-tiered review is what makes the policy survivable. A blanket “review every line” is abandoned within a month because it is not affordable. A rule that applies full scrutiny to the ten per cent where it matters is followed for years, and that is the difference between a policy and a poster.

The never-measure list protects the team from a well-meaning manager, and it belongs in writing rather than in somebody’s head, because the pressure to produce an adoption metric arrives from outside engineering and arrives suddenly.

Disclosure, which is unsettled

Should a pull request state that a change was generated? Teams disagree, and both positions are defensible.

For: it lets a reviewer calibrate. A change the author typed line by line and a change they skimmed warrant different scrutiny, and there is nothing in the diff that distinguishes them.

Against: it becomes a status marker, it is unenforceable, it grows meaningless as assistance blends into ordinary editing, and it quietly undercuts the ownership rule by implying the author is less responsible for those lines.

A reasonable middle, which several teams have landed on: do not label provenance, and instead ask the author to state their confidence. “I have run this against a copy of production and I understand every line” versus “first pass, please read the retry logic carefully”. That is more useful to a reviewer than provenance, it is honest, and it is fully compatible with owning the diff.

Whatever you choose, decide it explicitly and write it down. The worst outcome is an unstated norm that some people follow and others do not, because then a disclosure reads as a confession and its absence reads as a claim.

Review it on a date

Put a date on the page (six months out) and a name. The tools, their capabilities, their data-handling terms and their prices all move faster than any other technology your team depends on, and a policy written against last year’s landscape will be wrong in a way nobody notices until it matters.

The review is twenty minutes. Read the page, ask whether each rule is still the right one, ask whether anybody has been breaking one because it did not fit, and change it. A rule that people break silently is a rule that has already failed; the only question is whether you find out by revising the page or by reading an incident report.