A Slack thread is not an AI coding policy.

The “AI coding policy” is in a shared drive. Fourteen pages. Approved tools are listed in appendix B. Secrets are “handled in accordance with Information Security Policy 7.3.” Nobody on the team can quote a sentence from it. Copilot has been on for eleven months. Cursor agents started showing up in March. Claude Code is on a few Team seats because a staff engineer asked in Slack and nobody said no.

I am not writing another explainer of what an AI code audit covers, or which SKU to buy first — those are already up. This is the policy half of that conversation: how to write rules engineers will still obey on a Thursday when the questionnaire is not in the room. A policy that cannot survive a standup is not a control. It is a PDF.

Why the current document gets ignored

Engineers do not ignore policy because they enjoy chaos. They ignore it because the document does not describe the job. It was written for a buyer, or for legal, or for a board slide. It says “human in the loop.” It does not say whether Cursor may open a worktree. It does not say who reviews auth. It does not say whether production dumps belong in a prompt. So the team invents a local version in Slack, and that version is the one that ships.

Two other failure modes are just as common. The first is length. A handbook chapter that takes twenty minutes to read will not be read before a merge. The second is theater: the words exist, the admin defaults do not. Copilot is “approved with senior review” and the org still has no CODEOWNERS on payments. Claude Code is “not for unattended use” and Team seats already start in auto mode. We wrote the auto mode checklist and the Cursor Origin checklist for those pins. A policy that does not name the pin is a wish.

A process sentence is still not evidence. If the next email is a security questionnaire, human-in-the-loop is not the packet. Write the policy anyway. You cannot inspect a tree against a rule you refused to write down.

What an AI coding policy actually is

An AI coding policy is a short, dated statement of which assistants may touch company work, what must never enter a model context, who reviews which paths before merge, and which admin defaults enforce those rules. It is written for the people who ship. Legal and security review it. They should not be the authors of the review bar.

It is not a 40-page acceptable-use policy. It is not a vendor one-pager from GitHub, Cursor, or Anthropic. It is not a scanner config. It is not a findings report. The commercial cousin — when you need to know whether Origin, Copilot admin, and Claude managed settings match the words — is AI coding platform governance. The snapshot of what already merged is a different product: a point-in-time AI code audit. Mixing “what we allow” with “what is in the repo” in one Slack thread is how both get skipped.

The one-page that can survive a standup

If the team cannot repeat the rules in five bullets, the policy will not be followed. These are the five that matter. Everything else is a link out.

1. Named tools, named bans. Copilot, Cursor, Claude Code — or not. Consumer chatbots and unpublished agents are not a gray area. If a tool is missing from the list, it is prohibited on company source, tickets, and customer data.
2. Secrets never enter a prompt. Keys, tokens, connection strings, .env values. Names of environment variables are fine. Values are an incident. Rotate and write it down.
3. Senior review on sensitive paths. Auth, tenancy, payments, PHI. “Any teammate thumbs-up” is not a bar on those paths. Familiarity is not inspection: if the author and the reviewer used the same assistant, you still need a senior reader who knows the system. That is the same point as what assistants actually leave in a production repo.
4. No production data in prompts. No dumps, no live customer records, no “just this CSV.” Synthetic or redacted fixtures only. If you cannot say that in one sentence, do not pretend the old data-handling policy covers chat.
5. PHI stays out unless a BAA and minimum-necessary design say otherwise. Healthcare product work is a different access model. Clinical systems and BAA-capable architecture live at Maxiom Labs. Do not copy a generic SaaS paragraph onto a PHI path.

Add a sixth line if you need it: client source stays in the client environment. Unapproved tools do not get a paste. “Review” that uploads the tree to a third-party model is not review. A named senior engineer owns exceptions. Exceptions are written, time-bounded, and attached to the change — not a reaction emoji.

That is a page. Date it. Put it in the handbook the same day. We are adding a free AI coding policy generator on Resources for that first Markdown draft — a Confluence starter, not a signed control. If that landing is not on the public site when you click it, start from the hub. Do not wait on a form to write the five rules. A draft you argue over this week beats a perfect generator next month.

Enforcement lives in the toolchain

