Как работает SDD
От каскадной модели к выполнению задач ИИ-агентами по спецификации — полный технический разбор.
Эволюция
Как менялась разработка ПО
Четыре эпохи создания программного обеспечения — от жёсткой каскадной модели до ИИ-агентов, работающих по спецификации.
Waterfall
Последовательные этапы: требования, проектирование, реализация, тестирование, развёртывание. Каждый этап завершается до начала следующего. Изменения обходятся дорого, а обратная связь приходит через месяцы.
Предсказуемо, но медленно. Запрос на изменение после этапа проектирования мог перечеркнуть весь график.
Agile
Итеративные спринты, пользовательские истории, ежедневные планёрки, ретроспективы. Команды выпускают продукт по частям и подстраиваются под изменения. Но скорость по-прежнему ограничена размером команды и накладными расходами на координацию.
Обратная связь быстрее, но для масштабирования нужно больше людей, а чем больше людей, тем больше координации.
AI-Assisted
Автодополнение кода, ИИ-помощники, генерация кода в чате. Отдельные разработчики работают быстрее, но сам процесс разработки не меняется. ИИ помогает, а работу по-прежнему выполняют люди.
Производительность каждого разработчика растёт на 20–40%, но процесс, роли и узкие места остаются прежними.
SDD
Спецификация становится исполняемым контрактом. ИИ-агенты реализуют, тестируют, документируют и развёртывают систему под управлением ведущего инженера, который контролирует весь жизненный цикл с помощью формальных спецификаций.
Не ускорение разработчиков, а принципиально иной процесс. Один инженер, сначала спецификация, исполнение — за ИИ. Ключевая концепция
Что такое Specification-Driven Development?
Методология, в которой спецификация — источник истины, а ИИ-агенты — исполнители.
Specification-Driven Development (SDD) — методология, при которой любая функция, сервис или интеграция начинается с формальной машиночитаемой спецификации ещё до написания кода.
В отличие от традиционных подходов, где разработчики толкуют требования и принимают решения о реализации на ходу, SDD заранее закладывает в спецификацию все архитектурные и бизнес-решения. Спецификация — не документация, а первоисточник, по которому работают ИИ-агенты.
Итог: предсказуемый результат, стабильное качество и скорость разработки, которая растёт вместе с глубиной проработки спецификации, а не с численностью команды.
Спецификация — это код
Каждая функция начинается с формальной спецификации: контракты API, модели данных, бизнес-правила, критерии приёмки. Спецификация настолько точна, что ИИ-агенты реализуют её без разночтений.
Агенты выполняют работу
ИИ-агенты занимаются реализацией, тестированием, документированием, настройкой CI/CD и локализацией. Каждый агент работает в рамках определённой роли и строгих границ контекста.
Человек сохраняет контроль
Ведущий инженер пишет спецификации, проверяет все результаты, принимает архитектурные решения и контролирует качество. ИИ усиливает экспертизу, но не заменяет суждения человека.
Архитектура
Три уровня контекста
Каждый ИИ-агент работает в строгой иерархии контекста, которая обеспечивает согласованность и качество.
Системный контекст
Архитектурные правила, ограничения технологического стека, стандарты программирования, соглашения об именовании и общие инварианты проекта. Этот контекст загружается в каждую сессию агента и не меняется до конца проекта.
Пример: «Java 21, Spring Boot 3.2, PostgreSQL. Все сервисы построены по гексагональной архитектуре. REST API соответствуют спецификации OpenAPI 3.1. Без ORM — чистый SQL через jOOQ».
Контекст функции
Требования, критерии приёмки, контракты API, модели данных и бизнес-правила конкретной функции. Этот контекст ограничен текущей задачей и определяет, что именно должен создать агент.
Пример: «Сервис выдачи свидетельств: POST /api/v1/certificates. Проверяет вместимость склада и дубликаты серийных номеров, публикует доменное событие CertificateIssued».
Контекст исполнения
Текущий файл, область видимости функции, ожидаемые результаты тестов и непосредственные зависимости. Это самый узкий слой контекста: он точно указывает агенту, где тот находится и что нужно сделать дальше.
Пример: «Реализовать метод CertificateService.issue(). Вход: IssueCertificateCommand. Выход: CertificateDTO. Должен пройти тесты CertificateServiceTest, строки 45–78».
Жизненный цикл
Жизненный цикл SDD
Семь шагов от спецификации до промышленной эксплуатации — с проверкой человеком на каждом критическом этапе.
- 01
Написать системную спецификацию
Определить архитектуру, технологический стек, стандарты программирования, соглашения об API и общие правила проекта. Так формируется неизменный системный контекст для всех агентов.
- 02
Определить требования к функциям
Для каждой функции: контракты API, модели данных, бизнес-правила, критерии приёмки и ожидаемые результаты тестов. Спецификация должна быть достаточно точной, чтобы исключить разночтения при реализации.
- 03
Проверка человеком: спецификация
Инженер проверяет спецификацию на полноту, непротиворечивость и архитектурную обоснованность. Это важнейшая контрольная точка: ошибки на этом этапе распространяются на всю систему.
- 04
ИИ-агенты реализуют
Агенты исполняют спецификацию: пишут код, создают тесты, генерируют документацию, настраивают CI/CD. Каждый агент работает в рамках своей роли и границ контекста.
- 05
Автоматическая проверка
Весь сгенерированный код автоматически компилируется, тестируется и проходит статический анализ. Покрытие тестами, типобезопасность и стандарты программирования обеспечивают конвейеры CI, а не люди.
- 06
Проверка человеком: результат
Инженер проверяет сгенерированный код на корректность, граничные случаи, безопасность и готовность к промышленной эксплуатации. Результат работы ИИ никогда не развёртывается без проверки человеком.
- 07
Развёртывание в рабочей среде
Одобренный код вливается в основную ветку, запускаются конвейеры, система развёртывается. Полная прослеживаемость: от спецификации к коммиту и развёртыванию.
Ваша спецификация, фиксированная цена, работающая система.
- 01 Подписываем NDA До обсуждения любых деталей. Ваша идея защищена.
- 02 Ознакомительный звонок · 30 мин Только ведущий инженер — без менеджеров по продажам и посредников.
- 03 Письменная смета · 24 часа Фиксированные объём работ и цена либо оплата по факту (T&M) — на ваш выбор.
- 04 Начало работ в течение 48 часов Если мы подходим друг другу, можем начать сразу.