Specsmaxxing: критерии приёмки как основной артефакт

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

Статья представляет собой историю выздоровления от overengineering'а. Предыдущий этап автор называет "AI-психозом" - формулировка взята напрямую из статьи HandyAI "Ваш CEO страдает от AI-психоза", но применена с самокритикой. А именно: составление сложнейших PRD/TRD, создание библиотек навыков, наём "армии" субагентов, преодоление "звукового барьера vibe-coding'а" с полуторачасовым автономным прогоном. Результат работал, но оставался неаккуратным. Диагноз: "использование AI для создания AI-обвязок для создания продуктов вместо того, чтобы просто использовать AI для создания чёртова продукта".

Момент озарения

Поворотным моментом стало небольшое наблюдение. Субагент без каких-либо подсказок начал нумеровать требования:

AUTH-1: Accepts `Authorization: Bearer <token>` header
AUTH-2: Tokens are user-scoped...
AUTH-3: Rejects with 401 Unauthorized

...и ссылаться на эти теги в реализации:

// AUTH-1
const authHeader = req.headers["authorization"];
// AUTH-2
const isAuthorized = verifyBearerToken(authHeader);
// AUTH-3
if (!isValid) return res.status(401).json({ error: "Unauthorized" });

Первая реакция автора вполне традиционна: это сильная связанность, кошмар для рефакторинга. Но при повторном осмыслении оказалось, что именно в этой связанности и суть: теги становятся навигационным индексом, чек-листом для ревьюера и артефактом, который точно показывает, где именно в кодовой базе требование реализовано или протестировано. Теги получили название: ACID (Acceptance Criteria IDs) - центральная концепция, заслуживающая вынесения в отдельную страницу acceptance-criteria-ids.

feature.yaml

В статье формат YAML позиционируется как золотая середина между неструктурированным .md (нет идентификаторов, нет машиночитаемости) и EARS / Gherkin (слишком жёсткие, утомительные в написании):

feature:
    name: imaginary-api-endpoint
    product: api
    description: ...

components:
    AUTH:
      name: Authn and Authz
      requirements:
        1: Accepts Authorization header with `Bearer <token>`
        1-1: Token must be non-expired, non-revoked
        2: Respects the scopes configured for the owner
        2-note: See `access-tokens.SCOPES.1` for complete list of supported scopes

constraints:
    ENG:
      description: Cross-cutting or under-the-hood requirements
      requirements:
        1: All actions are idempotent
        2: All HTTP 2xx JSON responses wrap their payload in a root `data` key

Схема разделяет components (функциональные требования) и constraints (сквозные ограничения). Идентификаторы представляют собой стабильные иерархические номера. Соседние элементы *-note содержат перекрёстные ссылки. Флаги deprecated и replaced_by хранят историю прямо в тексте, а не в git.

Мысленный эксперимент

Самый сильный аргумент статьи спрятан в разделе "Future Gazing". Представьте, что генерация кода стала мгновенной, бесплатной и детерминированной относительно входного промпта. Если результат вас не устраивает, вы не правите его вручную - вы дополняете промпт. В этом пределе единственное, что сохраняет долгосрочную ценность, - критерии приёмки. Спецификация.

Затем автор выстраивает хронологическую цепочку: раньше мы записывали процедуры (код), затем инварианты (юнит-тесты), затем дельты (промпты). Все три составляющие становятся "в значительной степени одноразовыми или невидимыми, хотя когда-то были главным объектом нашего внимания". Выживает только спецификация. Она и так уже существует в головах и разговорах; выбор лишь в том, записать её до отчёта об ошибке или после.

По форме это тот же аргумент, что и в статье Rawquery "average is all you need": когда артефакт дешевеет, внимание переключается на вышестоящий артефакт, который всё ещё приходится создавать человеку. Код становится дешёвым артефактом; спецификации становятся дорогим.

От specsmaxxing -> testmaxxing -> reactive

