Метод
Как работает SDD
От каскадной модели к спецификационно-управляемому ИИ — полный технический разбор.
Эволюция
Как эволюционировала разработка ПО
Четыре эпохи создания программного обеспечения — от жёстких каскадов до ИИ-агентов, управляемых спецификацией.
Waterfall
Последовательные фазы: требования, проектирование, реализация, тестирование, развёртывание. Каждая фаза завершается до начала следующей. Изменения дороги; циклы обратной связи измеряются месяцами.
Предсказуемо, но медленно. Запрос на изменение после фазы проектирования мог обнулить всю временную шкалу.
Agile
Итеративные спринты, пользовательские истории, ежедневные встречи, ретроспективы. Команды поставляют инкрементально и адаптируются к изменениям. Но скорость по-прежнему ограничена размером команды и накладными расходами на координацию.
Более быстрая обратная связь, но масштабирование требует больше людей — а больше людей требуют больше координации.
AI-Assisted
Автодополнение кода, ИИ-копилоты, генерация кода через чат. Отдельные разработчики становятся быстрее, но сам процесс разработки не меняется. ИИ помогает; люди по-прежнему выполняют работу.
Рост продуктивности на 20–40% на разработчика — но процесс, роли и узкие места остаются прежними.
SDD
Спецификация становится исполняемым контрактом. ИИ-агенты реализуют, тестируют, документируют и развёртывают — оркестрируемые senior-инженером, который контролирует весь жизненный цикл через формальные спецификации.
Не более быстрые разработчики — принципиально другой процесс. Один инженер, спецификация прежде всего, исполнение силами ИИ. Ключевая концепция
Что такое Specification-Driven Development?
Методология, где спецификация — источник истины, а ИИ-агенты — рабочая сила.
Specification-Driven Development (SDD) — методология, при которой каждая фича, сервис и интеграция начинается как формальная, машиночитаемая спецификация — до написания единой строки кода.
В отличие от традиционных подходов, где разработчики интерпретируют требования и принимают решения по реализации на ходу, SDD выносит все архитектурные и бизнес-решения в спецификацию. Спецификация — это не документация, это источник истины, по которому ИИ-агенты выполняют работу.
Результат: предсказуемый выход, стабильное качество и скорость разработки, которая масштабируется глубиной спецификации — а не размером команды.
Спецификация — это код
Каждая фича начинается как формальная спецификация: API-контракты, модели данных, бизнес-правила, критерии приёмки. Спецификация достаточно точна, чтобы ИИ-агенты реализовали без неоднозначностей.
Агенты выполняют работу
ИИ-агенты занимаются реализацией, тестированием, документированием, настройкой CI/CD и локализацией. Каждый агент работает в рамках определённой роли и строгих границ контекста.
Человек сохраняет контроль
Senior-инженер пишет спецификации, проверяет весь результат, принимает архитектурные решения и валидирует качество. ИИ усиливает экспертизу — не заменяет суждение.
Архитектура
Три уровня контекста
Каждый ИИ-агент работает в строгой иерархии контекста, обеспечивающей консистентность и качество.
Системный контекст
Архитектурные правила, ограничения технологического стека, стандарты кодирования, соглашения об именовании и инварианты проекта. Этот контекст загружается в каждую сессию агента и никогда не меняется в ходе проекта.
Пример: "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
Семь шагов от спецификации до продакшена — с человеческими контрольными точками на каждом критическом этапе.
Написать системную спецификацию
Определить архитектуру, технологический стек, стандарты кодирования, API-конвенции и правила проекта. Это становится неизменяемым системным контекстом для всех агентов.
Определить требования к фиче
Для каждой фичи: API-контракты, модели данных, бизнес-правила, критерии приёмки и ожидания тестов. Спецификация должна быть достаточно точной для однозначной реализации.
Ревью человеком: спецификация
Инженер проверяет спецификацию на полноту, консистентность и архитектурную надёжность. Это самая критическая контрольная точка — ошибки здесь распространяются повсюду.
ИИ-агенты реализуют
Агенты исполняют спецификацию: пишут код, создают тесты, генерируют документацию, настраивают CI/CD. Каждый агент работает в рамках своей роли и границ контекста.
Автоматическая валидация
Весь сгенерированный код автоматически компилируется, тестируется и анализируется. Покрытие тестами, типобезопасность и стандарты кодирования обеспечиваются CI-пайплайнами — не людьми.
Ревью человеком: результат
Инженер проверяет сгенерированный код на корректность, граничные случаи, безопасность и готовность к продакшену. Результат работы ИИ никогда не развёртывается без валидации человеком.
Развёртывание в продакшен
Одобренный код мёржится, пайплайны запускаются, система развёртывается. Полная прослеживаемость от спецификации до коммита и развёртывания.
Готовы начать?
Создадим реальный продукт
Сначала NDA. Затем чёткое ТЗ, фиксированная цена и работающая система — за недели, а не месяцы.