Почему команды отказываются от подхода «сначала код, потом исправления», когда ИИ ускоряет поставку сверх всякого контроля? Spec-Driven Development (разработка на основе спецификаций) представляет шестиэтапную модель, которая переносит архитектурные решения, ограничения и ясность на более ранние стадии (upstream). Узнайте, как это улучшает качество выходного результата, сокращает циклы очистки кода и позволяет AI-агентам работать согласованно в рамках мультисервисных систем.

Поставка программного обеспечения была ориентирована на реализацию большую часть своего существования: команды открывали редактор, пробегали глазами бриф спринта и начинали писать код. Этот рабочий процесс имел смысл, когда основными создателями были люди, репозитории развивались медленно, а конвейеры релизов были линейными и предсказуемыми. Теперь AI-агенты, такие как Copilot, Cursor и Windsurf, генерируют код быстрее, чем успевают реагировать архитектура, управление (governance) и интеграция. Код перескакивает от бэкенд-логики к конфигурациям инфраструктуры и CI/CD за часы, на что раньше уходили месяцы.

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

Модель, ориентированная на спецификации (spec-first), обращает этот коллапс вспять с помощью живых, исполняемых артефактов. Вместо того чтобы код вел процесс, спецификации становятся якорем (и источником), на основе которого действуют ИИ и люди. Они содержат решения о структуре, библиотеках, паттернах, соответствии требованиям и интеграции еще до того, как будет сгенерирована хоть одна функция.

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

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

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

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

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

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

2. Слепые зоны репозитория и стека, так как они не знают вашей архитектуры, соглашений или технического долга, пока вы их не смоделируете.

3. Слепота контекста функции, поскольку они не могут вывести контракты API, зависимости или граничные случаи только из промпта.

4. Неограниченная автономия, ведущая к неконтролируемым отклонениям без контрольных точек.

Таким образом, команды могут перенести проектирование, принятие решений и защитные ограждения на более ранние этапы, продвигая код вниз по потоку для разработки по принципу «безопасность по дизайну» (security by design), с меньшим техническим долгом, меньшим количеством сломанных интерфейсов и значительно меньшим объемом переделок в командах.

Поскольку этот сдвиг все еще созревает, появляются различные подходы: Kiro IDE, BMAD, GitHub Spec Kit и другие. Каждый из них отражает свою интерпретацию модели. В нашем случае Spec Kit подошел наиболее естественно, так как мы уже работали внутри VS Code с GitHub Copilot. Поддержка Microsoft вселила уверенность, и мы хотели проверить модель с помощью быстрых прототипов, а не долгих сравнений. Это сработало хорошо с самого начала, поэтому мы продолжили развивать это направление.

Для формального контекста документация GitHub на github.com/github/spec-kit и статья den.dev/blog/github-spec-kit являются надежной отправной точкой, но то, что следует далее в этом блоге, основано на реальном внедрении спецификаций для создания продуктов.

Структурные ограничения разработки с помощью ИИ - и как Spec Kit им противостоит

1. Ограничения объема и продолжительности задач

LLM (большие языковые модели) отлично справляются с небольшими, четко ограниченными задачами. Попросите написать вспомогательную функцию, отрефакторить один класс или написать модульные тесты для одного модуля, и результаты обычно будут четкими и правильными. Но как только объем расширяется до многочасовой работы - обновления конечных точек API или исправления ошибок, затрагивающих несколько компонентов, - качество быстро падает. Чем дольше окно автономного выполнения, тем выше вероятность получить код, который компилируется, но на самом деле не решает вашу проблему правильно.

Проблема усугубляется, когда объем раздувается. Объем важнее продолжительности. LLM может модифицировать 1–3 файла с высоким качеством. Увеличьте это число до 10+ файлов, и согласованность нарушится. Чем больше файлов затрагивает один запрос, тем больше рефакторинга вам придется делать впоследствии. Это вопрос не лучших промптов, а фундаментального ограничения того, как эти модели поддерживают согласованность в больших наборах изменений.

Решение Spec Kit: Принудительная декомпозиция

Spec-Driven Development заменяет подход к кодированию «большого взрыва» на конвейер декомпозиции: Фича → Пользовательские истории → Задачи → Итеративная реализация.

Вместо того чтобы продвигать всю фичу через 20–30 файлов за один ошеломляющий проход, фича сначала переводится в пользовательские истории, затем в атомарные задачи с жестко ограниченной ответственностью. Только после этого начинается реализация, где каждая задача выполняется с ограниченным объемом, обычно затрагивая 1–2 файла и занимая минуты, а не часы. Сложность не исчезла, но она была преобразована в серию управляемых фрагментов с четкими границами.

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

