Спецификация — это цель компиляции

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

Это соотношение перевернулось — а переоценить свою работу под новый расклад не успел почти никто.

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

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

Вот и весь тезис. Остальная серия — о том, как это выглядит, если отнестись к нему буквально.

Чего на самом деле требует «компиляция»

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

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

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

Вот форма провала, которую я вижу постоянно. Черновик спеки утверждает, что в системе уже есть спящий механизм под то, что ты собрался строить: флаг, или закомментированный блок, или функция с ровно подходящим именем — и предложение сводится к «оно уже есть, просто включи». Правдоподобно. Символ существует; ленивая проверка — встречается ли имя в коде? — проходит. Но gate, который не принимает совпадение имени за доказательство, вместо этого открывает тело — и обнаруживает, что код с правильным именем делает совсем другое: охраняет другой ресурс, на другом слое, чем предполагает утверждение. Правильное имя, не та сущность — и на этом строилось бы целое направление работ. Когда каждое утверждение принудительно доведено до цитаты и перечитано в контексте, проваливаются почти никогда не абсурдные выдумки. Проваливаются правдоподобные утверждения, случайно истинные про другую часть системы.

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

Комната, в которой никто не стоит

А теперь утверждение неудобное — но я готов его защищать: я проверил, и почти все строят компилятор этажом ниже, чем нужно.

Движение spec-driven development уже реально. Spec Kit от GitHub, Kiro от AWS, Tessl — существует внятная карта, кто что занимает, и её стоит прочитать. У некоторых даже есть gate на слое спецификации — больше, чем я ожидал, когда пошёл проверять. Kiro проводит тебя от требований через дизайн к задачам и по ходу проверяет документ требований. Spec Kit поставляет Review & Acceptance Checklist, который ты валидируешь перед генерацией.

Так что комната не пуста. Но посмотри, что именно проверяют эти gate — в этом вся суть. Gate Kiro на спеке ловит неоднозначность, внутренние противоречия, неполноту, неверный уровень детализации. Чеклист Spec Kit спрашивает, полна ли спека и хорошо ли оформлена. Это настоящие, полезные проверки — и каждая из них проверяет когерентность. Согласован ли документ сам с собой? Полон ли он? Не противоречит ли себе?

Ни одна из них не задаёт другой вопрос: а это правда? Переживёт ли «API уже возвращает это поле» встречу с настоящим API? Ни один из этих инструментов не заземляет утверждения спеки о реальности в настоящей кодовой базе до генерации. Проверка Spec Kit против реальности запускается после имплементации — она сверяет собранный код со спекой, что само по себе дело хорошее, но противоположное тому, о чём я говорю. Исследования по grounding, которые действительно верифицируют против исходников (в 2026-м есть статьи с блокирующими gate, типизированными доказательствами, механической проверкой цитат), работают этажом ниже — на коде и извлечённых фрагментах, не на требованиях. Тулинг дизайн-систем заземляет имплементацию в реальных компонентах. Render-оракулы судят результат.

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

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

Это ставка, а не гарантия. «Рано» — синоним «риска». Аудитория, которой компилятор спецификаций нужен сегодня, мала, и справедливый читатель скажет, что это просто хорошая инженерная гигиена в пафосной рамке. Может быть. Я пишу для той версии тебя, которая через полгода будет стоять на ступеньке, на которую тебя вот-вот вытолкнут.

Серия: карта, а не территория

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

Что дальше:

• The Oracle Lens. Прежде чем строить gate, нужно понять, какую истину он вообще способен проверить. Я разделяю оракулы верификации на три оси — Truth (заземлено ли это в реальности), Coherence (согласовано ли внутри себя) и Intent (то ли это, чего на самом деле хотели) — и показываю их ортогональность: вот почему спека может пройти grounding и всё равно оказаться не тем.

• Grounding спеки. Тот самый блокирующий gate, целиком: «доказательство или не считается», метрика leak-rate и путаница слоёв как главный враг.

• Contracts, Not Tasks. Как ты передаёшь работу агенту, важнее, чем какому агенту, — и принцип под этим: гранулярность декомпозиции должна быть обратно пропорциональна силе твоего приёмочного gate.

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

Дальше: The Oracle Lens — три вида истины, которые gate может проверить, и один, который не может.