Почему агентная разработка нуждается в политиках

Средства разработки с помощью ИИ эволюционируют: от чат-ассистентов, подсказывающих код, к автономным агентам, которые сами планируют, пишут и ревьюят. Вместе с инструментами меняется и смысл того, что мы называем Governance (я буду использовать английский термин — ближайший русский аналог «регулирование», но он уже: governance это не только сами правила, но и то, как мы их принимаем и кто следит за их соблюдением). В чат-режиме разработчик — страховочная сетка: каждую строчку, предложенную моделью, он оценивает сам. В автономном режиме модель принимает тысячи микро-решений в час, и разработчик физически не может проверить их все. Governance перестаёт быть вспомогательным инструментом и становится жёстким требованием.

В этой статье я опишу трёхуровневый Governance-стек, который мы построили для платформы бронирования спортивных площадок (NestJS на бэкенде, Next.js на фронтенде), и покажу, почему он необходим. Но закончу открытым вопросом. Governance живёт в контекстном окне, а контекст стоит денег. Насколько устойчива такая модель при масштабировании? Ответ — в следующей статье.

Часть 1. Три уровня автоматизации

Разработка с помощью ИИ — это не выключатель с двумя положениями: «пишет человек» или «пишет машина». Это спектр. По мере движения по нему разработчик отдаёт всё больше контроля, а Governance из неявного становится явным. На третьем уровне политики перестают быть накладными расходами и превращаются в обязательное условие.

Уровень 1. Чат

Вы пишете промпт — модель отвечает кодом. Вы читаете, оцениваете, копируете в редактор, тестируете. Все решения за вами: модель лишь предлагает варианты. Обратная связь медленная, человеческая — каждый раунд занимает минуты, каждое решение осознанно.

Это и есть «вайб-кодинг» в хорошем смысле — термин, который популяризировал Андрей Карпати: описываешь задачу, получаешь код, не углубляешься. Для пет-проекта или прототипа — отлично. Для продакшена — нет, но об этом ниже.

В этом режиме Governance полностью неявный. Вы и так знаете, что throw new Error() в сервисе — это неправильно. Что в API используется snake_case. Какие файлы нельзя трогать без плана. Любая строчка, предложенная моделью, проходит через вашу голову прежде чем попасть в кодовую базу. Вы — страховочная сетка. Модель предлагает варианты, а ваша задача — не дать ошибке пройти.

Уровень 2. Агент под присмотром человека

Модель уже не просто предлагает код — она читает файлы, вносит изменения, запускает тесты, итерирует. Но вы по-прежнему контролируете процесс. Задаёте границы задачи. Утверждаете изменения до того, как они попадут в код. Ревьюите результат каждого вызова. Агент — это джун, вы — техлид. Обратная связь ускоряется: агент берёт на себя механическую работу, вы фокусируетесь на архитектуре и ревью. Но каждое действие агента всё ещё ограничено вашим указанием.

В этом режиме Governance становится явным, но остаётся лёгким. Вам нужны соглашения — именование, структура файлов, ожидания от тестов, — чтобы агент выдавал стабильный результат. Хороший harness — Claude Code, Codex CLI, Cursor — уже на этом уровне помогает: он умеет подбирать релевантные примеры из кодовой базы и показывать их агенту (few-shot prompting), что снижает количество ошибок. Но вы всё ещё проверяете всё сами. Ошибку в названии ловите, потому что читаете дифф. Слабый тест замечаете, потому что смотрите на утверждения. Агент может ошибаться, но вы его поправляете. Governance здесь — инструмент продуктивности, снижающий количество правок. Но это не несущая конструкция: если соглашения несовершенны, ваш ревью закрывает пробелы.

Уровень 3. Автономные агенты — точка перелома

Здесь модель управляет собственным исполнением. Создаёт подагентов для параллельной работы. Связывает операции через десятки файлов. Принимает сотни микро-решений — именование, структура, обработка ошибок, тестовые утверждения, порядок импортов — без участия человека на каждом шаге. Разработчик задаёт направление в начале и проверяет результат в конце. Как агент доберётся до цели — его дело.