2. Пробелы в контексте функции

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

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

Решение Spec Kit: Многоуровневая система контекста для сквозной (end-to-end) разработки фич

Спецификации смещают контекст от ситуативных промптов к структурированным слоям, на которые ассистент может полагаться:

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

• Слой спецификации: Создается через этапы «specify» и «clarify» в Spec Kit. Он определяет функциональный объем, такой как бизнес-требования, критерии приемки и граничные случаи, а также определяет сценарии использования, успех и возможности фичи.

Вместе эти слои дают ассистенту обзор на 360 градусов перед началом выполнения: что нужно построить, как работает проект и стратегию его доставки. В отличие от промптов, которые исчезают после выполнения, эти артефакты создают постоянный чертеж, который предотвращает дрейф (drift), обеспечивает согласованность и позволяет новой работе чисто интегрироваться в существующую систему.

3. Пробелы в знаниях о проекте

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

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

Решение Spec Kit: Слой конституции

Файл constitution.md - это способ Spec Kit закрыть пробел в стандартах, который обнажает ИИ. Он становится постоянным централизованным слоем намерений того, как ваша команда строит, а не того, как LLM предполагает, что программное обеспечение должно выглядеть. Вместо того чтобы полагаться на племенные знания и исправления при ревью кода, вы даете ассистенту те же указания, что и старшему сотруднику в первый день работы. Он определяет:

• Стек и стандарты: Фреймворки, версии, паттерны реализации. Примеры включают React 18.2, TypeScript 5.1 и Vite.

• Правила именования: Файлы, модули, сервисы, переменные, функции. Например, компоненты React используют PascalCase для файлов. Утилитарные функции используют экспорт в camelCase.

• Архитектурное намерение: Обоснование прошлых решений, предпочтительные подходы. Например: Бизнес-логика живет в слое /services, никогда в компонентах React. Вызовы API идут через обертку /api/client. Управление состоянием использует Zustand, а не Redux или Context.

• Управление библиотеками: Разрешенные импорты, запрещенные зависимости, критерии одобрения.

• Безопасность и соответствие требованиям: Потоки аутентификации, обработка данных, требования к аудиту.

Это не общий шаблон (boilerplate), а специфичные для проекта знания, которые обычно всплывают через комментарии при ревью кода, ветки в Slack и прошлые PR. LLM читает эту конституцию перед тем, как что-либо реализовывать, получая понимание ВАШИХ стандартов, а не общих лучших практик из обучающих данных.

4. Неконтролируемая автономия агентного «черного ящика»

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

Решение Spec Kit: Обязательные шлюзы проверки (Review Gates)

Конвейеры Spec-driven структурируют автоматизацию вокруг контрольных точек, требующих одобрения человека на нужной глубине. Эти точки останова возвращают контроль (supervision), не замедляя выполнение на таких этапах, как:

• Проверка спецификации (Specification review): Ассистент генерирует спецификацию фичи из вашего описания. Команды просматривают ее, чтобы удалить галлюцинации, исправить неверные интерпретации и прояснить двусмысленности. Поскольку человеческое намерение редко идеально сформулировано с первого раза, этот этап предотвращает дрейф на более поздних стадиях.

• Проверка плана (Plan review): Технический подход проверяется до генерации кода. Вы валидируете архитектуру, пути интеграции и альтернативы, чтобы ошибки не запекались в реализацию.

• Одобрение выполнения (Execution approval): Как только спецификация, план и декомпозиция задач подтверждены, ассистент получает разрешение на автономную реализацию.

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

TL;DR

Как выглядит рабочий процесс Spec-Driven на практике

Spec-Driven Development - это не просто «написание документа перед кодированием». Это структурированная модель выполнения, которая гарантирует, что ИИ, разработчики и системы работают на основе одной единой спецификации до того, как изменится хоть один файл. На практике рабочий процесс разворачивается через шесть предсказуемых этапов:

Constitution → Specify → Clarify → Plan → Tasks → Implement

1. Этап Constitution (Конституция) кодирует ДНК вашего проекта, документируя версии стека, соглашения об именовании, принципы слоев и архитектуры, разрешенные/запрещенные библиотеки, а также аутентификацию/логирование/доступность. Это предотвращает генерацию ассистентом «общего» кода и заставляет его соответствовать тому, как на самом деле работает ваша система.

2. Этап Specification (Спецификация) фиксирует функциональные и нефункциональные намерения, определяя требования, граничные случаи, зависимости API, а также требования к доступности и производительности.

