Коротко. Агенту нужна спецификация. Она даёт сценарии, ограничения, примеры и критерии проверки. Проблема возникает в другом месте: команда может принять исходную гипотезу за знание о продукте, данных или интеграции. Агент быстро превратит эту гипотезу в сервисы, тесты и инфраструктуру. После этого смена курса стоит дороже.

Этот текст основан на статье в корпоративном блоге Райффайзенбанка на Хабре и дополняет её самостоятельным разбором: где SDD помогает агентам, как не потерять точки принятия решений и что стоит измерять руководителю.

Быстрый код не делает решение дешёвым

Представим продуктовую задачу. Команда описала сценарии, API, ограничения и критерии приёмки. Агент получил контекст, написал код, тесты и Terraform. Через день есть почти готовый результат.

На этом этапе легко принять скорость реализации за скорость движения задачи. Иногда они совпадают. Изолированную фичу можно включить под флагом, показать части пользователей, посмотреть сигнал и откатить. В таком случае агент может быстро подготовить объём изменений, достаточный для эксперимента.

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

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

Во втором кейсе инженер быстро подготовил интеграцию с новым для команды продуктом 1С. Код появился за спринт. Юристы и безопасность ещё два спринта разбирались с данными, доступами и согласованиями.

В обоих случаях разработка шла быстро. Критическое неизвестное проверили поздно.

Границы эффекта AI

Исследования не дают единой универсальной оценки влияния инструментов для генерации кода. В контролируемых задачах эффект часто положительный: раннее исследование GitHub Copilot зафиксировало ускорение выполнения изолированной задачи. В реальной разработке картина зависит от типа задачи, зрелости системы и знания кода. В эксперименте METR опытные сопровождающие знакомых крупных OSS-проектов тратили с AI-инструментами раннего 2025 года на 19% больше времени на заранее определённые задачи.

Разрыв между написанием кода и выпуском особенно хорошо виден в работе NBER. В её данных автономные агенты были связаны с ростом числа коммитов на 240%; для числа проектов оценка составила 80%, для фактических релизов — 30%. Авторы связывают такое затухание эффекта с тем, что в производственной цепочке AI и человеческая работа остаются взаимодополняющими. Код проходит через ревью, CI, интеграции, проверки, выпуск и сопровождение.

У ограничения нет постоянного адреса. В одной системе очередь собирается в ревью. В другой всё ждёт тестового окружения, владельца API, безопасности или окна релиза. Ускорение генерации кода делает эти ограничения видимее.

DORA в отчёте 2025 года формулирует эту мысль шире: AI усиливает уже существующие сильные и слабые стороны организации. В отчёте рекомендуют работать и с инструментами, и с ограничениями системы доставки изменений.

Спецификация может выполнять две разные работы

У спецификации здесь два разных назначения.

Спецификация исследования (discovery spec) описывает ближайший проверяемый шаг. В ней важны сценарий, граница эксперимента, допущение, сигнал и решение, которое команда примет после сигнала. Такая спецификация помогает не спорить о том, что именно проверяем.

Исполнительская спецификация (execution spec) работает в повторяемой задаче с известными границами. Она может ссылаться на схему данных, грамматику конфигурации, контракт интеграции, каталог примеров и тестовый фреймворк. Здесь агент получает гораздо более узкое пространство решений.

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

Сама по себе спецификация не превращает процесс в waterfall. Waterfall-динамика появляется, когда команда считает раннее описание решения окончательным и перестаёт пересматривать его после новых сигналов. Есть и другая крайность: все решения откладывают под видом гибкости. В результате остаётся неопределённость без владельца, эксперимента и критерия выбора.

Где агенту можно дать широкий контур

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

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

Исполняемые контракты полезны именно своей ограниченностью. OpenAPI описывает API в машиночитаемой форме. JSON Schema проверяет структуру и заявленные ограничения данных. Эти инструменты проверяют ту часть реальности, которую команда сумела выразить в контракте. С их помощью нельзя автоматически проверить бизнес-смысл, правомерность работы с данными, производительность и качество пользовательского сценария.

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

Размер батча задаёт не число файлов

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

DORA рекомендует работать малыми батчами: их проще понять, провести через delivery-процесс и восстановить после сбоя. Для агентной разработки это тот же принцип. Агент способен подготовить широкий diff. Команда выбирает размер шага, который она способна проверить и безопасно выпустить.

Перед большой задачей полезно ответить на несколько вопросов.

  • Какой пользовательский или системный сценарий проверяем?
  • Что сознательно не входит в эту итерацию?
  • Какое предположение должно подтвердиться, чтобы продолжать?
  • Кто владеет данными, API, доступами и ограничениями?
  • Какие инварианты изменение не должно нарушить?
  • Какой тест, лог, метрика или демонстрация даст нужный сигнал?
  • Как включим изменение, что увидим после включения и как вернёмся назад?
  • Кто принимает решение продолжить, изменить курс или остановиться?

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

Что смотреть руководителю

Число пользователей AI-инструментов, PR и строк кода показывает активность использования. По этим данным нельзя судить о скорости и надёжности доставки изменений.

Я бы смотрел на три слоя.

Первый слой — использование: кто регулярно применяет инструмент, в каких сценариях и на каких этапах работы.

Второй — прохождение задачи: время от постановки до промышленной эксплуатации (Lead Time), пропускная способность потока (Throughput), ожидание ревью, время в CI, число итераций в PR и время от merge до релиза.

Третий — устойчивость: откаты, срочные исправления, доработки после развёртывания, дефекты после выпуска и время восстановления после неудачного деплоя.

DORA предлагает оценивать throughput и instability вместе. Метрики полезны на уровне приложения или сервиса, в контексте его риска и среды. Они плохо работают как KPI отдельного инженера.

Рост объёма подготовленного кода при растущих очередях на проверку и переделки не означает, что система стала быстрее. Польза агента проявляется, когда команда раньше получает сигнал, снижает риск ошибки и выпускает изменения без потери устойчивости.

Очень быстрый waterfall

SDD полезен, когда агент получает точные вводные, а повторяемые задачи опираются на правила, примеры и тесты. Команда получает хороший эффект, когда спецификация фиксирует накопленное знание и делает ближайший шаг проверяемым.

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

AI сокращает время до первого варианта. Инженерная работа по-прежнему включает выбор следующего вопроса, проверку ответа и ответственность за выпуск.