Что такое ИИ-агент без доверия: метод spec-review убрал ручное ревью 11 000 строк кода

Проблема знакома всем, кто делегирует генерацию кода ИИ-агентам. По наблюдению Кальницкого, 50% времени, сэкономленного на написании кода, сжигается на его ревью. Диффы (изменения в коде) на 10 000 строк, которые агент создаёт за час, приходится вычитывать вручную. Метод spec-review переносит контроль качества на этап до генерации кода и заменяет построчную проверку автоматическими тестами соответствия спецификации.

Что понадобится

• ИИ-агент для генерации кода (Кальницкий не указывает конкретный, подойдёт любой агентный инструмент: Cursor, Claude Code, Copilot в агентном режиме)
• Навык написания дизайн-документов (спецификаций) на 5-10 минут чтения
• Знакомство с приёмочными тестами на языке Gherkin (язык описания тестов простыми фразами «Когда… Тогда…»)
• Инструмент мутационного тестирования (проверяет, ловят ли тесты ошибки, внося мелкие поломки в код)
• Время: первая спецификация займёт несколько часов, дальше процесс ускоряется

Пошаговая инструкция: как внедрить spec-review

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

2. Разделите архитектуру на три слоя и пропишите правила для каждого:

3. Функциональное ядро. Логика описана алгебраическими типами и чистыми функциями (функциями без побочных эффектов, которые при одинаковых входных данных всегда дают одинаковый результат). Они целиком помещаются в контекст ИИ-агента и тестируются без моков (подставных объектов). Ядро не содержит ввода-вывода.

4. Оболочка. Тонкие интерфейсы к внешнему миру: базам данных, очередям сообщений, HTTP. Здесь же обвязка для надёжности: транзакции, повторные попытки, таймауты, кеши. Оболочка делает то, что ядро не может выразить типами.

5. Оркестрация. Контроллеры или обработчики сообщений, которые вызывают оболочку, передают результат в ядро и применяют его решение.

6. Обсудите и утвердите спецификацию с командой. Именно здесь принимаются ключевые архитектурные решения. Это и есть «spec-review»: ревью переносится со сгенерированного кода на спецификацию. Команда проверяет типы, сигнатуры функций ядра и интерфейсы адаптеров оболочки. По словам Кальницкого, в этих местах ловится 90% потенциальных проблем.

7. Поставьте агенту задачу строго по утвержденной спецификации. Не по описанию задачи из бэклога, а именно по дизайн-документу. Пример из спеки Кальницкого для ядра:

Core/ не имеет using на Kafka, Microsoft.Extensions.*, 
Confluent.Kafka — ноль I/O.

Решение продюсера — ADT, не bool + nullable:
public abstract record ProducerDecision {
  public sealed record SendNow : ProducerDecision;
  public sealed record DeferUntilWindow(UtcWindow Target) 
    : ProducerDecision;
  public sealed record DeadlineExceeded(DeadlinePolicy Policy) 
    : ProducerDecision;
}

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

2. Приёмочные тесты на языке Gherkin

3. Интеграционные тесты
4. Мутационное тестирование

5. Субагенты-ревьюеры и DoD (Definition of Done, список критериев завершённости) при составлении плана

6. Добавьте автоматический чек-лист: соответствует ли схема базы данных модели данных, актуальна ли документация API, соблюдаются ли зависимости между компонентами.

7. Отправляйте код в продакшен без построчного ревью. Ответственность за качество кода лежит на операторе ИИ-агента, а не на ревьюере.

Что это даёт вам прямо сейчас?

Разработчику, который использует ИИ-агентов. Метод убирает самое болезненное бутылочное горлышко: построчное ревью сгенерированного кода. Вместо чтения 10 000 строк диффа вы читаете спеку на 5-10 минут и проверяете, прошли ли автоматические тесты.

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

Предпринимателю или менеджеру продукта. Задача на три месяца для троих человек решена одним архитектором за два месяца факультативной работы. Метод масштабирует разработчика, а не команду. Для команд в РФ и СНГ, где ИИ-агенты доступны через Cursor, Copilot и открытые модели, подход применим без ограничений.

Автору Дзена или контент-специалисту. Принцип spec-review работает не только в коде. Если вы делегируете нейросети написание текстов, лонгридов, скриптов: утверждайте структуру и критерии до генерации, а не правьте результат построчно. Суть та же: дешевле проверить план, чем переписывать готовое.

Ключевой вывод простой: тот, кто понимает, что такое ИИ-агент и где заканчивается его компетенция, выигрывает не за счёт скорости генерации, а за счёт качества постановки задачи. Spec-review превращает проверку кода из мучительного чтения тысяч строк в пятиминутное согласование архитектуры. Попробуйте на ближайшей задаче: напишите спеку на три слоя до того, как откроете агент, и посмотрите, сколько времени на ревью вы потратите после.