Метод, который заменяет Spec-Driven Development — IDSD

SDD оформился как подход потому, что вайб-кодинг не сработал. Ты описывал цель, получал в ответ блок кода, он выглядел правильным, но работал не совсем так, как нужно. Сами GitHub сказали это, когда выпустили spec-kit в сентябре 2025 года: модели «исключительно хорошо достраивают шаблоны, но не умеют читать мысли». Поэтому фокус сместился к спецификации. Заранее подробно запиши, чего ты хочешь, — и агент перестаёт гадать. Кто-то написал несколько команд, GitHub, как это обычно бывает с GitHub, перехватил разговор с помощью spec-kit, а следом пришла ещё дюжина решений: Kiro от AWS, Tessl, BMAD, Agent OS. Менее чем за год категория стала массовой.

Одно уточнение, потому что внимательные читатели это проверят. Разработка на основе спецификаций — не новая идея, и те, кто внимательно в неё вглядывался, давно это говорили. Ларман и Базили в 2003 году описали в IEEE Computer, что итеративная разработка восходит к 1950-м, а идеал однопроходной разработки, управляемой документами, вызывал сомнения с самого начала — даже у Ройса, человека, на которого обычно возлагают вину за этот подход. Год спустя в докладе «Agile Specification-Driven Development» на XP 2004 Острофф, Макалски и Пейдж отстаивали не большие предварительные спецификации, а противоположную идею: «полная» спецификация — ошибочный идеал, а спецификация должна возникать постепенно из тестов и контрактов. Они не могли написать слово «полная», не взяв его в кавычки. Современное промышленное применение этого подхода появилось за годы до волны искусственного интеллекта. Провал вайб-кодинга не изобрёл SDD. Он сделал SDD массовым. А человек, который поджёг фитиль, Андрей Карпати, придумал термин «вайб-кодинг», а не SDD. Он — мост между двумя эпохами, тот, кто позже сказал, что эпоха вайба заканчивается. Упрощённая версия этой истории приписывает ему оба термина, и это неверно.

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

SDD оставляет дыры, а агент их заполняет

Вся проблема SDD в том, что люди пишут спецификацию как хотят. В спецификации есть «что». В ней есть «как». В ней есть всё что угодно и в каком угодно виде — всё, что инженер способен туда записать. Каждый инженер заполняет её тем, что было у него в голове тем утром. Затем агенты — Claude Code, Codex и Droids — читают спецификацию и начинают принимать решения, потому что в ней зияют огромные пробелы. И эти пробелы — не дефект спецификации.

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

Как спецификация OpenAI Symphony на самом деле доказывает мою правоту

Посмотрите, что OpenAI опубликовала вместе с Symphony в апреле 2026 года. Symphony — это открытая спецификация для оркестрации агентов, и в её основе лежит один файл спецификации: 2169 строк, восемнадцать разделов, формулировки в строгом стиле «должен» и «следует». Такой уровень детализации показывает ровно то, чего мы просим от людей, и ровно то, чего они сделать не могут.

Если бы кто-то действительно мог заранее записать всё это в один SPEC.md, тогда да, такой подход работает. Это не сарказм, а буквальная правда. Полная, однозначная спецификация на две тысячи строк приводит к хорошему программному обеспечению. OpenAI около шести месяцев строила внутренний инструмент с одним жёстким правилом: никакого кода, написанного человеком, каждая строка должна быть сгенерирована Codex. Они довели его до рабочего состояния. И только после того, как он заработал, они извлекли спецификацию из уже работающей системы. Затем они заставили Codex за один проход построить эталонную реализацию на Elixir и отдельно реализовать ту же спецификацию ещё на пяти языках — TypeScript, Go, Rust, Java и Python — именно для того, чтобы вытряхнуть из неё неоднозначности. Глубокая спецификация уровня RFC — это ретроспективная документация программного обеспечения, которое уже работало. И это не моя интерпретация: это собственное описание OpenAI того, в каком порядке всё происходило.

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

Я сам себя в это загнал

Я столкнулся с этим на собственной работе. Спецификация была хорошей, но агент всё равно ушёл в сторону, потому что я вышел из цикла и позволил ему заполнить части, которые сам не продумал. Какое-то время я называл это дрейфом. Но это был не дрейф. «Дрейф» — слово, к которому тянешься, когда не хочешь сказать: «я ушёл». Мне это стоило трёх дней переделки, чтобы удалить код, который вообще не должен был быть написан. Я трачу от 150 до 200 миллионов токенов в день, работая со своими агентами, и при текущих тарифах Opus три дня такого использования обходятся примерно в 985 долларов — реальные деньги, которые я потратил сначала на создание проблемы, а потом ещё раз на её устранение. Это была самая дешёвая версия такого провала — мои собственные деньги на моей собственной машине. Именно поэтому важно, что спецификация была хорошей: хорошая спецификация не держится сама по себе; она держится потому, что кто-то остаётся в цикле, пока она выполняется. А в тот раз я не остался.

