# Спека — это исходник. Промпт — сборочный мусор. В кодовой базе, которую пишет агент, что такое «исходный код»? Не сгенерированный код — это теперь build-output, как скомпилированный бинарь. И не промпт — это спичка, которой ты поджигаешь сборку и тут же бросаешь. Долговечная вещь, которую ты пишешь, которой владеешь, версионируешь и ревьюишь, — это спека. Иерархия перевернулась, а большинство всё ещё полирует ту часть, которую надо выбрасывать. - **Author:** Фёдор Чищин - **Published:** 2026-06-03 - **Tags:** agents, specs, methodology - **Source:** https://fedorthinks.com/ru/blog/the-spec-is-the-source --- Вот вопрос, который звучит просто, но таковым не является, как только ИИ-агент пишет бо́льшую часть твоего кода: что теперь _исходный код_? Покажи пальцем на ту вещь, которая является настоящим, авторитетным, ты-это-редактируешь артефактом проекта. Большинство показывает на код, который сгенерировал агент. Некоторые — на промпт. Оба неправы, и разрыв между верным ответом и этими двумя — это и есть весь сдвиг, который стоит понять. Я [писал раньше](/blog/specs-are-the-artifact), что спека, а не промпт, — артефакт, о котором стоит рассуждать. Год того, как это становилось целой индустрией, только заострил утверждение. Дело не просто в том, что спека — _один из_ артефактов. Дело в том, что спека теперь — **исходник**, а две вещи, к которым ты инстинктивно тянешься, код и промпт, обе понижены под ней. ## Старая иерархия: код был правдой Всю историю софта исходный код был источником правды. Это была долговечная вещь, которую ты писал руками, которой владел, клал под контроль версий, ревьюил строка за строкой и о которой спорил. Документация и комментарии были вторичны — описания _кода_, которым позволено расходиться, никогда не авторитет. Когда доки и код противоречили друг другу, побеждал код, потому что код был реален, а доки — рассказ о нём. Эта иерархия переворачивается, и у этого есть имя. ## Переворот: спека — исходник, код — build-output **Spec-driven development** (разработка от спецификации) — методология, версию которой в 2025–26 выпустил каждый крупный ИИ-инструмент для кода — делает [написанную, версионируемую спецификацию единственным источником правды, а код трактует как сгенерированный вывод](https://thebcms.com/blog/spec-driven-development). Ты пишешь спеку — что система делает и зачем, — выводишь план, разбиваешь его на задачи, и агент генерирует из него код. Спека — артефакт, который правят люди; код — то, что выдаёт сборка. Аналогия, к которой поле постоянно тянется, — ровно та самая: [спека — исходник так же, как `.c`-файл является исходником, а код — это бинарь, в который он компилируется](https://www.augmentcode.com/guides/what-is-spec-driven-development). Ты не правишь руками скомпилированный бинарь; ты правишь исходник и пересобираешь. В spec-driven development [сгенерированный код — это бинарь](https://www.morphllm.com/spec-driven-development) — его ты тоже не патчишь руками, потому что в тот миг, когда ты это делаешь, он рассинхронизируется с исходником, который должен его определять. Ты меняешь спеку и регенерируешь. Это больше не маргинальная идея. У GitHub [Spec Kit](https://www.marktechpost.com/2026/05/08/meet-github-spec-kit-an-open-source-toolkit-for-spec-driven-development-with-ai-coding-agents/) перевалил за 90 000 звёзд и поддерживает 29+ агентов; AWS Kiro — это IDE, целиком построенная вокруг этого; Cursor, OpenSpec, Tessl и остальные выпустили свою версию. Кто-то даже назвал это [пятым поколением программирования](https://medium.com/google-cloud/spec-driven-development-54cdf7e0b088). Весь мир инструментов сошёлся на одном и том же перевороте разом. ## Почему это верно, а не просто модно Причина, по которой это работает, — та же, по которой работает компиляция из исходника: ты рассуждаешь и вносишь изменения на уровне _намерения_, а сборку оставляешь производить артефакт. Spec-driven development [возник именно как противоядие от «vibe coding»](https://thebcms.com/blog/spec-driven-development) — напромптить агента в кучу правдоподобного кода, который расходится с тем, что ты имел в виду, галлюцинирует API и гниёт по мере роста. Привяжи сборку к написанному намерению — и расхождению есть с чем сверяться. И это окупается. GitHub сообщает, что команды на Spec Kit отгружают фичи примерно [на порядок меньшим числом циклов «перегенерировать с нуля»](https://www.fundesk.io/spec-driven-development-github-spec-kit-guide), чем при импровизированном промптинге; AWS документирует [40-часовые фичи, отгруженные меньше чем за 8 часов](https://www.morphllm.com/spec-driven-development) человеческого времени, когда они написаны спека-первой. Это не маленькая оптимизация — это то, что происходит, когда ты перестаёшь править бинарь руками и начинаешь владеть исходником. ## Так что тогда промпт? Вот часть, которая переосмысляет всё. Если спека — исходник, а код — build-output, то промпт даже не в иерархии того, что ты хранишь. **Промпт — это сборочный мусор** — транзитная команда, которую ты подаёшь, чтобы запустить генерацию, как строчка в шелле, которой ты вызываешь `make`. Ты не кладёшь вызов `make` под контроль версий и не ревьюишь его в pull request; ты версионируешь Makefile и исходник, а команда — это просто как ты в тот раз запустил сборку. Вот почему зацикливаться на формулировке промпта всегда было целиться не туда — тот же тезис, что я приводил, доказывая, что [промпт-инжиниринг мёртв](/blog/prompt-engineering-is-dead). Команды полируют формулировку одноразовой вещи, недоинвестируя в спеку — ту самую, над которой надо корпеть, которую надо версионировать и ревьюить. Они вычитывают спичку и игнорируют чертёж. ## Как это выглядит на практике Это просто то, как я строю. Спека — артефакт, над которым я реально работаю: вещь, которую я набрасываю, с которой спорю сам с собой, кладу под контроль версий и ревьюю как важную, потому что важна именно она. Агент генерирует из неё код. Если код неверен, я почти никогда не патчу код; я чиню спеку и регенерирую, потому что патчить вывод руками — это править бинарь и рассинхронизироваться с исходником. А промпт, который вёл конкретную генерацию? К следующему дню его нет. Я больше никогда на него не смотрю, потому что это был мусор — то, что ты чиркаешь, чтобы запустить сборку, а не то, что хранишь. Так что у вопроса, с которого я начал, теперь чистый ответ. Исходный код системы, построенной ИИ, — это спека. Код — то, что сборка из неё выдаёт. Промпт — спичка, которую ты чиркаешь и бросаешь. Пиши спеку так, будто это исходник, — потому что именно им она и стала.