Если на Уровне 1 вайб-кодинг — это осознанный выбор (я не смотрю, потому что ставки низкие), то здесь вы не смотрите, потому что физически не можете. 10 000 микро-решений в час.

На Уровне 2 вы ревьюите каждое действие агента индивидуально — ваше суждение заполняет пробелы в соглашениях. На Уровне 3 вы физически не можете этого делать. Агент, принимающий 10 000 микро-решений в час через параллельных подагентов, производит больше решений, чем вы способны проверить за день. Вы больше не страховочная сетка. Потому что вы не смотрите.

Governance-стек, который я описываю в этой статье — 12 документов политик, 10 навыков, 6 специализированных агентов, 6 ревью-промптов, 7-фазный рабочий процесс с зафиксированными артефактами, — это то, что делает Уровень 3 возможным. Не бюрократия ради бюрократии. Обязательное условие: закодированное суждение, заменяющее внимание разработчика в каждой точке микро-решения. Каждая политика — это решение, которое человек принял бы во время ручного ревью на Уровне 2, заранее формализованное и проверяемое автоматически.

Это ровно тот же переход, который DevOps совершил от ручной настройки серверов к Infrastructure-as-Code. На первом уровне DevOps вы заходите по SSH и запускаете скрипты для повторяющихся задач. На третьем — описываете всё в Terraform, и CI сам следит за соблюдением правил. Вы не ревьюите конфигурации, потому что они генерируются из протестированного, версионированного кода. Автономная агентная разработка — это третья стадия DevOps, применённая к самому процессу написания кода.

Часть 2. Три слоя защиты

Крупные компании управляют агентной разработкой через слои институциональных правил. Google и Microsoft следят за соблюдением политик ревью, стайл-гайдов и порогов покрытия не за счёт бдительности отдельных разработчиков, а через обязательные CI-проверки. Автор кода не решает, достаточно ли он хорош для релиза. На масштабе политики становятся инфраструктурой: линтер блокирует мёрж, падение покрытия ломает сборку, архитектурные ревью-борды контролируют межкомандные изменения. Ни один инженер не может переопределить систему — и ни один агент не должен.

У маленькой команды нет ни ревью-бордов, ни выделенной инфраструктуры. Но проблема та же: когда агенты пишут код автономно, разработчик не может ревьюить каждый вызов при 10 000 микро-решений в час. Решение — тот же паттерн, только в меньшем масштабе: закодируйте правила, применяйте их механически и позвольте более сильным моделям ревьюить более слабые.

Наш проект — небольшой стартап на NestJS и Next.js — делает именно это. Governance не привязан к конкретной модели: это набор документов, навыков и правил рабочего процесса, которые может исполнять любая способная модель. Три слоя:

Слой 1. Инженерные политики

Двенадцать документов. Не рекомендации — контракты с пронумерованными разделами, на которые агенты ссылаются механически:

Таблица 1. Инженерные политики — 12 документов

У каждой политики есть заголовок «Status: Adopted», дата принятия, пронумерованные разделы и ревью-чеклист. Формат намеренный: агенты могут механически парсить структуру, а ревьюеры — ссылаться на §4.1 вместо пересказа правила.

Слой 2. Навыки и специализированные агенты

Политики сами по себе не работают. Их применяют десять навыков и шесть специализированных агентов:

10 навыков (slash-команды): /test-driven-development, /verification-before-completion, /perf-check, /systematic-debugging, /issue-triage, /migration-review, /openspec-execute, /issue-to-proposal, /llm-council, /writing-skills.

6 специализированных агентов: coverage-analyzer (пробелы в покрытии с риск-скором), refactor-analyzer (дублирование, мёртвый код, N+1-запросы), migration-review (безопасность миграций), perf-check (регрессии производительности), apply-task (исполнение спецификаций) и fast (общие дешёвые задачи).