ICE: три ремесла и цикл, в котором они работают

Рамка называется ICE: намерение, контекст, ожидания (Intent, Context, Expectations). Эта статья определяет первое из них, потому что намерение — это базовая сущность, на которой держится всё остальное. Контекст и ожидания — тоже настоящие ремесла, но они для следующей статьи; попытка определить все три сразу — это верный путь обратно к одному раздутому документу, который этот подход как раз должен заменить. Поэтому сейчас — намерение, а контекст и ожидания позже.

Возьмём самый простой пример. Бизнес-сценарий: «Пользователь хочет купить красную обувь дешевле 90 долларов». Намерение — купить красную обувь дешевле 90 долларов: результат, которого хочет человек, без упоминаний о том, какой стек или какой сервис должен это реализовать. Намерение — первоклассная базовая сущность всего метода, и это не одно предложение. Намерение складывается из пяти вещей: описания того, что требуется; ограничений вокруг этого; сценариев, при которых всё считается провалом; сценариев, при которых всё считается успехом; и связей — ссылок на другие намерения, которых оно касается, чтобы изменение здесь можно было проследить до всего, на что оно влияет. Упустите любой из этих пяти элементов — и вы снова окажетесь перед дырой, которую агент заполнит за вас.

Если в понедельник вы сделаете только одно, сделайте вот это. Возьмите один реальный результат, который собираетесь поставить на этой неделе, — не систему целиком, а один результат: красную обувь дешевле 90 долларов. Опишите для него пять частей. Что требуется: красная обувь, которую покупатель действительно может купить дешевле 90 долларов. Ограничения: его размер, наличие на складе и возможность доставки этому покупателю. Сценарии провала: вернуть обувь за 140 долларов, обувь не в наличии или обувь не красного цвета. Сценарий успеха: покупатель добавляет доступную красную обувь в корзину и оформляет заказ. Связи: всё, что касается цены, запасов или оформления заказа, потому что изменения там меняют это намерение. Затем проверка: дайте это человеку, который не был у вас в голове, и спросите, где агенту всё ещё пришлось бы гадать. Каждое место, на которое он укажет, — это дыра, которую вы уже почти позволили заполнить. Закройте эти дыры, а не всю систему целиком. Это первый ход, и он стоит часа, а не внедрения новой методологии.

Ожидания

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

Контекст

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

Эти ремесла остаются просто отдельными частями, пока вы не увидите, как они движутся. Поэтому вот цикл, который нам нужно построить.

Человек даёт две вещи: намерение и ожидания, которые определяют, что значит «готово» и каким результат быть не должен. Они поступают в агентный цикл написания кода, где обвязка выполняет работу: подтягивает контекст, пишет код и проверяет его по ожиданиям. Если ожидания не выполнены, цикл запускается снова — и повторяется до тех пор, пока они не будут выполнены. Наконец, когда всё готово, код мерджится. Человек владеет намерением и ожиданиями и никогда их не покидает; обвязка владеет циклом, и её никогда не просят придумывать, чего хотел человек.

В этом и заключается весь смысл ICE. SDD дает сбой, потому что он требует, чтобы один документ, написанный одним способом тем, кто держит клавиатуру, одновременно служил смыслом, определением готовности, рабочим процессом и контекстом, а промежутки между ними остаются на усмотрение агента. Также стоит ясно сказать: обвязка — это не метод. spec-kit, BMAD и весь лагерь промптов и рабочих процессов — это обвязки, полезные обвязки, но всё же только обвязки. ICE же — это метод, который решает, что именно является работой, ещё до того, как обвязка вообще к ней прикоснётся. Возьмите обвязку без метода — а сегодня это вариант по умолчанию, потому что именно у обвязки есть кнопка «скачать», — и вы получите тот же провал, за который я заплатил тремя днями переделки, только уже в масштабе и с именем клиента на нём.

Я называю это IDSD — разработкой программного обеспечения на основе намерений (Intent-Driven Software Development), где объявлять результаты и позволять машине определять реализацию становится обычным способом работы, а не мечтой.

Кто-то скажет, что это всё та же спецификация под другим именем, и насчёт файлов они будут правы, но насчёт сути изменений — нет. Всё это по-прежнему Markdown: намерение, ожидания и контекст, и формат никогда не был проблемой. Изменилось то, чем является каждый файл и кто им владеет. Никакого отдельного ремесла спецификации нет: то, что раньше было расползающейся спецификацией, теперь стало ожиданиями — короткой границей, написанной человеком, которому был нужен результат, а не угаданной тем, кто в тот момент держал клавиатуру. Контекст — это то, как агентные инструменты выполняют свою работу; им владеет обвязка, а не человек, который импровизирует его в том же абзаце, где описывает желание пользователя. Один файл, написанный так, как держателю клавиатуры показалось тем утром, — вот что сломалось. А намерение плюс явный набор ожиданий, переданные обвязке, которая владеет сборкой, — это уже совсем другое.

