Опрос Sonar за 2026 год показывает, что 88% разработчиков считают, что генерируемый ИИ код увеличивает технический долг, а сторонники разработки на основе спецификаций (spec-driven development) утверждают, что дисциплинированный этап составления спецификаций может остановить этот процесс.
Почему это важно
Когда человек получает расплывчатую задачу (ticket), он задает уточняющие вопросы. ИИ-агент, напротив, заполняет пробелы на основе своих предположений и выдает код, который выглядит правдоподобно. Иллюзия корректности обходится дорого: тот же опрос Sonar сообщает, что более половины респондентов сталкивались с кодом, который проходит базовые проверки, но скрывает в себе трудноуловимые дефекты. Эти дефекты накапливаются в виде технического долга, вынуждая проводить рефакторинг в будущем, замедляя выпуск новых функций и раздувая бюджеты на поддержку.
Как выглядит разработка на основе спецификаций
Разработка на основе спецификаций (Spec-driven development, SDD) меняет привычный порядок действий. Вместо того чтобы давать ИИ-модели краткую пользовательскую историю (user story), команда пишет подробную, исполняемую агентом спецификацию, которая хранится в той же системе контроля версий, что и код. Спецификация становится единым источником истины — она фиксирует намерения, граничные случаи, ожидания по производительности и любые ограничения, которые ИИ-модель обязана соблюдать.
Этот процесс не заменяет работу человека по проектированию, а кодифицирует её. Перенося решения из памяти разработчика в конкретный документ, мы позволяем и людям, и будущим ИИ-агентам проследить, почему тот или иной фрагмент кода ведет себя именно так. Составление спецификации требует усилий на начальном этапе, но отладка неоднозначных результатов работы ИИ обходится гораздо дороже в дальнейшем.
Изменение рабочего процесса
Бэклог продукта — делайте задачи краткими, фиксируя только суть и высокоуровневые критерии приемки. Этот список по-прежнему служит основой для приоритизации.
Планирование спринта — команды обсуждают общую цель и согласовывают цель спринта (Sprint Goal), но откладывают детальную реализацию до момента готовности спецификации.
Во время спринта — исполнитель задачи пишет точную, машиночитаемую спецификацию. В ней указываются форматы входных данных, ожидаемые результаты, обработка ошибок и любые нефункциональные требования. Поскольку спецификация находится под контролем версий, рецензенты могут оставлять комментарии, предлагать правки и одобрять изменения так же, как и в случае с кодом.
Definition of Done — добавьте пункт «Спецификация рассмотрена и утверждена» в критерии качества (quality gate). Код не считается завершенным, пока спецификация не пройдет те же стандарты проверки, что и сама реализация.
Адаптация Kanban — добавьте две новые колонки: «Spec Drafted» (Спецификация подготовлена) и «Spec Approved» (Спецификация утверждена). Теперь рабочие элементы проходят путь: backlog → Sprint Goal → Spec Drafted → Spec Approved → In Progress → Done. Это визуальное изменение делает ранее невидимый этап координации явным.
Инструменты, которые уже внедряют использование спецификаций
Такие платформы, как GitHub Spec Kit и AWS Kiro, уже добавили контрольные точки, требующие наличия документа с требованиями перед началом любой генерации кода с помощью ИИ. Они не заменяют ИИ-модель, а приводят буквально воспринимающих всё агентов в соответствие с намерениями человека. Делая спецификацию обязательным условием, эти инструменты автоматизируют переход, не нарушая существующие CI/CD-конвейеры.
Возможные возражения
Критики утверждают, что написание спецификации создает трение в и без того быстром темпе Agile. Контраргумент заключается в том, что время, затраченное на составление спецификации, обычно составляет лишь малую часть того времени, которое позже потребуется на отладку кода, созданного ИИ на основе неоднозначного промпта.
Еще одно опасение — спецификации могут устареть по мере изменения требований. Интеграция с системой контроля версий решает эту проблему: любое изменение в спецификации создает новый коммит, инициирует проверку и заставляет команду пересмотреть связанный с ней код. На практике отношение к спецификациям как к коду позволяет поддерживать документацию в актуальном состоянии.
За чем следить дальше
Внедрение этой практики находится на ранней стадии, но динамика очевидна. По мере того как возможности генераторов кода на базе ИИ будут расти, потребность в точной, машиночитаемой формулировке намерений будет только увеличиваться.
Итог: Превращение расплывчатых промптов в конкретные, проверенные спецификации может показаться лишним шагом, но это превращает догадки в обоснованные и ответственные решения.