Хватит писать софт дважды: разработка по спецификации и конец переписываний
Почему софт всегда писали дважды — один раз в спецификациях, второй в коде — и почему второе написание наконец исчезает.
В разработке софта, если делать её правильно, приходится писать софт дважды: сначала в детальных спецификациях, объясняющих, что именно софт должен делать, а затем снова в виде кода, который эти спецификации оживляет. Но вот горькая правда: правильно с первого раза это делают редко.
Процесс часто ломается, потому что создание исчерпывающих спецификаций требует времени, а команды редко фиксируют все нужные детали заранее. Это ведёт к пробелам, допущениям и дорогим переделкам. В результате проекты по разработке софта часто выходят за бюджет, срывают сроки и оставляют всех разочарованными.
Скрытые издержки написания софта дважды
Чтобы понять, почему писать софт дважды необходимо, но редко удаётся хорошо, разберём две фазы:
1. Первое написание: спецификации на естественном языке
В первый раз, когда софт пишется, мы вообще не пишем код. Это создание требований, пользовательских историй и проектной документации — на естественном языке. Здесь команды описывают, как софт должен функционировать, что пользователи могут делать и каким должен быть опыт.
Но вот проблема: ни у одной команды не бывает роскоши расписать все детали. Продакт-менеджерам часто приходится спешить, чтобы уложиться в агрессивные сроки, — а в некоторых проектах профессиональных продакт-менеджеров вообще нет. Они очерчивают крупные штрихи, но ключевые функции и взаимодействия упускаются. Как говорил Стив Джобс, «великие продукты делаются из 5000 маленьких решений», но в большинстве проектов мы не принимаем эти решения заранее. Их оставляют разработчикам на истолкование позже, и это ведёт ко второму шагу.
2. Второе написание: перевод спецификаций в код
Как только спецификации переданы, инженеры отвечают за превращение этих описаний в работающий код. Но когда первое «написание» неполно, разработчики вынуждены заполнять пробелы воображением. Делаются допущения, и хотя инженеры могут хорошо владеть технологией, у них может не быть полной картины продуктового видения.
Здесь проблемы и всплывают:
- Упущенные детали ведут к трению: когда продуктовые команды не описывают важную функцию или сценарий, разработчикам приходится угадывать или импровизировать. Часто это приводит к функциональности, не соответствующей ожиданиям.
- Допущения ведут к переделкам: когда разработчики заполняют пробелы, они могут построить функции так, что это не совпадёт с продуктовым видением, что вызывает масштабные переделки позже в проекте.
- Указывание пальцем становится неизбежным: когда сроки съезжают и бюджеты трещат, команды перекладывают вину. Продуктовые команды упрекают разработку в том, что она «не поняла», а инженеры указывают на продукт за неясные спецификации.
Результат — каскад проблем, ведущих к сорванным срокам, превышенным бюджетам и неудовлетворительным итогам. Исследование CHAOS от Standish Group годами фиксирует, что большинство проектов по разработке софта выходят за бюджет и срывают даты поставки. Исследование McKinsey совместно с Оксфордским университетом обнаружило, что крупные ИТ-проекты в среднем превышают бюджет на 45% и сроки на 7%, давая при этом на 56% меньше ценности, чем предсказывалось, — и что 17% крупных ИТ-проектов идут настолько плохо, что угрожают самому существованию компании.
Очевидно, что-то в этом процессе сломано.
У практики теперь есть имя
Индустрия сошлась на термине для этого, пока большинство спорило о промптах: разработка по спецификации. Сначала напишите требования, ограничения и критерии успеха. Относитесь к этой спецификации как к источнику истины. Дайте агенту строить против неё.
GitHub выпустил Spec Kit. AWS выпустил Kiro. BMAD-METHOD, OpenSpec и Tessl — все попробовали свои силы. Мартин Фаулер об этом написал. Такое схождение не случайно — так бывает, когда целая категория обнаруживает один и тот же режим отказа одновременно.
А режим отказа — тот, что описан выше. Инструменты, начинающие с промпта, пропускают первое написание целиком. Они идут прямо ко второму, угадывая каждое решение, которого спецификация так и не приняла. Это нормально для демо и губительно для продукта.
Разработка по спецификации не устраняет первое написание. Она делает первое написание единственным, требующим человеческого суждения.
Новое первое написание: спецификации, которые можно действительно закончить
Вот что меняется. Причина, по которой никто не писал полных спецификаций, никогда не была в том, что не хотели, — она была в том, что работа шла слишком медленно, чтобы её оправдать. Недели исследования, чтобы получить документ, устаревавший при первом контакте со спринтом. Так что команды писали крупные штрихи и оставляли 5000 маленьких решений на обнаружение позже, по одному истолкованию за раз.
Когда составление спецификации занимает часы, а не месяцы, арифметика переворачивается. Вы можете позволить себе быть исчерпывающим. Функциональные требования, визуальный дизайн, модель данных, краевые случаи — зафиксированы прежде, чем кто-то откроет редактор, и достаточно дешёвы, чтобы править, когда вы что-то узнаёте.
Последняя часть важна. Спецификация, которую нельзя дешёво изменить, становится ложью в момент прихода реальности. Это тот же инстинкт, что и за сборкой API-first: примите несущие решения верно прежде, чем кто-то напишет экран, и остальное следует само.
Новое второе написание: генерация кода, а не перевод
Как только спецификация полна, второе написание перестаёт быть задачей перевода. Оно становится задачей генерации. Стандартные языки — JavaScript, TypeScript, Python. Стандартные фреймворки — React, Next.js. Настоящий код, в формах, которые инженеры уже знают, выведенный из документа, где каждое решение уже принято.
Разница не в том, что разработчики работают быстрее. В том, что они перестают делать часть, которая никогда не была инженерией, — механический пересказ решений, уже принятых кем-то другим.
Что меняется ниже по течению
Три вещи меняются одновременно:
- Первое написание доводится до конца: когда работа над спецификацией стоит часы, а не месяцы, команды могут позволить себе принять маленькие решения заранее, а не обнаруживать их на код-ревью.
- Никто не заполняет пробелы: код, сгенерированный из полной спецификации, не требует от кого-либо угадывать, что имела в виду продуктовая команда. Угадывание всегда было источником дефектов.
- Переделки перестают накапливаться: замысел и реализация стартуют согласованными. То, что раньше было переписыванием, становится правкой спецификации.
Будущее написания софта: естественный язык
Сколько люди выпускают софт, столько работа требовала писать его дважды: один раз на естественном языке, второй в коде. Это второе написание никогда не было ценной частью. Это была пошлина, которую мы платили, потому что другой дороги не было.
Это тот ход, вокруг которого организовано следующее поколение ИИ-конструкторов приложений: ясность прежде кода. Опишите приложение как чертёж, добейтесь верной архитектуры, дайте коду сгенерироваться против неё. Не срезка мимо работы по определению, а причина наконец сделать её как следует.
Теперь есть другой путь. Софт всегда должен был писаться один раз.
Что почитать дальше
Полное руководство по практике: разработка по спецификации. Почему поколение «сначала промпт» пропустило этот шаг, разобрано в vibe coding нарушил своё обещание, а что приходит на замену — в что приходит после vibe coding.
Часто задаваемые вопросы
Что такое разработка по спецификации? Разработка по спецификации означает написание требований, ограничений и критериев успеха до генерации любого кода и отношение к этой спецификации как к источнику истины, против которого строит ИИ-агент. Она возникла в 2025 году как прямой ответ на рабочие процессы «сначала промпт», полностью пропускающие шаг определения.
Чем разработка по спецификации отличается от написания традиционного документа требований? Документ — та же идея; экономика иная. Традиционные спецификации были достаточно дороги, чтобы команды писали крупные штрихи и обнаруживали остальное на код-ревью. Когда спецификация занимает часы, а не месяцы, и её можно дешёво править, её становится стоит доводить до конца — и стоит поддерживать в актуальности.
Какие инструменты поддерживают разработку по спецификации? GitHub Spec Kit, AWS Kiro, BMAD-METHOD, OpenSpec и Tessl — названные реализации, а Cursor поддерживает облегчённую версию через файлы правил. Различаются они в основном тем, насколько жёстко спецификация привязана к коду: управляет ли она генерацией однократно, развивается вместе с кодом или является единственным артефактом, который вы правите.
Замедляет ли разработка по спецификации команды? Она перемещает работу, а не добавляет её. Решения, зафиксированные в спецификации, — это решения, которые кто-то принимает в любом случае: либо осознанно заранее, либо неявно разработчиком или моделью, угадывающей позже. Второй путь и есть источник переделок.
Что происходит с разработчиками, если код генерируется из спецификаций? Механический пересказ чужих решений исчезает. Суждение об архитектуре, компромиссах, корректности и о том, чего строить не надо, — нет. Это всегда были те части, которые требовали инженера.
