Григорий Добряков

Howto · разбор

Разбор 07 GitHub: 2 stars

Cursor rules как governance: как держать планку качества, когда команда вайб-кодит

Как кодировать архитектурные стандарты прямо в toolchain, с которым команда работает каждый день — а не в документ, который никто не открывает.

CTO Head of AI Tech Lead Architect

Проблема

Когда в команде вайб-кодят 10 человек, архитектурные стандарты дрейфуют. AI не знает конвенций проекта — каждый разработчик получает свой вариант «как правильно». Объяснять стандарты на встрече раз в квартал не работает: правило, которого нет в инструменте, не соблюдается.

Методика

Кодировать стандарт прямо в toolchain, с которым команда работает каждый день, а не в документ, который никто не открывает.

  1. 1. Правила как версионируемый артефакт. .mdc-файлы в .cursor/rules — контекстная, привязанная к репозиторию архитектурная инструкция в git.
  2. 2. Модульная организация. Поддиректории по фреймворку/домену (framework/python/ и т.д.) — правило применяется там, где релевантно.
  3. 3. Фокус и actionability. Каждое правило ≤ ~500 строк, с целью, примерами и анти-паттернами — иначе AI его игнорирует.
  4. 4. Метаданные применения. Globs и условные флаги определяют, когда правило активно. Без глоба правило применяется везде и шумит.
  5. 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-инструменты и вы ищете способ удержать архитектурные стандарты без ручного контроля каждого PR — governance через toolchain, а не через встречи. Дополняет clarify gate в Jira (#11) и Spec Kit до кода (#12): rules действуют в IDE уже при реализации.

Хотите, чтобы AI-assisted разработка в вашей команде работала с архитектурными guardrails?

Постановка governance для команд, где вайб-кодят — так, чтобы стандарты соблюдались инструментом, а не доброй волей каждого разработчика.

Написать на почту

Другие разборы

Серия инженерных разборов: реальная задача → методика → работающий артефакт → честный разбор, где он ломается.

К серии →