Кратко: выпуск подкаста «Подлодка» о Spec Driven Development. Участники обсуждают, зачем нужен SDD, как устроены спецификации разных уровней, какие процессы помогают работать с LLM-агентами и какие мифы мешают внедрению подхода.
Ведущие: Егор Толстой, Станислав Цыганов
Гость: Алексей Верховский — автор BMOD, одного из популярных SDD-фреймворков
Основы SDD
Spec Driven Development — набор инженерных практик, которые помогают получать более предсказуемый результат от LLM-агентов.
Суть подхода:
- сначала в отдельной сессии подготовить компактную спецификацию примерно на 1000 слов
- затем передать её кодинг-агенту в новой чистой сессии.
Проблема контекстного окна
Формально современные модели поддерживают контекст на 1 млн токенов и больше. На практике полезный контекст обычно ограничен примерно 100–150 тыс. токенов и растёт медленнее, чем заявленные лимиты.
После 200 тыс. токенов качество работы модели может заметно снижаться. После 350–500 тыс. токенов модель чаще начинает ухудшать результат, а не улучшать его.
Одна из причин — lost in the middle syndrome: модель хуже удерживает информацию из середины длинного контекста, а затем начинает терять и ранние детали. Кроме того, LLM не всегда понимают, какая информация критична, поэтому автоматическое сжатие контекста может удалить важные детали.
Идеальная рабочая сессия
Лучший сценарий для агента: чистая сессия, чёткая задача и короткий, плотный контекст. В таком режиме агенту проще удерживать цель, ограничения и критерии результата.
SDD не равен Spec-as-Source
Спецификация как входной контекст работает хорошо. Но спецификация как единственный источник истины, из которого автоматически перегенерируется код, пока остаётся ненадёжным подходом.
Уровни и содержание спецификаций
В выпуске выделяют три уровня спецификаций.
Story
Небольшая задача на 100–300 строк кода. Обычно такая спека занимает около 1500 токенов и предназначена для кодинг-агента.
Epic
Группа из 5–10 stories. Такая спецификация занимает несколько страниц и нужна планирующему агенту и человеку.
Project
Высокоуровневое описание проекта: 20–30 ключевых идей, которые помогают сориентировать работу и связать отдельные эпики.
Что должно быть в story-спеке
- Intent — краткое описание намерения, до 300 токенов.
- Input/Output Matrix — таблица правил и граничных случаев.
- Acceptance Criteria — критерии приёмки, которые не сводятся только к входам и выходам.
- Non-goals / Scope exclusion — что не входит в задачу.
- Ссылки на код — конкретные файлы, модули или фрагменты.
- Архитектурный минимум — простая схема: основные блоки и связи между ними.
Что не стоит писать в спецификации
Не нужно подробно описывать архитектурные детали, которые агент может вывести сам. Также не стоит включать пошаговую инструкцию по реализации и случайные нефункциональные требования, если они не влияют на результат.
Практика и процесс SDD
Когда SDD полезен
Для тривиальных задач достаточно quick fix без отдельной спеки. Чем хуже задача помещается в одну рабочую сессию, тем выше ценность SDD.
Четыре стадии работы над story
- Intent Discovery — понять, чего хочет человек.
- Context Gathering — исследовать код и окружение задачи.
- Planning — спланировать изменения.
- Coding — реализовать решение.
Tracer Bullet
Первые 1–2 story в эпике стоит провести через все слои системы: интерфейс, бизнес-логику и хранение данных. Это помогает проверить архитектурный маршрут. После этого остальные story можно выполнять более автономно.
Экономика подхода
По оценке участников, Claude и Codex могут стоить около 100 долларов в месяц. При этом стоимость токенов составляет примерно 20–30% от зарплаты разработчика. Поэтому SDD может быть экономически оправдан, если снижает количество переделок и хаотичных итераций.
Выводы, мифы, тезисы
Миф: SDD слишком медленный
Для простых задач отдельная спека действительно может быть лишней. Но в сложных задачах SDD часто быстрее хаотичной работы без структуры.
Миф: спецификации должны быть идеальными с первого раза
SDD предполагает итеративную работу. Спеку можно уточнять по мере discovery и проверки контекста.
Миф: SDD убивает креативность
На практике подход освобождает время для архитектурных решений, потому что снижает шум в реализации.
Миф: нужны специальные инструменты
BMOD — один из популярных инструментов, но сам подход можно применять и без него.
Главный вывод
SDD — не универсальное решение для всех задач. Это набор практик для конкретной проблемы: LLM плохо работают с большим, разнородным и плохо структурированным контекстом. Хорошая спека помогает сузить контекст, зафиксировать намерение и повысить предсказуемость результата.
Takeaways
- Полезный контекст моделей растёт медленнее, чем заявленные размеры context window.
- SDD помогает управлять контекстом и снижать потери важной информации.
- Story-спека должна включать intent, input/output matrix, acceptance criteria и non-goals.
- Tracer Bullet помогает проверить весь путь реализации через ключевые слои системы.
- Вместо большого PRD часто достаточно 20–30 guiding thoughts на уровне проекта.
- Спеки не обязаны быть «вечнозелёными»: после выполнения задачи их можно архивировать.
- SDD не равен Spec-as-Source: код и комментарии остаются более богатым источником контекста.
- BMOD полезен, но SDD можно применять без специального фреймворка.
- Комментарии в коде стали полезнее: LLM могут поддерживать их актуальность лучше, чем прежние инструменты.
