Six months in, everyone on my team was using AI tools — but nobody was using them the same way. One engineer had custom Cursor rules. Another was copy-pasting raw code into ChatGPT. Another wasn’t using AI at all because “it makes stuff up.”

We had inconsistent output quality, inconsistent risk awareness, and no shared vocabulary for AI-generated code in review. I decided to formalize it.

Table of Contents

Why You Need a Standard

The argument against: AI usage is personal workflow. True for individual productivity. Stops being true when AI-generated code lands in PRs without being flagged, when different engineers get different results from the same codebase, or when a production issue traces back to AI output that wasn’t reviewed critically.

The goal isn’t to control how people work. It’s to make AI usage visible, consistent, and reviewable.

AGENTS.md: Project-Level Context

AGENTS.md lives at the repo root. AI coding agents (Claude Code, Codex, Cursor in agent mode) pick it up automatically — it’s context the AI wouldn’t otherwise have.

# AGENTS.md

## About This Service
Order processing service. Go 1.22. gRPC. Postgres.

## Architecture Notes
- All DB writes through the repository layer — never raw SQL in handlers
- Event schemas defined in /schemas — import from there, never redefine inline
- The ingestion queue is at-least-once; idempotency is the consumer's responsibility

## What Not to Generate
- Do not generate database migrations. Create a stub and flag for human review.
- Do not add new dependencies without noting them explicitly.

## Code Style
- No bare except clauses. Catch specific exceptions.
- Type hints required on all public functions.

The most important section: “What Not to Generate.” Explicit prohibitions are more reliable than hoping the AI infers constraints.

.cursorrules: Editor Guardrails

.cursorrules is evaluated before every Cursor generation — a persistent system prompt for your codebase. Keep it short; long rulesets get ignored.

YANTUoLEENuWVSSAETUaYRSRrS::Ee::GAwFesSoonsarleeyklrrioatsnwtogeaegeixDaxniBipsnlatmsiiitcpngirgretoaxldptpyuaie.ctocttntLieseior.dsnntsAvb.daaadlscAuskddeuedesmnp,pdtetynnispdooeeetnrnsvhcfiiiuacnentetsc.stt.wioiopFtnlhoaoofguuttrbpeupussetpirsonm.neisssIessn.iclolonug.diecSwoaanslesluoemwdpgteeixoccneasps.teiopnesr.file.

Prompt Library

Keep reusable prompts in docs/ai-prompts/. Three worth standardizing:

Code review: “Review this diff for correctness, edge cases, and security. Skip style comments. Flag anything uncertain. [PASTE DIFF]”

Refactoring: “Refactor the following to [GOAL]. Preserve the existing public interface. Note any places where behavior might unintentionally change. [PASTE CODE]”

Debug: “Error: [ERROR + STACK TRACE]. Context: [DESCRIPTION]. Recent changes: [DEPLOYMENTS]. Walk me through your hypothesis.”

For more on effective AI prompts, see prompt engineering for developers.

Review Checklist

Add to your PR template:

## AI-Assisted Code (if applicable)

- [ ] AI-generated sections identified in description or inline comments
- [ ] Tests assert against expected values, not function outputs
- [ ] No AI-generated database migrations
- [ ] Business logic assumptions verified against actual requirements

The boxes are advisory — they don’t block merge. But an unchecked box that a reviewer questions is the standard working. See AI PR review bots comparison for more on review tooling.

Limitations and Getting Buy-In

The honest limitations: Compliance is voluntary — no tooling detects AI-generated code automatically. The rules get stale when architecture changes. Not every repo has a maintainer who keeps these files current. Prompt library adoption is uneven.

None of these are reasons not to have a standard. They’re reasons to treat it as a living document.

Getting buy-in: The standard failed the first time I introduced it as a policy document. The second time, I introduced it as a starting point and asked for input. Engineers added rules they actually wanted and removed ones that felt prescriptive without value.

The standard people help write is the standard people follow.

Run a short session where each engineer shares their current AI workflow. Use that as the raw material for the first version. The rules will reflect real experience, not theoretical best practices.

Start with AGENTS.md in your most active repo. Add .cursorrules. Build the prompt library from prompts people already use. Add the review checklist. Iterate.

The goal isn’t to constrain AI usage. It’s to make sure the team is making consistent bets about when to trust it.