Specification Driven Development (SDD) — фронтирный подход на весну —осень 2026 года в разработке код-агентами на базе LLM. Его практическая реализация чаще всего представляет собой обвязку вокруг код-агента, создающую дополнительную систему ограничений для направления его движения. Такая обвязка, или L2-harness, состоит из набора стандартов, навыков и спецификаций. В этой заметке вводится проблематизация подхода со спецификациями.
Мой коллега, бэкенд-разработчик Роман Русаков выдвинул тезис.
Есть такое утверждение, что SDD — это язык более высокого уровня. Типа как ООП на ассемблере. Типа по спекам потом можно создать тоже самое.
Но вот прикол: мы не видим тех мест, где нам повезло.
У нас неполные требования, агент что-то делает, где-то сделает то, что мы хотели, а где-то не то.
Мы находим не то и улучшаем спеку. Но мы не знаем о том, что было сделано правильно в результате случайности.
Поэтому второй созданный софт, по этим же спекам, будет функционально не такой же.
На что первой моей мыслью было:
Надо использовать принятие результата оператором за отправную точку. Когда он принял результат, из кода везения можно взять и вернуть все предположения на уровень спек и этим зафиксироваться.
Эта мысль была преждевременна. Хотя сам тезис Романа заслуживает отдельного внимания в эпоху тотальной ставки на SDD-подходе код-агентной разработки.
Аксиома Русакова
Обратная связь в SDD-подходе асимметрична и касается только тех мест, где машине не повезло
Три следствия
- Измеренное качество спецификации завышено.
- Перегенерация не идемпотентна по поведению.
- Цикл самообманывается — каждый принятый результат повышает доверие к спеке, не повышая её определяющей силы
Зазор творчества
Спецификация всегда недоопределена, и машина молча заполняет её пробелы своим выбором
Место, которое спецификация не определяет, а пройти без него нельзя, — это умолчание. Машину умолчание не останавливает: она выбирает сама и оператору об этом не сообщает. Совокупность таких скрытых выборов, осевших в коде и поведении системы, — это зазор творчества.
Умолчаний хватает даже в спецификации, которую внимательно написал человек, знающий предметную область. Каждое машина закрывает сама. Если её выбор совпал с ожиданием, оператор принимает результат. Это и есть место, где повезло: в коде лежит решение, которого нет в спецификации, и выглядит оно как замысел.
Чем меньше у оператора конкретных ожиданий к результату, тем больше работы уходит в зазор творчества.
Почему это не компилятор
Выбор компилятора не меняет поведения программы, выбор агента в умолчании меняет
Компилятор тоже выбирает: раскладывает переменные по регистрам, переставляет инструкции. Семантика языка полностью задаёт поведение программы, и все выборы компилятора остаются внутри неё. У спецификации на естественном языке такой семантики нет. Два разных ответа машины на одно умолчание дают на одних и тех же данных разное поведение.
Детерминированный агент сделает выбор в умолчании повторяемым, но принятым от этого выбор не станет. Спецификация его по-прежнему не определяет, и он поменяется вместе с моделью, её версией или соседним контекстом. У вероятностной модели он меняется и от прогона к прогону. В режиме one-shot, где код каждый раз генерируется по спецификации с нуля, любая её правка разыгрывает все умолчания заново: поменяли одно требование — могло поменяться и то, чего правка не касалась. Это второе следствие аксиомы.
Три феномена
Подъём удачи в спецификацию при приёмке действует только на умолчание. У зазора творчества есть источники, которые спецификацией не лечатся
Даже если машина сама назовёт свои выборы, а оператор поднимет принятое в спецификацию, закроется только нежелательный эффект от умолчания. Остаются ещё три нежелательных феномена.
Дрейф. Спецификация место определяет, а машина отклоняется от её исполнения. Формула задана, вариаций у неё нет, а агент время от времени сочиняет разные строчки вычисления. На мелочах это видно сразу: сегодня код без комментариев, завтра с ними, и сдвигается нумерация строк; сегодня операнды в одну строку, завтра в две; отступ то в два пробела, то в четыре. Хуже, когда в какой-то из дней машина идёт другим путём, и генерация падает с ошибкой исполнения. Определённость требования не влечёт определённости исполнения, и норма, поднятая в спецификацию, от дрейфа не защищает.
Эрозия. Машина теряет часть содержания, правя уже принятое. Она заново собирает вещь из того, что понимает применительно к текущей задаче, и содержание, причина которого не записана рядом, выглядит для неё лишним. Попросили поменять одно условие — попутно переписан соседний фрагмент, и из него выпало то, зачем он был так устроен. Правку заказывал человек, поэтому расхождение с прежним выглядит ожидаемым, и потерянное попутно неотличимо от заказанного. Эрозии подвержено всё, что правит машина, включая саму спецификацию. Последствия копятся: каждая правка стартует с уже обеднённого состояния.
Наплыв. Машина переносит структуру и стиль из всего, что видит, — кода, текстов, схем, примеров — без прямого требования о переносе. Наплыв питает остальные феномены: заполняет умолчание, увлекает исполнение в дрейф, помогает эрозии вытеснить прежнее. Пример, приложенный к спецификации как подсказка, становится образцом целиком, вместе со случайными чертами, которые к задаче не относятся. Так же образцом незаметно становится случайное соседнее решение, а скопированная форма сама становится образцом для нового копирования, и загрязнение растёт по репозиторию снежным комом. Дашь модели лишнего — она начнёт клонировать это до одурения.
По результату эти феномены неразличимы. Различить их можно, только вернувшись к спецификации — было ли место определено — и к прежнему состоянию — было ли там содержание раньше.
Удачи живут в коде
Неподнятые удачи существуют только в коде, и машина может переписать их при любой правке
Полная пересборка по спецификации дорога, и в долгой работе систему правят поверх существующего кода: машина получает текущую версию и заказ, результат становится следующей точкой отсчёта.
Удачи из зазора творчества, которые никто не поднял в спецификацию, живут только в коде. Зеркала в требованиях у них нет, и переписать их машина может, ничему в спецификации не противореча. Агент технически способен править весь доступный код при самом локальном заказе, поэтому эрозия выходит за пределы заказанного и забирает поведение, которое уже устраивало человека.
Приёмка ловит не всё
Приёмка — единственный внешний судья результата, но она видит один прогон и только то, что наблюдалось
Тесты, написанные машиной по той же спецификации, судьёй быть не могут: в них ошибки того же рода. Остаётся человек. Дрейф на другом прогоне и эрозию в месте, куда человек не смотрел, приёмка не ловит. Сводные цифры выглядят правдоподобно при многих ответах на одно умолчание: ошибка растворяется в них и проявляется позже, когда по ним начинают принимать решения.
Машина производит артефакты в разы, а то и на порядки быстрее, чем человек способен их просмотреть. В большой системе даже внимательная вычитка изменений не гарантирует, что важная потеря будет замечена. Сплошное сличение возможно, но оно замедляет пару «человек — машина» до скорости человека.
Что остаётся
Спецификация в SDD не становится новым исходным кодом. Удача в ней следов не оставляет, и доверие к ней растёт быстрее её определяющей силы. Умолчание машина заполняет молча, дрейф отклоняет исполнение от определённого, эрозия забирает принятое, наплыв разносит случайное как образец. Всё это оседает в коде, который правят дальше, и проходит мимо приёмки, которая видит только увиденное.
Опыт one-shot генераций по спецификациям дал два пункта, которые машине нельзя доверить: выбор решения там, где способов действия несколько, и отделение важного от неважного. Первое — это умолчание, второе — эрозия.
Открытым остаётся вопрос: как удержать поведение системы, если объём внимания человека не растёт вместе с объёмом того, что производит машина?
P.S.
Заинтересовавшихся этим отрывком предлагаю прочесть исходные тезисы размышлений на тему феноменов и путей их исправления
К контрмерам от потери устойчивости ИИ-обвязки, работающей на базе спецификаций