Most teams already use AI coding tools. Fewer have agreed how. The result is a codebase where every developer follows a private set of habits, and nobody knows which changes were checked carefully and which were accepted on trust.
Guidelines fix that, as long as they are short enough to remember. Here are seven that hold up.
Rules for the people
1. The person who opens the pull request owns it. Whether they typed it, accepted a suggestion or ran an agent, they answer for every line. "The AI wrote it" is never an explanation for a bug.
2. If you cannot explain it, do not submit it. A line you cannot explain is a line you are trusting, not checking. This one rule prevents most of the damage.
3. Say when AI did a substantial part. A short note in the pull request, such as "the agent wrote the migration; I rewrote the validation", tells the reviewer where to look. It is not a confession. It is a map.
4. Keep changes small. AI makes it easy to produce a 1,500-line pull request in an afternoon, and nobody can review that properly. Agree a size limit and split anything larger.
5. A changed test needs a reason. If a change edits or deletes an existing assertion, the pull request must say which decision allows it. Generated changes rewrite inconvenient tests more often than you would think.
6. Review by risk, not by size. Copy and styling get one reviewer. Anything that writes data, checks input, controls access or touches shared code gets two, plus a run against realistic data.
7. Some things never go into an AI tool. Secrets, customer data and any code your contracts restrict. Use fake data with the same shape instead.
What goes in the rules file
Half the people searching for AI coding guidelines mean something else: the instructions file their agent reads, such as AGENTS.md, CLAUDE.md, .github/copilot-instructions.md or a Cursor rules file. Once the team has agreed its rules, put the parts an agent can follow there:
- how to run the tests, and the instruction to run them before saying a task is done
- the project's own patterns for errors, logging and naming, so it does not invent a second way
- what not to touch without asking: migrations, CI configuration, authentication, generated files
- "do not edit or delete existing tests unless asked"
- "ask rather than guess when the request is unclear"
Keep it short and specific. A rules file is read on every task, so every vague line costs attention and helps nobody. Review changes to it like code, because it changes how every future change gets written.
Agree them together
Guidelines handed down get ignored. Spend half an hour agreeing them as a team, write them down, and revisit them in a month, because the tools will have changed by then.
The free AI acceptable use policy template turns these rules into a two-page policy you can fill in. The AI code review checklist gives reviewers the steps behind rules 2, 5 and 6.