Разработка по спецификации: практика, к которой сошлась категория

Каждый серьёзный ИИ-инструмент для кодирования выпустил одну и ту же возможность в пределах примерно года друг от друга — а такое почти никогда не происходит случайно.

В 2025 году интересным вопросом было, насколько хороши становятся модели. В 2026 интересный вопрос — что вы им передаёте.

GitHub выпустил Spec Kit. AWS выпустил Kiro, среду разработки, построенную вокруг этой идеи. BMAD-METHOD, OpenSpec и Tessl — каждый попробовал свои силы. Cursor пришёл к тому же через файлы правил. Мартин Фаулер опубликовал сравнение реализаций. Когда шесть независимых команд сходятся к одному ответу в пределах двенадцати месяцев, они не копируют друг друга. Они все бьются об одну и ту же стену.

У стены теперь есть имя. И у решения тоже.

Что такое разработка по спецификации на самом деле

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

Вот и всё. Это не новая идея — это инженерия требований, которой индустрия тридцать лет занималась плохо, а потом в основном забросила как слишком медленную. Изменилась не концепция. Изменилась экономика.

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

Режим отказа, против которого это изобрели

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

Какие решения? Те, что оказываются важными. Уникален ли адрес электронной почты и уникален в пределах чего. Что отменённый аккаунт всё ещё может видеть. Что происходит, когда два человека правят одну запись. Нужна ли тому списку пагинация до того, как в нём окажется десять тысяч строк.

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

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

Данные о том, что происходит без этого

Отчёт DORA «State of AI-assisted Software Development» за 2025 год — самое ясное доступное чтение. 90% специалистов в технологиях теперь используют ИИ на работе, и более 80% верят, что он повысил их продуктивность. И более высокое внедрение ИИ связано с ростом пропускной способности поставки софта и с ростом нестабильности поставки софта одновременно.

Быстрее выпускают. Хуже удерживают работоспособность. И то и другое вместе.

Анализ GitClear за 2026 год по 623 миллионам изменений кода показывает форму ущерба. Относительно базы 2023 года: дублированных блоков кода больше на 81%, копипаста внутри коммита выросла с 9,4% в 2022 году до 15,7% в первой половине 2026 года, конструкций, маскирующих ошибки, больше на 47%. При этом межфайловые вызовы функций — лучший доступный индикатор переиспользования кода — снизились на 35%, а активность рефакторинга обрушилась с 21% изменений в 2022 году до 3,8% в 2026-м.

Разработчики теперь примерно в пять раз чаще копируют и вставляют, чем рефакторят. В 2022 году это соотношение работало в обратную сторону.

Ничто из этого не проблема качества модели. Это то, что происходит, когда генерация дешёва, а структура — ничья явная задача.

Три степени приверженности

Не все имеют в виду одно и то же, и различия важны на практике. Формулировка Мартина Фаулера — самая чистая из виденных мною.

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

Спецификация как якорь. Спецификация и код развиваются вместе. Меняете спецификацию, перегенерируете затронутые части, поддерживаете актуальность обоих. Больше дисциплины, а награда — документ, которому можно доверять.

Спецификация как источник. Спецификация — единственный артефакт, который вы правите. Код — это вывод, как скомпилированный бинарник, — его не патчат вручную. Сильнейшие гарантии и самый большой скачок в том, как работает команда.

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

Что относится к спецификации

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

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

Что не относится: детали реализации, которые генератор выбирает лучше вас. Спецификация, называющая имена переменных, — это не спецификация, а код с худшими инструментами.

Часть, в которой все ошибаются

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

Если ограничение живёт только в документе, это пожелание. Генератор прочитал его один раз и мог соблюсти или не соблюсти в четырнадцатом файле, к которому прикоснулся. Ограничения должны оказаться там, где система проверяет: not-null и unique в базе данных, а не в обработчике формы; типы на границах, а не в комментарии; авторизация как политика, которую система вычисляет, а не как условие, которое кто-то не забыл написать.

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

Как понять, действительно ли вы этим занимаетесь

Четыре вопроса, и они неудобны специально.

1. Когда что-то ломается, вы правите код или спецификацию? Если ответ всегда «код», у вас в лучшем случае «сначала спецификация», и документ уже устарел.
2. Сможет ли новый человек прочитать спецификацию и предсказать поведение системы? Если ему придётся читать код, чтобы понять, спецификация — сводка, а не источник.
3. Есть ли в спецификации что-то, что система не может нарушить? Если каждое правило — проза, ни одно из них не гарантировано.
4. Вы рецензируете спецификацию или дифф? Рецензировать тысячи строк сгенерированного кода — театр. Спорьте о документе, пока спор ещё дёшев.

Где это оставляет инструменты

Большинство нынешних реализаций работают по спецификации конкретно для генерации кода. Они производят спецификацию и генерируют против неё реализацию, а артефакт, с которым они работают, — кодовая база.

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

Разумные люди расходятся в том, насколько далеко это заходить. Никто из серьёзных не предлагает вернуться назад.

Чего это стоит

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

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

И это действительно применимо не ко всему. Если вы проверяете идею на этих выходных и собираетесь выбросить результат — выбрасывайте. Ничто из этого не стоит делать для софта с двухдневным сроком жизни.

Почему это прижилось

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

Это больше не тот обмен. Теперь документ и есть большая часть работы, а сборка — дешёвая часть. Шесть независимых команд заметили это в пределах года друг от друга, потому что это было очевидным следствием того, что модель стала хороша.

Практика не выиграла спор. Экономика сдвинулась у неё под ногами.

Что почитать дальше

Исходный диагноз: vibe coding нарушил своё обещание. Куда категория двинулась дальше: что приходит после vibe coding. Тот же аргумент применительно к целым системам: проектирование софта AI-first с нуля. И более старая формулировка той же идеи: хватит писать софт дважды.

Часто задаваемые вопросы

Что такое разработка по спецификации? Написание требований, ограничений и критериев успеха до генерации любого кода и отношение к этой спецификации как к источнику истины, против которого строит ИИ-агент. Она возникла в 2025 и 2026 годах как прямой ответ на рабочие процессы «сначала промпт», пропускающие шаг определения.

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

Какие инструменты поддерживают разработку по спецификации? GitHub Spec Kit, AWS Kiro, BMAD-METHOD, OpenSpec и Tessl — названные реализации, а Cursor поддерживает облегчённую версию через файлы правил. Различаются они в основном тем, насколько жёстко спецификация связана с кодом: управляет ли она генерацией однократно, развивается рядом с ним или является единственным артефактом, который вы правите.

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

Замедляет ли разработка по спецификации команды? Она перемещает работу, а не добавляет её. Решения в спецификации принимаются либо осознанно заранее, либо неявно генератором, угадывающим позже, и второй путь и есть источник переделок. Она медленнее в первую неделю и быстрее после.

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

Разработка по спецификации — то же, что проектирование AI-first? Разработка по спецификации — практика определения прежде генерации. Проектирование AI-first — более широкий набор архитектурных следствий, который также покрывает, где обеспечиваются ограничения, в каком порядке вы принимаете решения и проектирование под агентных потребителей наряду с человеческими.