Cursor rules as governance for AI-assisted development

Problem

When a team of 10 people vibe-codes, architectural standards drift. AI doesn't know the project's conventions — each developer gets their own version of "the right way." Explaining standards in a quarterly meeting doesn't work: a rule that isn't in the tool isn't followed.

Methodology

Encode the standard directly in the toolchain the team works with every day — not in a document nobody opens.

1. 1. Rules as a versioned artifact: .mdc files in .cursor/rules — context-bound, repository-scoped architectural instructions in git.
2. 2. Modular organization: subdirectories by framework/domain (framework/python/ etc.) — a rule applies where it's relevant.
3. 3. Focus and actionability: each rule ≤ ~500 lines, with a goal, examples, and anti-patterns — otherwise the AI ignores it.
4. 4. Application metadata: globs and conditional flags determine when a rule is active. Without a glob, a rule applies everywhere and creates noise.
5. 5. Effect: a new contributor inherits the same ruleset; style and architectural consistency are enforced by the tool, not code-review heroics.

A real file from the repo — rules/architecture-rules.mdc (github.com/dobryakov/cursor-rules):

# Architecture and Integrations

* Dual write is forbidden. Writing to the DB and publishing an event in the same
  handler without a transaction is potential data loss. Pattern: outbox write in
  the same transaction, relay as a separate process.
* Cross-service synchronous HTTP calls are allowed no deeper than one level.
  Chains A→B→C — only via queue with explicit DLQ and timeouts.
* API contracts don't change without a version. Changing field semantics or
  deleting a field = new version; the old version lives at least 90 days with
  a deprecated marker.

Three rules — one file — one topic. Each names a concrete anti-pattern and explicitly forbids it: the agent doesn't "check related components" abstractly — it knows dual write is forbidden and why. Next to it in the repo are testing-rules.mdc, infrastructure-rules.mdc, observability-rules.mdc — each covering its own zone. A rule without a glob is noise everywhere; a rule with a glob is silent until needed.

Artifact

github.com/dobryakov/cursor-rules (RU + EN versions, ★2). A template framework teams customize for their project.

For whom and why

Risk: with mass AI coding and no rules in the repo, every developer inherits their own version of the architecture; divergence is silent until the first major refactor.

Solution: standards are encoded in the toolchain — not in a senior engineer's head, not in a document nobody opens.

Metric: a new team member gets the same guardrails from the first commit — visible in git history, not felt by intuition.

Directly tied to enterprise training on "how to vibe-code correctly": governance is introduced not through a lecture but through a toolchain guardrail. For CTO, this is the answer to the main fear of mass vibe-coding — "how do we keep architectural control."