6 ревью-промптов: proposal-reviewer, design-reviewer, spec-reviewer, tasks-reviewer, consistency-reviewer и ux-reviewer — по одному на каждый тип артефакта.

Ключевое решение: ревью-модель желательно должна быть сильнее авторской. Pro-модель ревьюит то, что написала Fast-модель. Fast-модель, исполняющая зафиксированную спецификацию, делает механические ошибки — перепутала переменную, пропустила граничный случай в тесте, не тот порядок импортов. Pro-модель ловит их до того, как они попадут в кодовую базу. Это не двойная проверка одной и той же работы: ревьюер читает результат, а не ход рассуждений автора, и поэтому находит другие классы ошибок.

Политики привязаны к механизмам контроля явно:

• Стандарты тестирования → /test-driven-development, /verification-before-completion, coverage-analyzer

• Обработка ошибок → /systematic-debugging, глобальный exception filter, все ревью-промпты

• Дизайн API → design-reviewer, spec-reviewer, proposal-reviewer

• Здоровье кода → refactor-analyzer, pre-commit jscpd + ts-prune

• Производительность → /perf-check, Lighthouse CI, проверка размера бандла в CI

• Трекинг задач → /issue-triage, /issue-to-proposal

Слой 3. Рабочий процесс

Разработка фич идёт по собственному 7-фазному процессу. За основу взята методология разработки через спецификации — OpenSpec:

EXPLORE → PROPOSE → DESIGN → SPEC → TASKS → APPLY → ARCHIVE

Каждая фаза создаёт зафиксированный артефакт, который проходит ревью до начала следующей фазы. Именно так рождаются «предложения» (proposals): результат фазы PROPOSE — это документ, описывающий, что и зачем мы собираемся менять. Правило последовательной заморозки устроено просто: прошёл ревью — артефакт заблокирован. Это устраняет порочный круг «исправление A ломает B, исправление B ломает A». Ревьюеры запускаются без истории разговора: если ограничение не записано в артефакте или в документе, на который тот ссылается, — для ревьюера его не существует. Это вынуждает артефакты быть самодостаточными: разработчик не может полагаться на то, что «мы же это обсуждали».

Каждый артефакт несёт критерии приёмки в нотации EARS — триггеры WHEN, IF, WHILE с ответами SHALL. Структурированная нотация снижает неоднозначность и даёт более тестируемые требования, чем обычный текст.

Фазы планирования — EXPLORE, PROPOSE, DESIGN, SPEC — работают на Pro-моделях: архитектура, рассуждения, тестируемость. Фазы исполнения — TASKS, APPLY, ARCHIVE — на Fast-моделях: механическая работа по зафиксированной спецификации. Все ревью — на Pro: ревьюеру желательно использовать модель сильнее авторской.

В основе маршрутизации лежит структурная асимметрия. Артефакт спецификации, созданный Pro-моделью на фазах планирования, переносит «интеллект» вниз по потоку. Fast-модели не нужно понимать архитектуру — она просто точно следует инструкциям. Pro-модель остаётся на ревью, где каждый пойманный баг экономит на порядки больше, чем стоит сам ревью-вызов.

Git-трекинг задач

Задачи живут в репозитории как markdown-файлы в openspec/issues/. Вместо поля «статус» — положение в директории: открытые задачи лежат в open/, решённые — в archive/. Каждое исправление бага требует регрессионного теста. Цикл TDD: красный до исправления, зелёный после.

Задачи проходят пять фаз:

DISCOVER → TRIAGE → RESOLVE → VERIFY → ARCHIVE

