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

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

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

Когда агент берёт точное описание изменения и за минуты выдаёт рабочую, протестированную имплементацию, имплементация перестаёт быть узким местом. Перестаёт быть местом, где живёт мастерство.

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

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

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

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

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

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

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

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

• «API уже возвращает это поле»
• «это чисто UI-изменение»
• «консьюмер переживёт лишний параметр»

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

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

Вот форма провала, которую я вижу постоянно.

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

Почему проходит ревью. Символ существует. Ленивая проверка — встречается ли имя в коде? — загорается зелёным.

Что находит настоящий gate. Не принимай совпадение имени за доказательство, открой тело — и код с правильным именем делает совсем другое: охраняет другой ресурс, на другом слое, чем предполагает утверждение.

Цена. Правильное имя, не та сущность — и на этом строилось бы целое направление работ.

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

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

УТВЕРЖДЕНИЕ   «API уже возвращает это поле»
ДОКАЗАТЕЛЬСТВО  обязательно — файл:строка и фактическая форма в этой строке
ВЕРДИКТ       принято          утверждение входит в спеку
              отклонено        утверждение вычёркивается или уходит в открытые вопросы
              не тот слой      символ есть, но охраняет другое → назад автору

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

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

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

Движение spec-driven development уже реально. Spec Kit от GitHub, Kiro от AWS, Tessl — существует внятная карта, кто что занимает, и её стоит прочитать.

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

Так что комната не пуста. Но посмотри, что именно проверяют эти gate — в этом вся суть:

Каждая из этих проверок на слое спеки проверяет когерентность. Согласован ли документ сам с собой? Полон ли он? Не противоречит ли себе? Настоящие, полезные вопросы.

Ни одна не задаёт другой: а это правда? Переживёт ли «API уже возвращает это поле» встречу с настоящим API? Ничто в этой таблице не заземляет утверждения спеки о реальности в кодовой базе до генерации.

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

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

Так почему комната пуста? Льстивое объяснение тут же и неверное. Она пуста не потому, что это хитрая ниша, которую разглядел я один. Она пуста, потому что рано.

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

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

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

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

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

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

Что дальше:

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

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

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

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

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

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