Содержание

В эпоху, когда код пишет ИИ, более ценный навык смещается от «писать код» к «писать спецификацию». Подход, который улавливает этот сдвиг, — это спецификационно-ориентированная разработка (Spec-Driven Development, SDD). В 2026 году крупные инструменты — Claude Code, GitHub, AWS и другие — все взяли его на вооружение, и он привлекает внимание как «следующий шаг» после vibe coding.

В этой статье для новичков разбираем, что такое спецификационно-ориентированная разработка, почему она нужна именно сейчас, базовые четыре шага, основные инструменты и когда выбирать её, а когда — vibe coding.

SPEC-DRIVEN DEVELOPMENT · ВЕДЁТ СПЕЦИФИКАЦИЯ

«Specify → Plan → Tasks → Implement»

— каждый шаг оставляет документ, поэтому ИИ не приходится догадываться

ШАГ 1

Specify

Опишите словами, что именно вы строите.

ШАГ 2

Plan

Добавьте проектирование, технологии и ограничения.

ШАГ 3

Tasks

Разбейте на небольшие, проверяемые единицы.

ШАГ 4

Implement

ИИ реализует всё по спецификации.

1. Что такое Spec-Driven Development (SDD)?

Спецификационно-ориентированная разработка — это подход, в котором «спецификация» становится главным героем проекта (центральным документом), а ИИ выводит из неё реализацию. Вместо того чтобы сразу заставлять ИИ писать код, вы сначала фиксируете «что и как строить» в структурированном документе, и ИИ-агент читает эту спецификацию, чтобы спроектировать, разбить на части и реализовать.

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

💡 В одну строку: SDD = «пиши спецификацию раньше кода». Спецификация — это источник истины, а код — производное, сгенерированное из неё. Через призму context engineering спецификация — это ещё и лучший «контекст», который вы можете передать ИИ.

2. Почему именно сейчас? «Стена трёх месяцев» vibe coding

Vibe coding (создание через диалог по ходу идей) умеет выдавать прототипы с невероятной скоростью, но склонен ломаться при масштабировании. В публикациях и среди практиков нередко описывают, как код, построенный на порыве, упирается в «стену технического долга» примерно через три месяца, а затраты на сопровождение раздуваются. Сгенерированный ИИ код остаётся как есть, накапливается в продакшене и потом становится невозможным для исправления.

Спецификационно-ориентированная разработка убивает этот «дрейф требований» ещё на этапе проектирования. Фиксация спецификации заранее добавляет усилий на старте, но резко сокращает переделки на последующих этапах. GitHub сообщает, что с помощью собственного инструментария число циклов «перегенерировать с нуля» снизилось примерно на порядок (данные приводит вендор).

VIBE CODING

Быстро · хорош для исследования

  • Прототипирование и проверка идей молниеносны
  • Нащупывайте направление прямо в диалоге
  • Но склонен ломаться при масштабировании
  • Требования дрейфуют, копится долг
SPEC-DRIVEN DEVELOPMENT

Поддерживаемо · хорош для выпуска

  • Спецификация — источник истины, меньше блужданий
  • Предотвращает дрейф требований по самой конструкции
  • Больше усилий на старте
  • Гораздо меньше переделок, проще сопровождать

Говорят даже, что «в 2026 году преимущество инженера — в умении писать спецификации больше, чем писать код». Чем больше вы делегируете ИИ, тем сильнее человеческая работа смещается к «точному определению того, что нужно построить».

3. Базовый поток — четыре шага

Названия немного различаются от инструмента к инструменту, но спецификационно-ориентированная разработка в целом следует одним и тем же четырём шагам. Главное — что каждый шаг оставляет документ (часто файл Markdown), который читает следующий шаг. Хитрость в том, чтобы информация не оставалась только в «голове» ИИ.

① Specify

Опишите словами, что строить — функции, цель, пользователей, критерии приёмки.

② Plan (проектирование)

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

③ Tasks (разбивка)

Разбейте план на небольшие, проверяемые единицы, которые можно подтверждать по одной.

④ Implement

ИИ реализует каждую задачу по спецификации. Человек сосредоточен на проверке и одобрении.

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

4. Основные инструменты (Spec Kit, Kiro и другие)

По состоянию на 2026 год большинство крупных кодинг-агентов поддерживают SDD. Вот ведущие примеры.

