Три афоризма, которые я повторяю чаще остальных: «PRD = WHAT, не HOW», «CLAUDE.md - конституция одного агента, BMAD - конституция команды», «без процесса AI повышает сложность кода». Последний - не риторика. MSR 2026 даёт цифры: 42.7% коммитов AI-агентов повышают цикломатическую сложность, 56.1% снижают Maintainability Index, +39% когнитивной сложности на горизонте.
Все говорят, что AI ускоряет разработку. Это правда - мы проверили. За восемнадцать месяцев работы с AI-помощниками скорость написания кода выросла заметно. Но скорость и качество оказались разными векторами. Без рамок мы получали быструю работу с накапливающимся долгом - PR за PR, каждый сам по себе нормальный, и всё равно кодовая база через три месяца просила рефакторинга. Когда добавили процесс - первые недели медленнее, каждый шаг требовал согласования артефактов. Зато откатов не было.
За эти месяцы у меня сложились три тезиса. Не правила - именно тезисы: утверждения, которые можно проверить и опровергнуть. Я повторяю их чаще остального, когда разговариваю с командами, которые начинают работать с агентами всерьёз.
1. PRD - это WHAT, не HOW
«PRD = WHAT, не HOW. Если ты пишешь стек в PRD, ты пишешь не PRD, а ticket.»
PRD (документ требований к продукту) отвечает на два вопроса: зачем это нужно и что должно произойти с точки зрения пользователя. Не «как реализовать» и не «чем реализовать» - это вопросы для архитектурного решения, спецификации, технического задания.
Звучит очевидно. На практике нарушается постоянно.
Я видел PRD с формулировкой «использовать PostgreSQL для хранения событий» прямо в секции требований. Или «реализовать кэш через Redis». Это не требования к продукту - это технические решения, которые случайно написали не туда. Разница принципиальная: требование описывает ожидаемое поведение, решение описывает способ реализации. Когда решение попадает в требование, оно теряет контекст своего появления и превращается в «так написано» - без обоснования, без условий пересмотра, без автора.
Конкретная история. Команда в B2B выбирала инструмент аналитики. В PRD написали: «использовать Mixpanel для воронок конверсии». Через год Mixpanel поднял тарифы втрое. Команда захотела переехать на Amplitude - и обнаружила, что инструмент зашит в требование, а значит, смена инструмента формально требует переписывания PRD и повторного согласования. Три недели уговоров, потому что «в требованиях написано Mixpanel». Инструмент попал в документ, где должно было быть только поведение.
Правильная формулировка в том PRD звучала бы: «команде нужны воронки конверсии по пяти ключевым событиям, p95 latency не более двух секунд». Всё. Выбор инструмента - отдельное архитектурное решение с условиями пересмотра: «если цена превысит X в год или функциональность ограничит Y, пересматриваем».
Когда за PRD работает AI-агент - эта проблема усиливается. Агент послушно выполняет то, что написано в требованиях. Если там написан стек - агент строит именно его, без вопросов. Требование и решение перестают быть разными слоями, агент строит «правильно по документу» и выдаёт технический долг, который невидим до ревью.
Практическое правило: если в вашем PRD есть слова «PostgreSQL», «Redis», «Kafka», «React», «S3» в секции требований - это сигнал. Не значит, что эти инструменты неправильные. Значит, что они попали не в тот документ.
Подробнее о том, как устроены тринадцать разделов PRD и чем спецификация отличается от требований: Цикл PRD → RFC → ADR и Спецификации против требований.
2. CLAUDE.md - конституция одного агента. BMAD - конституция команды агентов
«CLAUDE.md - конституция одного агента. BMAD - конституция команды агентов. Первая масштабируется на человека. Вторая - на процесс.»
CLAUDE.md (или его аналог в других инструментах - .cursorrules, AGENTS.md, системное сообщение на старте) - это набор правил, которые один AI-агент читает в начале каждой сессии. Без него агент каждый раз заново угадывает ваши конвенции: как вы называете переменные, куда кладёте тесты, как оформляете коммиты, что считаете «готово». С ним агент работает как новый сотрудник, который прочитал руководство по онбордингу перед первым рабочим днём.
Это решает проблему одного разработчика с одним агентом. И именно здесь начинается следующая проблема.
Возьмём команду из пяти человек, у каждого - свой агент. Каждый агент правильно настроен, каждый работает в рамках своего CLAUDE.md. Агент первого разработчика реализует фичу А за несколько часов - делает PR. Агент второго параллельно реализует фичу B - тоже делает PR. Оба PR технически корректны. При ревью выясняется: фича A предполагает, что событие X хранится в базе данных, фича B - что в очереди. Оба агента работали «правильно» по своим конвенциям. У них не было общего поля для согласования архитектурного допущения.
Пять разработчиков с пятью агентами - это не пять человек, это двадцать пять «работников» в одном репозитории. Чтобы это не превратилось в Вавилон, нужна общая конституция: один формат PRD, один формат архитектурного решения, одна шкала глубины задачи. Ни один из агентов не принимает решение в одностороннем порядке, потому что «правила одного» несовместимы с «масштабом команды».
BMAD (Breakthrough Method for Agile AI-Driven Development) - один из форматов такой общей конституции. Не единственный и не обязательно лучший для любой команды. Важен принцип: общий формат артефактов как связующий язык между агентами разных разработчиков.
Без него команда масштабирует скорость. Вместе с ней - рассогласование.
С ним - каждый агент знает не только «как работает мой разработчик», но и «как устроен процесс принятия решений здесь». Разница между «я выполняю задачу» и «я понимаю контекст задачи» - именно здесь.
Детали координации двух-пяти агентов в одном репозитории: Координация нескольких агентов. Контракт подсказок - язык, которым агент и инструмент разговаривают: Протокол агента.
3. MSR 2026: AI без процесса повышает сложность кода
«Без процесса AI ускоряет производство долга так же, как ускоряет производство кода. Это математика.»
Предыдущие два тезиса - методологические рассуждения. Этот подкреплён данными.
В 2026 году на Mining Software Repositories вышло исследование, которое я перечитывал несколько раз: «Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects» (Courtney E. Miller et al., MSR 2026). Авторы изучили коммиты, сделанные AI-агентами в реальных открытых репозиториях, и сравнили их с коммитами без агентов по нескольким метрикам сложности кода.
Цифры:
- 56.1% агентских коммитов снижают Maintainability Index - показатель удобства сопровождения
- 42.7% агентских коммитов повышают Cyclomatic Complexity - цикломатическую сложность
- +18% статических предупреждений компилятора и линтера на горизонте
- +39% когнитивной сложности - устойчивый «agent-induced technical debt»
Это не означает, что AI плохо пишет код. Это означает, что AI пишет код быстро - и с теми же системными проблемами, что человек, когда торопится. Больше коммитов в единицу времени при том же проценте проблемных коммитов = больше проблем на выходе. Скорость усиливает то, что уже есть.
Второе исследование с той же конференции - «When AI Code Doesn’t Stick» (MSR 2026) - изучало отменённые AI-коммиты: почему код, который агент написал, потом откатывали. Таксономия причин:
- 22.33% - непредвиденные побочные эффекты и переусложнение
- 22.13% - функциональная некорректность
- 17.71% - проблемы с качеством кода
- 12.47% - проблемы с зависимостями
Что меня в этой таксономии останавливает: самая большая категория - не «неправильный алгоритм» и не «синтаксическая ошибка». Это переусложнение и побочные эффекты. То есть агент решает задачу, но делает это так, что решение задевает то, чего не должно было касаться, или создаёт структуру избыточно сложную для поставленной задачи. Это типичный результат работы без контекста - без понимания границ задачи, без архитектурных ограничений, без критерия «готово».
Что отличало команды, у которых метрики не просели? Авторы MSR не делают из этого отдельную секцию, но паттерн прослеживается в примерах: у них был процесс. Не конкретный инструмент - процесс: PRD с чёткими границами, архитектурные решения с условиями пересмотра, ритм ревью, артефакты, в которых агент мог прочитать «что здесь можно, а что нельзя».
Формула простая. Агент производит коммиты быстрее человека. Если процент проблемных коммитов не снизился - при росте скорости вы получаете больше проблем за тот же период. Снизить этот процент можно только одним способом: дать агенту рамки, в которых он понимает контекст задачи. Это и есть процесс.
Решение не «использовать агентов меньше». Решение - выстроить процесс до того, как разогнать скорость. Скорость - следствие, не причина. Процесс - причина хорошей скорости.
Источники:
Если из трёх тезисов вынести один - пусть будет третий.
Первые два - про то, как думать о задачах и командах. Третий - про то, что происходит, когда этого нет. Цифры не риторика: 56%, 42%, +39% - это не «AI плохой», это «AI без процесса производит долг в промышленных масштабах». Не хуже человека без процесса. Просто быстрее.
Процесс - не роскошь и не бюрократия. Это защита от технического долга, который AI начинает производить индустриально, как только вы даёте ему скорость без рамок.