Агентная инженерия и вайб-кодинг: в чём разница

Коротко

Вайб-кодинг и агентная инженерия (agentic engineering, агентный инжиниринг) — два режима работы с одним и тем же инструментом: ИИ-агентом в редакторе. Разница не в модели, не в подписке и не в размере проекта. Она в одном: существовал ли проверяемый план до того, как агент начал писать код, и есть ли способ проверить результат после.

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

Агентная инженерия — сначала спецификация, потом план, потом атомарные задачи, потом код, и на каждом переходе человек ставит галочку. Агент здесь исполнитель с ограничениями: файл правил (AGENTS.md, CLAUDE.md), тесты как приёмка, обязательное ревью диффа, узкий контекст.

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

Два разных ответа на один вопрос

Термин «вайб-кодинг» придумал Андрей Карпатый в феврале 2025 года, и придумал его честно — как описание режима, в котором ты «полностью отдаёшься вайбу, забываешь, что код вообще существует», принимаешь все правки подряд и копипастишь текст ошибки обратно в чат, не читая. Он же сразу оговорил область применения: одноразовые проекты выходного дня. Саймон Уиллисон позже сузил определение до одной строки — «создание софта с помощью LLM без чтения кода, который она пишет». Не «с помощью ИИ», а именно «без чтения».

«Агентная инженерия» появилась как ответ на очевидную проблему: агенты научились писать код быстрее, чем люди научились проверять. Формулировка тут более размытая, потому что термин пришёл из практики, а не из твита. Рабочее определение: вайб-режим — разговорный цикл, где человек в центре и решает по ощущению; агентный — целеориентированный цикл, где агент планирует, исполняет, тестирует и итерирует внутри заранее заданных рамок.

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

Где проходит граница

Граница — не по инструменту. Claude Code, Cursor, Codex, Kiro одинаково пригодны для обоих режимов. Граница проходит по трём артефактам, которые либо есть до старта, либо их нет.

Спецификация. Не «сделай форму регистрации», а описание того, что считается корректным поведением: какие поля, что валидируется, что происходит при повторной отправке, куда идут данные. Подход, в котором спека — источник правды, а код производная, оформился в отдельную методологию: spec-driven development. У GitHub есть открытый тулкит spec-kit под лицензией MIT, который навязывает четыре фазы через слэш-команды: /speckit.specify → /speckit.plan → /speckit.tasks → /speckit.implement, плюс /speckit.constitution для принципов проекта. Работает с 30+ агентами.

Правила проекта. Файл, который агент читает перед каждой задачей: команды сборки и тестов, стиль, запреты. Стандарт де-факто — AGENTS.md, открытый формат под управлением Agentic AI Foundation (Linux Foundation), его понимают Copilot, Cursor, Zed, Aider, Codex и другие; на сайте заявлено больше 60 000 репозиториев с таким файлом. Формат — обычный markdown, обязательных полей нет.

Критерий приёмки. Тест, линтер, типы, ручной чек-лист — что угодно, что даёт ответ «да/нет» без вашего вкуса. Без него ревью диффа превращается в чтение по диагонали, а это ровно вайб-кодинг с лишним шагом.

Если все три есть — вы в агентной инженерии, даже если агент работает автономно час подряд. Если нет ни одного — вы вайб-кодите, даже если пишете промпты на две страницы.

Таблица различий по практике

Строка про «где ломается» — самая честная. Агентная инженерия не бессмертна: спека, которую перестали править вместе с кодом, вредит сильнее, чем её отсутствие, потому что агент верит ей больше, чем реальности.

Когда нужен агентный подход, а когда хватит вайб-кодинга

Вайб-кодинг рационален, когда цена ошибки меньше цены дисциплины. Это лендинг на выходные, скрипт для разовой выгрузки, внутренняя утилита на одного человека, проверка гипотезы «а вообще взлетит?». Здесь спека — накладные расходы: пока вы её пишете, дешевле было собрать три варианта и выбросить два.

