Most eng teams that have tried to write an AI coding standard end up with one of two things: nothing written down at all, or a document so vague it does not change anyone's behavior.
"Use AI responsibly." "Review AI-generated code carefully." "Use good judgment." These are not standards. They are things nobody would disagree with, which is exactly why they do not help.
A standard the team can actually stick with needs to be more specific, and shorter than you'd expect.
Start with what, not with rules
The most useful AI coding standards start by naming the specific tasks the team uses AI for, not by listing rules. "We use Claude Code by default for: PR description drafts, flaky test triage, first-pass code review comments, and turning a scoped ticket into a draft PR." That single sentence does more work than a page of guidelines, because it tells every engineer exactly where to start.
Tasks outside that list are not forbidden. They are just not the default yet, which keeps the standard from trying to cover every possible use case on day one.
Define what "good" looks like for AI-assisted work
This is the part most standards skip. It is not enough to say AI-assisted PRs need review. Engineers need to know what a good one looks like before they submit it, not find out from review comments after the fact.
A useful version is concrete: the diff is scoped to one clear change, the PR description explains what changed and why in the author's own words, anything the reviewer should double-check is flagged, and the change went through the same CI and review gates as any other PR. That is specific enough to actually guide someone.
Name where human review is non-negotiable
Not every task carries the same risk. A standard should say plainly where a human always checks the work before it ships, regardless of how confident the tool seemed: schema changes, anything touching production config, anything customer-facing, security-relevant code. Naming these explicitly removes the ambiguity that leads to someone assuming "it's probably fine" on the one change where it mattered most.
Decide on disclosure, once, as a team
Some teams want AI involvement flagged in every PR. Some do not care as long as the output meets the same bar as any other code. Either is defensible. What is not defensible is every engineer deciding individually, because that produces the inconsistency that makes review harder and erodes trust in what "AI-assisted" even means on that team.
Pick one answer, write it down, move on.
Keep it short enough to actually be followed
A standard that takes fifteen minutes to read will not get read a second time. The versions that stick are closer to half a page: the default use cases, what good output looks like, where review is non-negotiable, and the disclosure policy. Anything longer starts competing with actual work for attention, and loses.
Assign an owner
A standard with no owner drifts out of date the first time the team's tools change. Someone specific should be responsible for updating it and for noticing when it is not being followed, the same way someone owns the team's testing conventions or code style guide.
What good looks like
A good AI coding standard fits on one page, names specific default use cases instead of general principles, defines what good output looks like, and has an owner who keeps it current. If your team's current standard is a Slack message from six months ago or nothing at all, that gap is worth closing before adoption drifts further.
If you want help writing a standard your team will actually follow, book a call. If I'm not the right person, I'll say so.