DISCOVER — кто угодно, человек или агент, создаёт issue.md с описанием и шагами воспроизведения. TRIAGE — агент назначает приоритет, привязывает задачу к требованиям спецификации и принимает решение: исправить сейчас, отложить или повысить до предложения. RESOLVE — анализ корневой причины, падающий тест (RED), исправление (GREEN), коммит. VERIFY — сверка с базовым состоянием подтверждает отсутствие регрессий; баг больше не воспроизводится. ARCHIVE — задача переносится в archive/, перекрёстные ссылки валидируются.

Задачи и предложения связаны в обе стороны. Если исправление затрагивает больше трёх файлов или вводит новое поведение, задача повышается до полноценного предложения через /issue-to-proposal: задача получает поле promoted_to, предложение — обратную ссылку origin. При архивации связанная задача закрывается. В обратную сторону: функциональность, намеренно исключённая из предложения на фазе SPEC, становится отложенной задачей (type: deferred, origin указывает на slug предложения).

Агенты могут создавать задачи не когда угодно, а только в строго определённых точках процесса:

• EXPLORE — ранее существовавшие сбои тестов, обнаруженные при замере базового состояния

• PROPOSE — агенты не могут создавать задачи

• DESIGN — агенты не могут создавать задачи

• SPEC — отложенные элементы, баги, найденные при написании спецификации

• TASKS — агенты не могут создавать задачи

• APPLY — баги, найденные при реализации

• ARCHIVE — финальные проверки, перемещение решённых задач в архив

Этот гейтинг не позволяет агентам генерировать неограниченную побочную работу на фазах, где нужна концентрация. Баги, о которых сообщил человек, обходят любые гейты.

Весь жизненный цикл разработки — фичи, баги, отложенные задачи, ревью, архив — живёт в репозитории. Агенты читают и пишут задачи теми же инструментами, что и код. Никакого внешнего трекера. Никакого разрыва синхронизации.

Не обязательно переносить всё в Git, если у вас уже есть трекер с историей. Того же эффекта можно добиться, написав небольшой MCP-сервер: он даст агенту те же возможности — создать задачу, найти по номеру, изменить статус, привязать к спецификации — но данные останутся в существующей системе. Главное, чтобы интерфейс был единообразным и машиночитаемым. Агент не должен гадать, где искать задачи и как они устроены.

Что это даёт

Governance-стек решает три проблемы, без которых сложно построить индустриальный конвейер разработки:

1. Неограниченные циклы задач. Рабочий процесс фиксирует границы задачи до начала реализации. Каждая задача привязана к конкретному требованию спецификации. Агент не может на ходу переписать спецификацию под себя.

2. Расползание границ задачи без истории изменений. Каждое предложение включает explore-brief.md — документ, в котором заранее зафиксированы человеческие решения и ограничения. review-log.md записывает найденные проблемы, исправления и принятые решения после каждого раунда ревью. Правило последовательной заморозки не позволяет модели тихо пересмотреть или отменить уже согласованное. Находки на поздних фазах требуют явных поправок — и сами поправки тоже протоколируются. Детерминированный скрипт валидации проверяет, что все перекрёстные ссылки разрешаются, обязательные файлы на месте, ни один артефакт не потерян. Это проверка, которую модель не может обойти словами — хотя бы потому, что выполняется она не на LLM.

3. Исполнение без учёта стоимости. Таблица маршрутизации назначает дешёвые Fast-модели на высокообъёмную механическую работу и дорогие Pro-модели на низкообъёмные рассуждения — архитектурные решения, ревью-гейты. Структура затрат встроена в процесс, а не прикручена сверху.

Важны не сами слои по отдельности, а то, что они связаны. Политики без навыков и агентов — просто текст, который никто не соблюдает. Навыки без рабочего процесса — просто скрипты, непонятно когда запускать. Рабочий процесс без политик — схема на доске: красиво, но ничего не гарантирует.