3. Этап Clarify (Уточнение) устраняет двусмысленность, возникающую из-за нечетких требований и объема. Он проверяет наличие пропущенных ограничений или предположений, конфликтующих требований и того, следует ли подтвердить или исключить граничные случаи.

4. Этап Planning (Планирование) затем отображает спецификацию на реальную архитектуру системы, определяя, какие сервисы, модули, потоки данных, логика состояния и хуки наблюдаемости будут затронуты. Это предотвращает изобретение ассистентом новых структур или угадывание паттернов интеграции, которых нет в вашем стеке.

5. В рамках Tasks (Задач) декомпозиция нарезает реализацию на атомарные, проверяемые единицы с границами, не превышающими несколько файлов на задачу. Это останавливает ИИ от действий в масштабе всей фичи, которые нарушают связность, загрязняют зависимости или вынуждают проводить масштабный рефакторинг.

6. Этап Implement (Реализация) гарантирует, что генерация кода происходит в рамках ограничений, определенных конституцией, спецификацией и планом, поэтому ассистент выдает что-то структурно правильное с самого начала. Вместо переписывания плохого кода команды оттачивают оставшиеся 20–40% для точности, интеграции и полировки.

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

Почему модель доставки spec-first может стать трансформационной для инженерии

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

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

• Разработка сдвигается влево (Shift left): Команды тратят больше времени на ранних этапах (upstream) на системный дизайн, определение объема, архитектуру и планирование, и меньше на набор кода. Важная работа происходит до реализации, а не во время нее.

• Роль разработчика эволюционирует в архитекторов: Разработчики переходят от написания кода к проектированию систем и валидации реализаций. Ревью кода начинает фокусироваться на архитектуре и соответствии спецификациям, а не на синтаксисе и стиле.

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

• Интеграция с SDLC (Software Development Life Cycle) изменится: Спецификации становятся первоклассными артефактами, которые можно версионировать, тестировать и проверять. CI/CD может валидировать спецификации перед генерацией кода, а документация остается точной, потому что она делит один и тот же источник.

• Кривая затрат изменится, что перестроит глобальную доставку: Традиционная разработка наказывает за позднее обнаружение ошибок. Доставка, управляемая спецификациями, сократит этот цикл. Вы можете пересматривать и валидировать быстрее и генерировать реализации по запросу, снижая стоимость итерации и уменьшая риск ошибки на раннем этапе.

Команды, которые будут процветать с разработкой, ориентированной на спецификации

Spec-Driven Development оказывает наибольшее влияние на:

• Команды, использующие инструменты на базе ИИ (AI-native), такие как Copilot, Cursor, Windsurf, Claude Code или Gemini CLI, которым нужны структурированные намерения для получения надежного, не галлюцинирующего результата от AI-агентов.

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

• Корпоративные и существующие (brownfield) проекты с устаревшими системами, ограничениями соответствия или кодовыми базами смешанных эпох, где внедрение стандартов и управления задним числом после реализации замедляет доставку и увеличивает риски.

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

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

Установка реалистичных ожиданий ⚠️

Прежде чем мы станем чрезмерно оптимистичными, важно понять, чем является Spec Kit, а чем нет:

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

• Spec Kit все еще на ранней стадии: В версии 0.0.72 он развивается публично. Форматы файлов, рабочие процессы и интеграции с ассистентами будут меняться. Любой, кто принимает его сейчас, подписывается на итерации, а не на окончательность.

• Автоматизация - это не замена: Если 60–80% сгенерированного кода пригодно для использования после ревью - это победа. Вы все равно будете уточнять граничные случаи, исправлять логику, выравнивать паттерны и подтягивать детали реализации.

• Соответствие объему имеет значение: Spec Kit в настоящее время лучше всего работает для сквозных (end-to-end) или автономных сборок фич, особенно в контексте brownfield. Он менее эффективен для разрозненных рефакторингов, инкрементальных правок или узких исправлений в нескольких потоках.

• Ценность - в структуре, а не в магии: Spec Kit делает ИИ предсказуемым, принуждая к ясности заранее, а не удаляя инженеров из цикла.

Что дальше?

С этим курсом вы теперь понимаете намерение, механику и долгосрочные последствия модели spec-first. Следующий материал будет посвящен реализации в реальном мире: как наложить спецификации на живое приложение средней сложности (brownfield), которое находится в продакшене более года. Мы экспериментировали и пытались использовать Spec Kit в нашем SDLC, прогнали несколько реализаций фич через этот рабочий процесс и узнали, что работает, а что нет. Оставайтесь с нами!

UPD: Попробовал OpenSpec - мне ближе.