Что такое SDD и как мы применяем его в работе

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

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

Что такое Spec-Driven Development

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

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

Условно процесс можно представить так:

• Замысел → Спецификация → План → Реализация → Проверка

Спецификация конкретной задачи и общий контекст проекта — разные вещи. Архитектурные принципы, правила написания кода, инструкции по работе с репозиторием, AGENTS.md или architecture.md могут использоваться во многих задачах. Спецификация описывает конкретное изменение.

Три уровня разработки на основе спецификаций

Это не обязательные последовательные уровни зрелости. Для многих команд уже подход spec-first дает достаточно контроля над работой ИИ-агентов.

Почему SDD стал особенно важен с появлением ИИ-агентов

Разработчики и раньше уточняли требования до реализации. ИИ просто сделал цену плохо поставленной задачи заметнее.

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

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

На ИИ-митапе Evrone «Где заканчивается вайбкодинг и начинается инженерная AI-разработка» один из спикеров разбирал SDD именно как процесс: задачу стоит проработать до начала работы с агентом, дать ему достаточный контекст и описание задачи, а не восстанавливать исходный замысел после того, как код уже написан.

Посмотреть запись AI-митапа Evrone на YouTube >>

SDD в этом смысле не учит ИИ программировать. Он помогает инженеру точнее управлять тем, что именно должно быть реализовано.

SDD vs Vibe Coding

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

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

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

Хорошая спецификация — это не большая спецификация

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

В зависимости от задачи спецификация  может содержать:

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

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

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

Как мы применяем Spec-Driven AI Development в Evrone

На практике разработка через спецификации помогает нам закрыть три типовые проблемы работы с ИИ-ассистентами.

Что происходит с задачей БЕЗ SDD?

Рассмотрим типичную постановку задачи в чате и проблемы, которые возникают из-за недостатка контекста.

• Пример: «Сделай мониторинг интеграций»

Задача в чате:

Нужно добавить экран мониторинга интеграционных потоков. Пользователи должны видеть ошибки и детали.

 

Что может сделать ИИ без дополнительных ограничений:

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

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

Как выглядит подход SDD на примере OpenSpec

SDD предлагает работать через структурированные артефакты. Один из инструментов для этого — OpenSpec. Он организует контекст через спецификации (specs/) и изменения (changes/).

Основные этапы:

• Proposal — описание изменения. Фиксируем, зачем нужна задача, что входит в ее объем и что остается за его пределами.
• Spec — спецификация. Описываем ожидаемое поведение системы через сценарии.
• Design — техническое решение. При необходимости фиксируем архитектуру реализации.
• Tasks — план работ. Разбиваем реализацию на конкретные шаги.

Структура изменений:

openspec/changes/monitoring-screen/

├── proposal.md        # Зачем нужен экран

├── design.md          # Как реализуем

├── tasks.md           # План работ

└── specs/

    └── monitoring/

        └── spec.md    # Как изменится поведение системы

Практические кейсы: ДО и ПОСЛЕ SDD

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

• Кейс 1. Мониторинг интеграций (Enterprise UI)

ЛАБ СП / Integration Gears
Платформа интеграционных потоков для бизнеса. Задача — создать единое окно мониторинга сотен и тысяч интеграций, чтобы служба поддержки могла быстро находить и диагностировать сбои. Изображения и UI-кит разрабатывались командой Evrone.

Контекст: система для поддержки сотен интеграционных потоков.

❌ ДО SDD: в чате

Нужно сделать список интеграций, чтобы видно было, где ошибка. Можно как таблицу сделать.

 

Проблемы для ИИ:

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

✅ ПОСЛЕ SDD: в спецификации

В файле specs/monitoring/spec.md фиксируем поведение через сценарии:

# Delta for Monitoring Center

## ADDED Requirements

### Requirement: Integration flow execution list

The system SHALL show recent integration flow executions with status,

timestamp, source system, target system, and error indicator.

#### Scenario: Support engineer filters failed executions

- GIVEN a support engineer is viewing the monitoring list

- WHEN the engineer filters by "Failed"

- THEN the system shows only failed executions

- AND each row displays the failing step if known

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

• Кейс 2. Сервис отчетов (внутренние инструменты)

Школа 21 / Сбер
Образовательная EdTech-платформа. Evrone разрабатывала сервисы для участников школы, включая отчеты, внутренних чат-ботов и сервис трудоустройства «Отклик». В проекте участвовали фронтенд-, бэкенд- и DevOps-специалисты.

Контекст: перенос генерации PDF с бэкенда на фронтенд.

❌ ДО SDD: в чате

Сделай генерацию отчетов в браузере, чтобы сервер не грузил

 

Проблемы для ИИ:

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

✅ ПОСЛЕ SDD: в спецификации

В proposal.md фиксируем границы задачи:

# Proposal: Move PDF generation to frontend

## Scope

In scope:

- Render PDF on frontend using data from backend

- Show loading state during generation

- Handle generation errors with user message

Out of scope:

- Changing backend data sources

- Adding PDF templates

- Real-time generation

Результат: агент понимает не только что нужно изменить, но и какие части системы трогать нельзя.

• Кейс 3. Логистика: система статусов

TRUCKER
Система автоматизации логистики для перевозчиков. Разработка функциональности для управления заказами, маршрутами и интеграциями с внешними сервисами.

Контекст: отслеживание статусов грузов.

❌ ДО SDD: в чате

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

 

Проблемы для ИИ:

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

✅ ПОСЛЕ SDD: в спецификации

# Delta for Shipments

## ADDED Requirements

### Requirement: Shipment status notifications

The system SHALL notify a dispatcher when a shipment enters

a status requiring attention.

#### Scenario: Duplicate event received

- GIVEN the same status event is received more than once

- WHEN the duplicate event is processed

- THEN the system SHALL NOT create duplicate notifications

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

Сводная таблица изменений

Хотите ускорить разработку с ИИ без потери инженерного контроля?

Где метод разработки через спецификации действительно полезен

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

Например, когда:

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

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

Рекомендация для команды

Начать можно с одной задачи:

• Выберите одну функцию.
• Зафиксируйте цель, объем и ограничения в proposal.md.
• Попросите ИИ подготовить spec.md на основе этого описания.
• Проверьте спецификацию и только после этого переходите к реализации задач из tasks.md.

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

SDD не отменяет Agile

Принцип «сначала спецификация» может напоминать Waterfall, но SDD не требует проектировать весь продукт заранее. Спецификация может описывать следующее небольшое значимое изменение внутри обычного итерационного процесса:

• Уточнить задачу → Зафиксировать замысел → Реализовать → Проверить → Получить обратную связь → Обновить контекст

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

SDD дополняет этот процесс там, где работа с ИИ требует более явного управления контекстом, требованиями и ограничениями.

Что меняется в роли разработчика

ИИ снижает стоимость механического написания кода, но не стоимость неправильного инженерного решения.

Поэтому большее значение приобретают:

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

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

Что получает клиент

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

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

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