Представим обычную продуктовую задачу. Нужно добавить новую фичу. Команда описывает её через Specification-Driven Development и фиксирует сценарии, ограничения, API и критерии приёмки. Агент получает контекст, быстро пишет код, тесты и инфраструктуру. Через день, а то и раньше, почти готов результат. Но где здесь waterfall?

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

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

Когда быстрый результат действительно полезен

Сергей Чистяков уже рассказывал на Хабре о похожем опыте агентной разработки. В одном из наших экспериментов несколько сервисов на Python быстро собрали как прототипы, чтобы показать сценарий пользователям и проверить гипотезу. После обратной связи команда скорректировала решение и осознанно спроектировала production-версию на целевом стеке с авторизацией, наблюдаемостью и другими эксплуатационными требованиями.

Здесь дешёвый код сработал ровно так, как должен работать прототип. Он покупал знание о том, нужен ли пользователю этот сценарий и каким он должен быть. Команда не пыталась превратить прототип в production-основу без пересмотра.

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

Спецификация — не знание о продукте

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

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

Команда редко сразу знает о новой фиче всё необходимое.

Это нормальная природа работы с неопределённостью. Команда постепенно понимает, какой вопрос следовало задать. Но тут полезно различать две вещи:

• Спецификацию ближайшего проверяемого шага.

• Спецификацию всей будущей реализации.

Первая помогает агенту двигаться. Вторая может быть ориентиром, если команда воспринимает её как предположение, которое ещё предстоит проверить.

Как быстрый результат становится дорогим

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

Интеграция с комплаенс-проверкой

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

В следующем спринте выяснилось, что API был внутренним инструментом команды аудита и открывал доступ к сырым данным.. Использовать его другим командам было нельзя. Два спринта разработки пришлось списать вместе с новым сервисом.

Документация оказалась подробной и точной. Она отвечала на вопросы «как устроен API» и «как к нему подключиться», но не на главный вопрос: имеет ли команда право пользоваться этим API в своём сценарии. Разговор с владельцами интеграции стоил бы существенно дешевле готового сервиса.

Интеграция с новым продуктом 1С

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

Отдельного времени потребовали вопросы, которые не решаются скоростью написания кода. Можно ли обрабатывать эти данные, какие требования предъявляются к доступам и кто должен согласовать решение.

Что объединяет эти случаи

В обеих историях AI ускоряет написание кода, но не проверку предположений, от которых зависит решение.

Полная спецификация:

→ цепочка реализации

→ код, тесты, интеграции, инфраструктура

→ новое знание о продукте, данных или ограничениях

→ массовая переделка и повторная проверка

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

AI дёшево переписывает код, но разрешения владельцев систем, проверка данных, согласования и ответственность за выпуск остаются за командой.

Чем дальше команда проходит по одной ветке решения, тем дороже её пересмотр.

Узкое место — доверие к изменению

Написание кода долго было заметным ограничением скорости разработки. Агент резко ускоряет этот этап но остаются этапы, которые сами собой не масштабируются:

1. Понять, что реализован именно нужный сценарий.

2. Доказать, что изменение не сломало соседние сценарии.

3. Проверить интеграции, данные, безопасность и эксплуатационные последствия.

4. Решить, как безопасно выкатить и откатить результат.

5. Принять ответственность за то, что изменение можно выпускать.

Code review — важная часть этой работы. Ревьюер восстанавливает намерение, оценивает компромиссы, проверяет, хватает ли автоматических доказательств.

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

DORA связывает работу маленькими батчами с быстрыми циклами обратной связи и отмечает, что эта практика усиливает положительный эффект AI на продуктовый результат.

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

Агент в узкой типовой задаче

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

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

Для этой работы команда дала агенту грамматику конфигураций и правила её применения. Грамматика фиксирует допустимые конструкции. Правила определяют, как описывать подключение, валидацию и трансформации. А отдельный скилл объясняет агенту, как пользоваться этими артефактами в конкретной задаче.

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

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

Здесь особенно важна связка из двух шагов:

грамматика и правила конфигурации
→ конфигурация подключения
→ типовой тестовый фреймворк и пример
→ автотесты
→ проверка результата командой и пайплайном

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

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

Хороший AI-конвейер и размер задачи

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

Признаки здорового конвейера:

• Есть пользовательский или системный сигнал, который появится быстро.

• Изменение можно включить ограниченно: по флагу, для сегмента или в shadow-режиме.

• Определён понятный rollback.

• Автоматические тесты и контракты покрывают главные инварианты.

• Проверены критические неизвестные: качество модели, доступность данных, права на API, требования безопасности и комплаенса.

• Известен владелец решения, который понимает риск.

• Команда знает, что будет делать при отрицательном результате эксперимента.

Для повторяемых операционных задач к этому списку добавляются ещё несколько признаков:

• Пространство допустимых решений описано грамматикой, схемой или набором контрактов.

• Есть типовые примеры, по которым можно восстановить ожидаемую структуру результата.

• Правила валидации исполняемы или легко проверяются человеком.

• Определено, какие части работы может выполнять неинженерная роль, а какие остаются зоной решения разработчика.

• Результат встраивается в существующий CI/CD-процесс, тестовый контур или другой привычный механизм контроля.

В таком конвейере AI помогает быстрее провести эксперимент, подготовить типовой артефакт или воспроизводимо выполнить операционную работу.

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

Что должен делать SDD

Хорошая спецификация делает ближайший шаг проверяемым. Она не задаёт весь путь реализации сразу.

Перед агентной задачей полезно зафиксировать короткую карточку:

Сценарий: какой пользовательский или системный случай проверяем?
Граница: что сознательно не делаем в этой итерации?
Критическое предположение: что должно оказаться правдой, чтобы продолжать?
Внешние владельцы: с кем нужно подтвердить права, данные, доступы и ограничения?
Инварианты: что изменение не имеет права нарушить?
Проверка: какой тест, метрика, демонстрация или лог подтвердит результат?
Выпуск: как включаем, наблюдаем и откатываем?
Владелец: кто принимает решение о следующем шаге?

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

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

Она также помогает раньше задать вопросы, на которых строились истории выше. Есть ли право пользоваться API, доказана ли точность модели на реальных данных, согласованы ли доступы и данные, по какому критерию стоит продолжать инвестиции?

И вот мы снова пришли к XP

Это звучит знакомо, потому что AI не отменил то, за счёт чего работает Extreme Programming.

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

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

Парная работа сегодня часто выглядит как «инженер плюс агент». Агент готовит реализацию, варианты и тестовые заготовки. Инженер удерживает контекст, задаёт границы, замечает новые обстоятельства и решает, стоит ли продолжать по этой ветке.

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

XP возвращает в AI-конвейер точки, где команда имеет право передумать, пока цена решения ещё мала.

Финал

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

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

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

Ценность создают те, кто быстро превращает код, который агент уже умеет писать, в изменение, за которое можно уверенно отвечать.

В своем телеграм-канале я каждую неделю покрываю подобные темы, а также пишу дайджесты с последними трендами в менеджменте и том, как меняются паттерны работы айти-команд.