Есть ещё один механизм, который стоит упомянуть отдельно. Хороший harness — Claude Code, Codex CLI, Cursor — умеет не просто показывать агенту правила, но и подбирать релевантные примеры из кодовой базы: как устроен похожий модуль, какой паттерн уже используется, как выглядит хороший тест в этом проекте. Сама модель способна учиться на примерах (это называется few-shot prompting): исследование n1n.ai (январь 2026) показало, что добавление трёх релевантных примеров в промпт повышает успешность выполнения задачи агентами с 15% до 78%. Но какие именно примеры показывать — решает harness. Наш CLAUDE.md + 12 политик — это, по сути, статический few-shot: вместо динамического подбора мы заранее закодировали «как правильно» в документы.

Индустрия движется именно в эту сторону. Команды, надёжно поставляющие код в 2026 году, принимают одну и ту же архитектуру: песочница для исполнения, явное объявление границ до запуска агентов, неизменяемые логи действий, человеческие гейты на решениях с высокими последствиями и потолки затрат на уровне оркестрации. Наш трёхуровневый стек — лишь одна реализация этих принципов: 12 политик вместо 70-строчного CLAUDE.md, 7-фазный процесс вместо PR-шаблона, агенты-ревьюеры вместо обязательного аппрува от человека. Паттерн общий. Отличается только глубина проработки.

Где мы споткнулись

Стек не был идеален. Больше всего человеческого вмешательства требовал дизайн интерфейсов. Если не следить за соблюдением политик и не поправлять агентов вручную, они начинали лепить кто во что горазд: каждый компонент выглядел нормально сам по себе, но при сборке получалась каша. Отступы, цвета, паттерны взаимодействия расходились. Оказалось, что текстовыми политиками непросто описать визуальные ограничения так, чтобы агент применял их стабильно.

Но ситуация улучшалась. Каждое ручное исправление становилось примером в дизайн-политике. Со временем политика накопила достаточно конкретных случаев, и агенты перестали повторять одни и те же ошибки. Та же динамика работала везде: агент пропускал непротестированный граничный случай — политика тестирования получала новое требование; ревью находило функцию с цикломатической сложностью выше десяти — политика качества кода пополнялась более удачным примером. Политики не были статичными документами, написанными раз и навсегда. Каждое исправление бага предотвращало десятки таких же багов в будущем. Политики работали как инвестиция с растущей отдачей: чем больше мы в них вкладывали, тем меньше ошибок допускали агенты.

И пожалуй, самый глубокий вывод из всей этой истории: Governance в контекстном окне не просто дешевле дообучения — он быстрее улучшается. Дообученная модель требует переобучения при каждом изменении политики. Политика в контекстном окне — это исправленная строчка текста. Цикл от обнаружения проблемы до её закрытия — минуты, а не недели. И эта скорость важнее начального качества правил, потому что начальное качество никогда не бывает достаточно высоким.

Часть 3. Масштаб делает Governance обязательным

Governance — это накладные расходы. Когда вы в одиночку пишете скрипт, они не нужны: вы и есть Governance. Для команды из трёх человек с одним агентом у каждого достаточно лёгких соглашений. Но Governance становится обязательным — в тот момент, когда количество вызовов агентов превышает количество ревью кода, которые вы физически способны сделать за день.

Математика простая. Разработчик осмысленно ревьюит примерно 500–1 000 строк в час. Агентный процесс генерирует 5 000–10 000 строк в час через параллельные вызовы. При соотношении 10:1 у вас три варианта: (a) пропускать ревью для 90% сгенерированного кода, (b) нанять в десять раз больше ревьюеров, либо © закодировать критерии ревью настолько тщательно, чтобы более сильная модель проводила его автоматически.

Вариант (a) — это 11% непроверенных обновлений бэкенда в Uber и инцидент на $500M. Вариант (b) убивает весь выигрыш в продуктивности от использования агентов. Вариант (c) — это Governance, и только он масштабируется.