GitHub Spec Kit

Опенсорсный CLI (90 000+ звёзд на GitHub). Поддерживает Specify → Plan → Tasks → Implement и работает с более чем 30 агентами, включая Claude Code и GitHub Copilot.

AWS Kiro

Перед генерацией любого кода проходит Requirements → Design → Tasks, с роутером Auto, который подбирает лучшую модель под каждую задачу, и доступен как в CLI, так и в вебе.

Другие

BMAD, OpenSpec, Tessl, Google Antigravity и Cursor тоже предлагают собственные потоки SDD. Большинство крупных инструментов в той или иной форме его поддерживают.

Специальный инструмент даже не нужен — освоить сам подход можно, просто «сначала написав спецификацию в Markdown, а затем дав ИИ прочитать её перед реализацией». Это к тому же снижает вероятность проблемы, когда ИИ игнорирует ваши правила, потому что вы передаёте спецификацию как ясный документ.

5. Когда выбирать SDD, а когда vibe coding

Важно не «что правильнее», а «когда что применять». Практичный ответ для 2026 года — гибрид: vibe для исследования, SDD для выпуска.

  • Когда подходит vibe coding: проверка идеи, одноразовые прототипы, когда хочется попробовать что-то небольшое в одиночку. Этап, на котором нужно просто быстро добраться до «хоть чего-то».
  • Когда подходит SDD: продакшен-системы, которые вы будете долго сопровождать, командная разработка, продукты, где спецификация важна. Когда вы смотрите на весь жизненный цикл разработки.

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

6. Как попробовать прямо сегодня

Начать можно с малого, не устанавливая никакого специального инструмента.

  • Сначала напишите спецификацию на одну страницу: для нужной функции набросайте «цель, входы/выходы, критерии приёмки» пунктами в Markdown.
  • Дайте ИИ прочитать спецификацию, прежде чем просить код: скажите ему «реализуй строго по этой спецификации; обо всём неоднозначном спрашивай у меня». Не говорите просто «построй это».
  • Нарезайте задачи мелко: не всё разом — реализуйте одну функцию, проверьте, затем следующую. Если зафиксировать процедуру в Claude Skills, повторяемость возрастёт.
  • Держите спецификацию в актуальном состоянии: когда что-то меняется, сначала правьте спецификацию, потом код. Сохранять спецификацию источником истины — самая суть SDD.

💡 Помогает и новичкам: когда вы создаёте приложение с ИИ, одно лишь предварительное написание спецификации заметно повышает качество результата. Это приём, которым можно пользоваться, даже если вы не сильны в программировании.

Итоги

Три ключевых вывода о спецификационно-ориентированной разработке.

  • Что это: написание «спецификации» раньше кода и реализация ИИ по ней как по источнику истины. Спецификация — центральный документ.
  • Почему: потому что это предотвращает «дрейф требований и технический долг» vibe coding ещё на этапе проектирования и сокращает переделки.
  • Когда: гибрид — vibe для исследования, SDD для выпуска. Проверка человеком обязательна.

Начните с «напиши спецификацию на одну страницу, прежде чем строить». В эпоху ИИ поднимаются не те, кто быстрее всех пишет код, а те, кто умеет точно определить, что нужно построить. Прочитайте про vibe coding и context engineering вместе с этой статьёй, чтобы получить полную картину разработки с ИИ.

FAQ

Q. Может ли новичок в программировании заниматься спецификационно-ориентированной разработкой?

A. Да — пожалуй, для новичков она наиболее эффективна. Одно лишь упорядочивание «что строить» словами до любого кода стабилизирует вывод ИИ и повышает качество. Начать можно с заметок в Markdown, без всякого специального инструмента.

Q. Устарел ли теперь vibe coding?

A. Нет. Для исследования и прототипирования vibe coding по-прежнему самый быстрый. Это не «старое против нового» — применять их по фазам и есть мейнстрим 2026 года: vibe для исследования, SDD на пути в продакшен.

Q. Насколько подробной должна быть спецификация?

A. Ориентир — достаточно подробно, чтобы передать «цель, входы/выходы, критерии приёмки». Слишком детально — становится негибкой; слишком расплывчато — ИИ начинает гадать. Как и в шести частях хорошего промпта, целитесь в середину: конкретно, но гибко.

Q. Делает ли SDD проверку кода ненужной?

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