Cursor rules как governance: как держать планку качества, когда команда вайб-кодит
Как кодировать архитектурные стандарты прямо в toolchain, с которым команда работает каждый день — а не в документ, который никто не открывает.
Проблема
Когда в команде вайб-кодят 10 человек, архитектурные стандарты дрейфуют. AI не знает конвенций проекта — каждый разработчик получает свой вариант «как правильно». Объяснять стандарты на встрече раз в квартал не работает: правило, которого нет в инструменте, не соблюдается.
Методика
Кодировать стандарт прямо в toolchain, с которым команда работает каждый день, а не в документ, который никто не открывает.
-
1. Правила как версионируемый артефакт.
.mdc-файлы в.cursor/rules— контекстная, привязанная к репозиторию архитектурная инструкция в git. -
2. Модульная организация. Поддиректории по
фреймворку/домену (
framework/python/и т.д.) — правило применяется там, где релевантно. - 3. Фокус и actionability. Каждое правило ≤ ~500 строк, с целью, примерами и анти-паттернами — иначе AI его игнорирует.
- 4. Метаданные применения. Globs и условные флаги определяют, когда правило активно. Без глоба правило применяется везде и шумит.
- 5. Эффект. Новый контрибьютор наследует тот же ruleset; consistency стиля и архитектурных решений обеспечивается инструментом, не code-review-героизмом.
Реальный файл из репо —
ru/rules/architecture-rules.mdc
(github.com/dobryakov/cursor-rules):
# Архитектура и интеграции
* Dual write запрещён. Запись в БД и публикация события в одном хендлере
без транзакции — это потенциальная потеря данных. Паттерн: outbox-запись
в той же транзакции, relay — отдельный процесс.
* Межсервисный синхронный HTTP-вызов допустим не глубже одного уровня.
Цепочки A→B→C — только через очередь с явным DLQ и таймаутами.
* API-контракт не меняется без версии. Изменение семантики поля или удаление
= новая версия; старая версия живёт минимум 90 дней с deprecated-маркером.
Три правила — один файл — одна тема. Каждое называет конкретный анти-паттерн
и запрещает его явно: агент не «проверяет связанные компоненты» абстрактно —
он знает, что dual write запрещён и почему. В репо рядом лежат
testing-rules.mdc,
infrastructure-rules.mdc,
observability-rules.mdc —
каждый про свою зону. Правило без glob шумит везде, правило с glob молчит,
пока не нужно.
Артефакт
github.com/dobryakov/cursor-rules (RU + EN версии, 2★). Шаблонный фреймворк, который команда кастомизирует под свой проект.
Где ломается
- Правило без глоба = шум. Применяется ко всему, AI получает нерелевантный контекст, качество ответов падает.
- Слишком длинное правило игнорируется. Лимит ~500 строк — не стиль, а ограничение внимания модели.
- Это framework, не реализация. Сам по себе репо — шаблон; ценность возникает только когда правила наполнены доменными стандартами проекта.
Для кого и почему
Если у вас команда активно использует AI-инструменты и вы ищете способ удержать архитектурные стандарты без ручного контроля каждого PR — governance через toolchain, а не через встречи. Дополняет clarify gate в Jira (#11) и Spec Kit до кода (#12): rules действуют в IDE уже при реализации.
Хотите, чтобы AI-assisted разработка в вашей команде работала с архитектурными guardrails?
Постановка governance для команд, где вайб-кодят — так, чтобы стандарты соблюдались инструментом, а не доброй волей каждого разработчика.
Написать на почтуДругие разборы
Серия инженерных разборов: реальная задача → методика → работающий артефакт → честный разбор, где он ломается.
К серии →