Агентный подход нужен, когда выполняется хотя бы одно:

• код увидит кто-то кроме вас;
• к нему вернутся через месяц (в том числе вы сами);
• есть данные пользователей — то есть появляются требования 152-ФЗ, и «агент как-то сохранил» перестаёт быть приемлемым ответом;
• задача не влезает в одно окно контекста;
• над проектом работает больше одного человека.

И честное ограничение, которое почти нигде не пишут: агентная обвязка не гарантирует ускорения. В рандомизированном исследовании METR 16 опытных опенсорс-разработчиков решали 246 реальных задач в своих же репозиториях. С доступом к ИИ-инструментам они тратили на 19% больше времени, чем без. При этом заранее ожидали ускорения на 24%, а после эксперимента всё ещё считали, что ускорились на 20%. Выборка маленькая и специфическая — люди на своих зрелых кодовых базах, — но вывод переносится: субъективное ощущение скорости и реальная скорость расходятся, и меряться надо часами до мерджа, а не ощущениями.

Второе ограничение — деньги. Полный цикл «спека → план → задачи → реализация» съедает заметно больше токенов, чем один промпт, потому что агент несколько раз перечитывает контекст. Тарифы стоит смотреть на официальных страницах: у Kiro, например, на июль 2026 бесплатный тариф даёт 50 кредитов в месяц, Pro — 20 $ за 1000 кредитов, доп. кредиты по 0,04 $ (kiro.dev/pricing). Отдельная российская специфика: карты российских банков у большинства таких сервисов не проходят, и вопрос оплаты решается через посредников — закладывайте это в план до того, как перестроите весь процесс под конкретный инструмент.

Как перейти от одного к другому

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

1. Заведите AGENTS.md в корне. Пять разделов: что за проект, как собрать, как прогнать тесты, стиль, чего делать нельзя. Держите его коротким — файл на 1000 строк агент читает хуже, чем на 80.
2. Добейтесь одной команды для проверки. npm test, make check — неважно. Пока проверка не запускается одной строкой, агент не сможет проверять себя сам.
3. Введите правило «дифф не мерджится непрочитанным». Самое неприятное и самое полезное. Именно здесь вайб-кодинг заканчивается формально.
4. Начните писать спеку для задач дороже одного дня. Не для всех — для дорогих. Формат: что делаем, что не делаем, как поймём, что готово.
5. Разбивайте на атомарные задачи. Одна задача — один дифф, который можно откатить отдельно. Если агент трогает восемь файлов в четырёх слоях, план был плохой.
6. Только потом подключайте автоматизацию — subagents, MCP-серверы, параллельные ветки. Инструменты усиливают процесс, а не заменяют его; обзор серверов есть в разделе MCP.

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

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

Частые вопросы

Агентный инжиниринг и agentic engineering — это одно и то же?

Да, это калька. В русских текстах встречаются три варианта: «агентный инжиниринг», «агентная инженерия», «агентная разработка». Устоявшейся нормы пока нет, все три означают одно — дисциплинированную работу с ИИ-агентами, где спецификация и приёмка первичны по отношению к генерации кода. Не путайте с «агентными системами» (multi-agent systems) — там речь про архитектуру продукта, а не про процесс разработки.

Можно ли считать агентной инженерией работу с одним агентом без мультиагентных схем?

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

Spec-driven development — обязательная часть агентного подхода?

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

Что делать, если в проекте нет тестов и написать их некому?

Заменить критерий приёмки на то, что есть: типы, линтер, ручной чек-лист из 5–10 пунктов, скриншот-сравнение. Это хуже тестов, но принципиально лучше, чем ничего: у агента должен быть ответ «да/нет», не зависящий от вашего настроения. Параллельно попросите агента покрывать тестами тот код, который он трогает, — так покрытие растёт по мере работы, а не отдельным героическим спринтом.

Агентная инженерия ускорит мою работу?

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