Спека — это исходник. Промпт — сборочный мусор.

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

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

Старая иерархия: код был правдой

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

Эта иерархия переворачивается, и у этого есть имя.

Переворот: спека — исходник, код — build-output

Spec-driven development (разработка от спецификации) — методология, версию которой в 2025–26 выпустил каждый крупный ИИ-инструмент для кода — делает написанную, версионируемую спецификацию единственным источником правды, а код трактует как сгенерированный вывод. Ты пишешь спеку — что система делает и зачем, — выводишь план, разбиваешь его на задачи, и агент генерирует из него код. Спека — артефакт, который правят люди; код — то, что выдаёт сборка.

Аналогия, к которой поле постоянно тянется, — ровно та самая: спека — исходник так же, как .c-файл является исходником, а код — это бинарь, в который он компилируется. Ты не правишь руками скомпилированный бинарь; ты правишь исходник и пересобираешь. В spec-driven development сгенерированный код — это бинарь — его ты тоже не патчишь руками, потому что в тот миг, когда ты это делаешь, он рассинхронизируется с исходником, который должен его определять. Ты меняешь спеку и регенерируешь.

Это больше не маргинальная идея. У GitHub Spec Kit перевалил за 90 000 звёзд и поддерживает 29+ агентов; AWS Kiro — это IDE, целиком построенная вокруг этого; Cursor, OpenSpec, Tessl и остальные выпустили свою версию. Кто-то даже назвал это пятым поколением программирования. Весь мир инструментов сошёлся на одном и том же перевороте разом.

Почему это верно, а не просто модно

Причина, по которой это работает, — та же, по которой работает компиляция из исходника: ты рассуждаешь и вносишь изменения на уровне намерения, а сборку оставляешь производить артефакт. Spec-driven development возник именно как противоядие от «vibe coding» — напромптить агента в кучу правдоподобного кода, который расходится с тем, что ты имел в виду, галлюцинирует API и гниёт по мере роста. Привяжи сборку к написанному намерению — и расхождению есть с чем сверяться.

И это окупается. GitHub сообщает, что команды на Spec Kit отгружают фичи примерно на порядок меньшим числом циклов «перегенерировать с нуля», чем при импровизированном промптинге; AWS документирует 40-часовые фичи, отгруженные меньше чем за 8 часов человеческого времени, когда они написаны спека-первой. Это не маленькая оптимизация — это то, что происходит, когда ты перестаёшь править бинарь руками и начинаешь владеть исходником.

Так что тогда промпт?

Вот часть, которая переосмысляет всё. Если спека — исходник, а код — build-output, то промпт даже не в иерархии того, что ты хранишь. Промпт — это сборочный мусор — транзитная команда, которую ты подаёшь, чтобы запустить генерацию, как строчка в шелле, которой ты вызываешь make. Ты не кладёшь вызов make под контроль версий и не ревьюишь его в pull request; ты версионируешь Makefile и исходник, а команда — это просто как ты в тот раз запустил сборку.

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

Как это выглядит на практике

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

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