IDSD как минимум на два уровня выше того места, где индустрия находится сегодня

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

Ира сказала это вслух. Она мой ведущий консультант, восемнадцать лет опыта. «Команды ещё не приняли SDD, — сказала она. — Ему едва исполнился год, и большинство всё ещё делает вид, что им пользуется. А теперь ты хочешь, чтобы они писали намерения и ожидания как отдельные ремёсла, с трассируемостью между ними, да ещё и для агентов. Это на две ступени выше того, где команды реально находятся».

Потом заговорила Найра. Она дала аудитории двинуться дальше, как она обычно делает. «Одну минуту». Тихо, будто речь шла о чём-то небольшом. «То, что команды не готовы, — не риск. Риск — это день, когда агент напишет десять тысяч строк, которые выглядят правильно, а никто не будет владеть той частью, где объясняется, что значит “правильно”. Мы не просим их освоить более сложную спецификацию. Мы просим их продолжать выполнять одно суждение, которое этот метод очень легко позволяет пропустить». Она только что вернула мне весь аргумент в четырёх предложениях — и превратила возражение Иры в причину делать это, а не в причину не делать.

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

Что не даёт мне спать

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

Когда мои команды работают над проектами, они будут упускать критически важные части системы. Это те самые десять тысяч строк Найры, которые выглядят правильно, — то, на что она тихо указала ещё до того, как у меня появились для этого слова. Не потому, что команды плохие. А потому, что теперь стало до смешного легко генерировать огромный объём кода, и чем проще становится генерация, тем увереннее можно ошибаться в промышленных масштабах. Когда METR провела в 2025 году контролируемое испытание на эту тему, опытные разработчики с ИИ работали заметно медленнее, но уходили с уверенностью, что ИИ сделал их быстрее. Ошибаться и при этом чувствовать, что ты ускорился, — весь провал в одном предложении. Мы будем тратить время и деньги на то, чтобы хорошо производить не то. Это чертовски меня пугает, и у меня есть чеки, подтверждающие, что страх заслуженный. Это снова мои три дня переделки, только гораздо больше и уже за счет клиента.

Настоящий ответ — тот, в который я верю, но которым сам живу не до конца, — в том, что нужно быть вовлечённым на каждом шаге. Быть частью команды, пока работа происходит, а не проверяющим, который приходит в конце благословить diff, уже слишком большой, чтобы его по-настоящему прочитать. Я выделял это как ключевую метрику: присутствие в цикле, а не одобрение на воротах. У меня это неплохо получается. Но я не могу делать это всё время. Та часть меня, которая хочет довериться агенту и отойти, — та же самая часть, которая купила мне три дня переделки. Я знаю этот провал изнутри, потому что я его постоянный клиент.

Кто на самом деле платит

В конечном счёте это история не про разработку программного обеспечения. Это история про экономику, а люди в самом низу этой цепочки ни разу в жизни не читали спецификацию.

Есть два способа строить программное обеспечение, и индустрия это знает, даже когда не произносит вслух. Можно писать код: медленно создавать и дёшево запускать, потому что вычисления уже много лет являются массовым товаром. А можно опереться на агентов: быстро создавать и дорого запускать. Не потому, что токены стали дорогими: цена за токен продолжает падать. Дорого — потому что агент, которому позволили заполнять пробелы, сжигает настолько больше токенов на один законченный результат, что стоимость результата растёт, даже когда цена падает. И пугающе большая доля этих токенов уходит на уверенно неверные действия до того, как кто-то это замечает.

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

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

Вот что я делаю с этим в собственной команде. Мы идём дальше SDD. Мы будем запускать IDSD: намерение и ожидания, написанные с настоящей дисциплиной; контекст, удержанный ровно в тех границах, которые нам нужны; и затем агенты выполняют работу. Мне немного страшно. Я всё равно это делаю, потому что это необходимо сделать и потому что за этим стоит принцип догфудинга: сначала запускаешь собственный метод на себе, прежде чем он когда-либо попадёт в счёт клиента. Маховик начинает накапливать эффект только если он вращается, а вращается он только тогда, когда кто-то готов сделать первый оборот. Так это и начинается.

Так что вопрос не в том, могут ли ваши агенты выполнить работу. Могут. Вопрос в том, хватит ли у вас дисциплины самому владеть намерением и ожиданиями — и хватит ли нервов оставаться в цикле, пока машина работает, в тот день, когда было бы намного проще выйти из него и просто благословить diff. Этот день и есть вся игра. Что вы сделаете в этот день?

Источник