Доказательная база есть с обеих сторон. «Constitutional Spec-Driven Development» (arXiv, 2026) показал: встраивание спецификаций безопасности в системный промпт снижает количество дефектов на 73% по сравнению с неограниченной генерацией. Статья «Productivity-Reliability Paradox» (Farrag et al., 2026), обобщившая 67 источников, формулирует жёстко: «дисциплина спецификации, а не способности модели — вот что ограничивает надёжность разработки с помощью ИИ». Формальный ROI-анализ (Ivchenko, 2026) даёт снижение дефектов на 30–90% и 200–400% ROI за три года. С положительной стороной разобрались: от Governance качество AI-кода растёт.

С отрицательной — тоже. Gartner Magic Quadrant: только 21% организаций имеют зрелое агентное управление. SIG проанализировала 30 000 корпоративных систем: AI-код содержит вдвое больше уязвимостей, чем написанный человеком, и 86% не дотягивает до рейтингов сопровождаемости. Вывод: без Governance агенты пишут код быстрее, но стоимость исправления ошибок превышает выигрыш в скорости.

Так как же применять Governance? Механизмов два, и один практически недоступен большинству команд. Дообучение (полное или LoRA) впекает соглашения в веса модели — нужны размеченные данные, вычислительный бюджет и переобучение при каждом изменении политики. Governance в контекстном окне помещает правила в системный промпт — работает на любой модели, обновляется мгновенно, не требует ничего, кроме токенов. Если у вас нет ML-инфраструктуры, выбора у вас нет. Только контекстное окно.

И здесь возникает напряжение. Governance в контекстном окне делает стек универсально доступным — без обучения, без инфраструктуры, без ML-экспертизы. Но он потребляет токены. А токены стоят денег. Стек такой глубины, как наш — 12 политик, 10 описаний навыков, 6 промптов агентов, 6 ревью-промптов, правила рабочего процесса, — весит примерно 80 000 токенов. Они загружаются при каждом вызове агента. Тысячи вызовов на фичу. Десятки фич.

Вопрос неизбежен: сколько стоит поддерживать этот уровень Governance на масштабе? Экономически ли это устойчиво? Или под давлением затрат команды срезают политики, пока от всего Governance-стека не останется один CLAUDE.md на 70 строк — жертвуя теми самыми правилами, которые делают автономных агентов безопасными?

Стэнфордская лаборатория цифровой экономики (апрель 2026) обнаружила: задачи агентной разработки потребляют до 1 000× больше токенов, чем простой чат, с разбросом стоимости до 30× на одной и той же задаче, и модели не способны предсказать собственное потребление. Неуправляемая агентная разработка структурно не поддаётся бюджетированию — это ясно. Но никто не опубликовал второй датасет: что будет, если ею управлять. Реальная нагрузка. Конкретный стек. Тысячи продакшен-вызовов. И счёт.

Об этом — следующая статья: «Кто на самом деле лидирует в агентной разработке (и это не тот, о ком вы подумали)».

Источники

Доказательства эффективности Governance:

• Constitutional Spec-Driven Development (снижение дефектов на 73%): arXiv:2602.02584

• The Productivity-Reliability Paradox (Farrag et al., 2026): arXiv:2605.01160

• ROI of Spec Investment (снижение дефектов на 30–90%, Ivchenko, 2026): Zenodo

• Эмпирическое исследование EARS Notation: SN Computer Science (2025)

• SIG «State of Software 2026» (AI-код: 2× уязвимостей, 86% ниже рейтинга сопровождаемости): ITBrief

• Gartner Magic Quadrant for Enterprise AI Coding Agents (2026): Gartner

• Stanford Digital Economy Lab, «How Do AI Agents Spend Your Money?» (апрель 2026): Stanford

Агенты:

• Improving Agentic Coding Performance with Few-Shot Prompting (n1n.ai, январь 2026): n1n.ai

Публичные примеры агентных политик:

• OpenAI Codex CLI (88 AGENTS.md файлов): GitHub

• Trail of Bits Claude Code config: GitHub

• Multica/Karpathy CLAUDE.md (176K+ звёзд): GitHub

• AGENTS.md standard (Linux Foundation): GitHub