Две последующие фазы, которые намечает автор:

Testmaxxing. Когда скорость генерации кода опережает скорость чтения, узким местом становится уверенность в соответствии спецификации - поэтому ROI тестирования и наблюдаемости резко возрастает. Acai.sh сегодня закрывает только половину "от спецификации к реализации"; часть с обратной связью от QA пока находится в планах.
Реактивные фабрики ПО. Спецификации + строгий QA + надёжный CI = LLM может автономно реагировать на упавший тест или алерт без вмешательства человека. Автор замечает, что "каждая хорошо финансируемая команда разработчиков в мире прямо сейчас занята созданием собственного самописного решения для этого". Charlie Labs, botctl, superhq, flue - всё это разные попытки закрыть отдельные части этой задачи.

Раздел сравнения с аналогами

Автор даёт оценку четырём смежным инструментам (что заодно служит списком для будущего изучения):

GitHub SpecKit - охарактеризован как "vibe coding с лишними шагами". Дополняет агентов промптами и навыками, но не отслеживает соответствие в стиле ACID.
OpenSpec - отказ от него носит философский характер: OpenSpec считает, что спецификации описывают, как системы ведут себя сейчас. Acai утверждает, что спецификации описывают, как системы должны себя вести; текущее поведение преходяще.
Kiro - преобразует неструктурированный markdown в синтаксис EARS. Автору не нравятся обе крайности; feature.yaml позиционируется как середина.
Traycer.ai - использует обычные .md-файлы; Acai более требователен к формату.

Прагматические ограничения, отмеченные автором

Стабильная нумерация критически важна. Изменение нумерации в спецификации означает перепривязку ссылок в коде. Флаги deprecated и replaced_by существуют именно для этого.
Одна спецификация на каждую возможность - сквозные спецификации охватывают несколько репозиториев (frontend / backend / микросервисы), но заранее зафиксировать границы отдельной возможности требует дисциплины.
Никакого дизайна/UI в спецификациях. "Спецификации нужны для поведения, ограничений и больше ни для чего". Сначала добиться работы по спецификации, наведение лоска - в последнюю очередь.
Внедрение требует перехода на формат YAML, а также дашборда для проведения ревью (open-source версия включает опцию запуска self-hosted сервера).

Честная оценка

Самый сильный тезис статьи - вполне скромный: нумерованные критерии приёмки со ссылками в коде делают результат работы агента пригодным для ревью так, как этого не позволяет неструктурированный .md. Дашборд, рабочий процесс с push и концепция "реактивной фабрики ПО" - это сопутствующее продвижение продукта: вполне уместное для статьи, но не влияющее на полезность самих ACID. Можно перенять соглашение об идентификаторах и ссылках, не покупая ничего из остального.

Вторая ценная мысль - описание выхода из AI-психоза. Автор вслух проговаривает то, о чём каждый по-своему уже говорили Лалит, Кантрилл и Беннетт: между vibe-coding'ом и армиями агентов существует стабильная точка равновесия, и чтобы её найти, приходится выбросить массу проделанной работы.

См. также

acceptance-criteria-ids - соглашение ACID как переносимая концепция
acai - набор инструментов (CLI + сервер + дашборд)
acai-blog - блог
ceo-ai-psychosis - термин "AI-психоз", который автор заимствует и применяет к себе
ai-assisted-workflow - семишаговый процесс Барберо, близкий по духу (планирование до написания кода)
building-syntaqlite-ai - отчёт Лалита о том, что "проектирование нельзя делегировать"
clean-code-coding-agents - структура кода как дисциплина управления контекстом агента
average-is-all-you-need - тезис о том, "что приобретает ценность, когда генерация становится дешёвой"
no-silver-bullet-llms - Беннетт о структурном потолке прироста производительности от LLM
i-dont-want-your-prs - созвучное переосмысление Ценжаркевича о том, что вообще имеет смысл рецензировать