Vibe Coding против Agentic Engineering: что утверждается в новой белой книге Google об SDLC

От слогана до технической документации

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

Примерно через шестнадцать месяцев Google опубликовал 50-страничный технический отчёт под названием «Новый процесс разработки с использованием Vibe Coding», написанный Адди Османи, Шубхамом Сабуу и Сократисом Картакисом. Он детальный и чётко структурированный, а его выводы резки: Vibe Coding был подходящим инструментом для прототипов, однако постепенно негативно влияет на производственные системы, и многие команды этого не замечают, поскольку ущерб накапливается постепенно. В следующих разделах рассматриваются аргументы отчёта, чёткие границы его подхода и последствия для тех, кто будет использовать ИИ-агентов в 2026 году.

Почему Vibe Coding сработал и где он достиг предела

Vibe Coding стал популярным, потому что снизил порог входа в разработку. Прототипы создавались за несколько минут, неинженеры могли собирать рабочие инструменты, а время от появления идеи до готового кода сократилось с дней до часов. Это ценно, и отвергать это — проявление инженерного снобизма. Однако проблемой никогда не был сам порог; проблема — потолок возможностей.

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

Причина кроется в структуре. Метод Vibe coding был создан для быстрого запуска функций, а не для соблюдения требований к корректности на уровне производственных систем, и это разные цели. Смешивание этих подходов и приводит к современным проблемам. В белой книге предлагается предоставить командам соответствующую терминологию и рамки для того, чтобы они перестали их смешивать.

Спектр с одним фактором разделения

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

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

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

Модель — не главная переменная

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

Модель — это лишь одна из составляющих. Остальные элементы, а именно промпты, инструменты, правила работы с контекстом, среды выполнения, подагенты и механизмы отслеживания, образуют инфраструктуру, и поведение агента во многом зависит от этой инфраструктуры, а не от самой модели. Два примера из статьи подтверждают это. На тестовой платформе Terminal Bench 2.0 одна команда смогла поднять агента для программирования с места за пределами топ-30 до топ-5, изменив исключительно инфраструктуру. В другом исследовании LangChain правки системных промптов, инструментов и промежуточного программного обеспечения при неизменной модели позволили улучшить результаты агента на 13,7 баллов.

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

Инжиниринг контекста заменяет инжиниринг промптов

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

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

Лучшим решением здесь являются «навыки агента»: структурированные, переносимые пакеты процедурных знаний, которые загружаются только тогда, когда они нужны для выполнения задачи. Вместо того чтобы загружать специализированные знания в системный промпт, навыки позволяют агенту оставаться легким универсалом, превращаясь в специалиста при необходимости. Файл AGENTS.md, хорошо регулирующий этот баланс, может выглядеть следующим образом:

# Project: PaymentService API

## Architecture
- REST API, Node.js, PostgreSQL
- Never modify /src/core/billing without explicit approval

## Agent Skills (load on demand)
- skill:stripe-integration → load when task involves payments
- skill:database-migrations → load when task involves schema changes

## Hard Constraints
- No hardcoded credentials
- All new endpoints require integration tests before merge

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

Ловушка 80%

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

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

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

Режимы руководителя и оркестратора

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

Режим оркестратора находится на более высоком уровне. Разработчики устанавливают цели, передают их агентам и проверяют полученные результаты, не наблюдая за построчным формированием кода. Агенты работают параллельно в фоновых средах тестирования иногда в течение нескольких часов и возвращают запросы на внесение изменений. Разработчик периодически проверяет результаты и при необходимости корректирует действия агентов.

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

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

Вопрос экономики

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

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

Для одного разработчика, занимающегося прототипированием или побочным проектом, метод vibe coding явно превосходит по стоимости. Не требуется защита производственной системы, и объем накопленных задолженностей никогда не достигает опасного уровня. Команды достигают этой точки раньше, чем ожидалось. Пять инженеров, использующих метод vibe coding в течение трех месяцев, могут легко потерять треть своих ресурсов на отладку и доработки, которых можно было бы избежать с помощью систематической проверки. Инфраструктура типа агентов окупает свои затраты, если ее внедрять до того, как задолженность превысит критический уровень.

Что рассматривается в статье и чего — нет

Данная статья не является презентацией продукта. Это документ-контекст, причем более удобный, чем большинство других, поскольку его основные утверждения можно проверить. Эффект «узды» действительно существует и поддается измерению, как показывают приведенные тесты. Проблема 80% действительно существует и усугубляется по мере того, как сотрудники берутся за более сложную работу. А смена роли от руководителя к координатору уже происходит во всех крупных инженерных организациях.

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

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