Проблемы и особенности Spec-Driven Development при разработке ПО

Spec-Driven Development (SDD) — подход к разработке программного обеспечения, в котором центральным артефактом становится не исходный код, а спецификация, описывающая замысел и требования к системе. Такой подход особенно важен в эпоху ИИ-агентов, когда написание и изменение кода становится значительно более быстрым, а основным ограничением становится качество постановки задачи и сохранение контекста проекта.

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

Для ИТ-руководителя SDD интересен не столько как новый способ документирования требований, сколько как изменение самой модели разработки. Спецификация превращается в управляемый источник контекста, на основании которого ИИ-агенты планируют работу, создают код, проводят проверки и предлагают изменения.

Что такое SDD

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

Предыстория

Традиционно разработка программного обеспечения строилась вокруг последовательности «требования → проектирование → код → тестирование». Спецификация фиксировала, что должна делать система, после чего основное внимание команды постепенно перемещалось на архитектуру и программный код. На практике документ с требованиями после нескольких итераций нередко начинал отставать от реального состояния продукта.

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

Чем дешевле становится генерация кода, тем выше относительная ценность качественной спецификации.

Суть подхода

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

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

Таким образом, SDD представляет собой не просто «разработку через техническое задание», а управляемый цикл преобразования намерения в работающую систему. Спецификация фиксирует намерение, а инструменты разработки превращают его в конкретную реализацию.

Расшифровка

SDD расшифровывается как Spec-Driven Development — «разработка, управляемая спецификацией» или «разработка на основе спецификации». Термин используется для обозначения подходов, в которых спецификация определяет содержание и направление разработки, а программный код является производным результатом.

В современном контексте SDD тесно связан с ИИ-агентами. Например, GitHub Spec Kit описывает SDD как процесс, в котором сначала определяется, что необходимо построить, затем формируются план и задачи, после чего агент выполняет реализацию.

Простыми словами

Если упростить, SDD можно представить как правило: «сначала договоримся о том, что должно получиться, и только потом поручим машине это реализовать».

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

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

Спецификация как единая версия правды

В SDD спецификация приобретает статус единой версии правды — Single Source of Truth для разработки. Это особенно важно в проектах с несколькими командами и ИИ-агентами, где информация о требованиях может одновременно находиться в задачах, чатах, документации, исходном коде и результатах обсуждений.

Главный артефакт проекта

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

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

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

Постоянно уточняется ИИ-агентами

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

Спецификация становится не архивом требований, а живым контекстом проекта, который постоянно уточняется по мере накопления знаний о системе.

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

Смещение фокуса с кода на спецификацию

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

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

Именно здесь SDD связывается с концепцией AI SDLC. В ней можно выделить петлю намерений (Intent Loop), где формируется и уточняется то, что должна делать система, и петлю реализации (Implementation Loop), где это намерение превращается в конкретный программный результат. Спецификация связывает обе петли: в первой она формируется и уточняется, во второй становится контекстом для работы ИИ-агентов.

В AI SDLC человек в первую очередь управляет намерением, а ИИ-агент — его реализацией. Поэтому ценность перемещается от ручного написания кода к формированию качественной, непротиворечивой и актуальной спецификации.

Изменение спецификации и понятие дельты

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

Новая задача заворачивается в дельта-спецификацию

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

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

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

Далее согласуется только дельта, а не вся спека

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

Согласовывать нужно не всю систему заново, а только изменение относительно уже принятого состояния.

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

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

Фреймворки SDD

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

OpenSpec

OpenSpec — фреймворк SDD для ИИ-кодинг-ассистентов, ориентированный на согласование замысла между человеком и агентом до начала реализации. В его модели изменение оформляется через структурированный набор артефактов: предложение, спецификации, технический дизайн и задачи. Это позволяет отделить обсуждение изменения от его непосредственной реализации.

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

GitHub Spec Kit

GitHub Spec Kit — открытый инструментарий для организации SDD-процесса с ИИ-кодинг-агентами. Базовая последовательность включает формирование спецификации, планирование, декомпозицию на задачи и реализацию. Инструментарий также предусматривает расширение процесса и интеграцию с различными агентами.

Tessl Spec-Driven Development

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

Kiro

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

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