Engineers follow what the tools enforce. They skim what the handbook requests. If Copilot is allowed only on application repos, say so in admin, not only in prose. If Claude Code may not run unattended on infra, pin disableAutoMode — the checklist is already public. If GitHub is the system of record, Origin does not become a second forge because a default flipped. Platform governance is that review: approved editor, approved host, who can enable a mirror, what the next questionnaire should actually say.

Pull request rules are the other half. CODEOWNERS on auth and payments. Required reviewers who are not the same people prompting the diff. A comment template that asks “did an assistant write this path, and who re-read it.” None of that replaces an independent findings trail. It is how the policy stops being a wish. Scanners stay in CI. They do not sign the policy, and they do not sign the questionnaire.

If you will keep merging assistant output after you write the page, the page will go stale without a review cadence. That is AI code oversight, not a reason to skip writing the page. If findings need to become controls in the product — logging, access, retention — that is compliance engineering, not another PDF.

Hire vs DIY

Write it internally this week when the team already knows which tools are in use, a staff engineer can name the sensitive paths, and nobody is asking you to prove the console matches the words. One page. Date. Handbook. Admin pins the same day. That is the whole job.

Buy platform governance when you cannot honestly say whether Origin, Copilot admin, or Claude auto mode matches the paragraph you are about to send a buyer. That gap is not a writing problem. It is a toolchain problem. Tool-specific search still has a landing for the code those tools already wrote: Copilot & Cursor code audit. Unattended Claude sessions are Claude Code governance.

Buy a snapshot when a date is on the calendar and the buyer wants findings, not a policy. The one-pager does not substitute for a named engineer, read-only access, and a severity-ranked report. If you are choosing among audit, monthly oversight, and governed MCP, use which SKU to buy first. Prompt-built products that never had an engineering process start with vibe coding governance, not a Copilot-on-a-mature-repo policy.

We have been shipping software since 2002. Assistants are now part of how software gets written. The failure is treating a handbook chapter as review, and treating review as a sentence you cannot attach to an email.

FAQ: AI coding policies engineers will follow

What belongs in an AI coding policy?

Approved tools, banned tools, secrets, production data in prompts, PHI, who reviews which paths, and which admin defaults enforce those rules. Date it. Keep it to a page. Link out for the rest.

Is a long acceptable-use policy enough?

No. Length is how the real rules get lost. Engineers will not consult appendix B before a merge. Write five bullets they can repeat. Put the legal language in a document they are not asked to ship against.

Does “human in the loop” count as the policy?

No. It is a process claim. It does not name tools, seniority, or what never enters a prompt. Buyers who have been through a real questionnaire want evidence. See why that sentence fails.

Can we generate the policy and call it done?

No. A generator — including the one we are putting on Resources — emits a draft. Someone still has to name the tools you actually use, pin the admin defaults, and argue over the review bar. A Markdown file in Confluence is not a control until the toolchain matches it.

Who should write it — legal, security, or engineering?

Engineering writes the review bar and the tool list. Security and legal review secrets, PHI, and customer-contract language. If legal writes the merge rules, you will get a document nobody can enforce. If engineering skips legal on PHI, you will get a document that creates liability.

Do we have to ban Copilot or Cursor?

No. You have to stop pretending an unwritten Slack approval is a policy, and stop sending last year’s paragraph to the next questionnaire while Team seats run unattended agents.

How is this different from an AI code audit?

The policy says what is allowed. An audit says what is already in the tree. You need the first to inspect against. You need the second when a date is on the calendar. They are not substitutes.

We handle PHI. Does the one-pager change?

The five bullets stay. The PHI bullet gets stricter, and the access model is not a generic SaaS review. Product work on clinical systems goes through Maxiom Labs. Say PHI on the scoping call so nobody pastes a template over a BAA.

Where do we put it so people actually see it?

The engineering handbook, the new-hire checklist, and the pull request template. Not only a shared drive. If a new contractor cannot find it in five minutes, it does not exist.

If you want the toolchain reviewed against the page — not a slide — start with AI coding platform governance. If the next question is what already merged, request an AI code audit or request a scoping call. Thirty minutes is enough to pick a scope, or to hear that we are not the fit.

I write from the seat of a working engineering company, not a tool vendor. More at antoniochagoury.com.