Vibe-engineering

Vibe-engineering - практика, описанная Джошем Бличером Снайдером (Josh Bleecher Snyder) в claude-is-not-a-compiler: инженер оставляет принятие решений за собой, а задача агента - сделать эти решения быстрее, обоснованнее и доступнее сразу на всех уровнях системы. Это контрастирует с vibe-coding, где агенту отдаются сами решения.

Граница

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

Claude здесь был не просто компилятором. Я ни разу не отдавал задачу целиком, позволяя агенту принимать пачку решений ради реализации. Это и есть vibe-coding. Claude был скорее вертикально интегрированным ресурсом, мультикомпилятором.

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

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

Почему здесь важно слово "вертикальный"

В модели с компилятором агент помещался на один уровень стека, между инженером и компилятором, переводя естественный язык в код. Такой взгляд недооценивает возможности, ведь реальный выигрыш в том, что модель способна обсуждать стратегию, продукт, архитектуру, код и машинный код без организационных издержек. Человеческим организациям трудно работать сквозь разные слои не только из-за нехватки знаний, но и из-за стоимости встреч, согласований и сокрытия информации - тех самых вещей, которые позволяют им масштабироваться. У агента ничего этого нет, поэтому межуровневая консультация, требовавшая отдельной встречи, превращается в обычный промпт.

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

Как устроена эта практика

Характерные черты на примере DNS-сервера из claude-is-not-a-compiler:

• Самые верхнеуровневые стратегические и архитектурные решения люди принимают напрямую, лично, до запуска агентов.
• Агент используется в первую очередь как исследователь: стандартные архитектурные решения, тонкости предметной области, прошлые уязвимости и сбои, отвергнутые альтернативы, сценарии отказов, стратегия тестирования.
• Реализация создаётся параллельно несколько раз, а результаты сравниваются на расхождения (differential-spec-analysis). Именно в расхождениях скрываются незаданные вопросы и неявные решения.
• По мере нахождения ответов они ужимаются в краткие письменные инструкции - "документ шрамов" (scar-tissue document), который накапливается по мере итераций и остаётся жить дальше.
• Проверка выполняется на уровне работы системы, а не построчно: тесты, сквозные (end-to-end) тесты, shadow-режим перед выводом в production.

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

"Документ шрамов"

Долговечный результат здесь - не код, а накопленный свод правил. Он пишется сжато, как для агентов, так и для людей, фиксирует важные решения на всех уровнях и рассчитан на то, чтобы пережить исправления багов и постоянную смену кода. В случае с DNS-сервером документ пересобирали три полные итерации, пока его не стало эмпирически достаточно, чтобы провести агента по всем значимым решениям.

Это та же логика, что и нумерованные критерии приёмки в acceptance-criteria-ids или аргумент о спецификации как основном артефакте в specsmaxxing, только пришедшая с противоположной стороны: не "напиши спецификацию заранее", а "дай спецификации выкристаллизоваться из решений, которые пришлось принять по ходу дела".

В чём предмет споров

Очевидное возражение состоит в том, что это просто vibe-coding с более удачным брендингом. Честный ответ заключается в том, что граница держится на утверждении, которое может проверить только сам автор, - что решения действительно принимал он. Со стороны фраза "я прочитал ничтожно мало кода" выглядит одинаково в обоих случаях. Это та же проблема ненаблюдаемых усилий, что и в agent-principal-agent-problem и credibility-as-slop-test, только применённая к собственному рассказу инженера о своей работе.

Прямые возражения: reviewing-ai-code утверждает, что пропускная способность ревью ограничивает объём сгенерированного кода, который вообще можно ответственно выпускать, а cult-of-vibe-coding рассматривает нечтение кода как ошибку и симптом сбоя, а не метод. peril-of-laziness-lost описывает механизм, на который указали бы оба текста: ограничения по человеческому времени раньше заставляли выбирать простые решения, тогда как vibe-engineering снимает это ограничение, заявляя при этом, что способность суждения никуда не делась.

Близкие, но отличающиеся подходы: control-the-ideas-not-the-code приходит к тому же выводу (контролируй архитектуру, пропускай строки кода), но обретает уверенность через расспросы одной модели о её решениях, тогда как vibe-engineering опирается на многократную параллельную генерацию и сравнение вариантов. danluu-ai-coding-testing предлагает третий путь - тестирование настолько плотное, что ревью становится попросту ненужным.

Сам Бличер Снайдер прогнозирует, что этот спор скоро потеряет актуальность: "в ближайшем будущем vibe-engineering станет просто... инженерией".

Связанные страницы

• claude-is-not-a-compiler - первоисточник и разобранный пример
• differential-spec-analysis - метод, позволяющий выявить незаданные вопросы и неявные решения
• cult-of-vibe-coding, simonw-vibe-coding-agentic - собственно vibe-coding
• agent-principal-agent-problem - коллапс ревью, внутри которого существует этот подход
• specsmaxxing, acceptance-criteria-ids - семейство подходов "спецификация как главный артефакт"
• rakyll-coding-agents - та же граница, проведённая с организационной стороны: агенты снимают издержки на координацию, но ценой потери стимула обучать джуниоров
• short-leash-ai-method - противоположный полюс той же оси, где инженерная дисциплина заключается в чтении каждого diff'а, а не в предварительной спецификации