# Где граница между агентной разработкой и вайб-программированием?

> Агентную разработку от вайб-программирования отличают ответственность, ограничения, доказательства и ревью. Осваивайте агентов по пятиуровневой модели.

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

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

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

## Границу определяет ответственность, а не стиль промпта

Агентная разработка начинается, когда люди сохраняют ответственность за систему, но передают агенту ограниченную работу. Вайб-программирование начинается, когда сам сгенерированный результат становится основанием для уверенности. В одном случае команда говорит: `агент создал код, который выглядит правильно`; в другом: `критерии приемки, ревью и контроль релиза показывают, что изменение выполняет заданный контракт`.

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

В этой области часто смешивают автономность и полномочия. Автономность показывает, сколько шагов агент может сделать без вмешательства. Полномочия определяют, какими ресурсами и решениями он вправе распоряжаться. Команда может разрешить высокую автономность при очень узких полномочиях: агент меняет один сервис, запускает локальные тесты и открывает черновой пул-реквест, но не читает продакшен-секреты, не меняет биллинг, не сливает код и не выполняет деплой. Когда эти понятия путают, агенту часто выдают широкие права лишь ради меньшего числа запросов на подтверждение.

Ответственность также означает, что у изменения есть конкретный владелец. Ему не нужно проверять каждый сгенерированный токен. Но он обязан понимать ожидаемое поведение, границу риска, предъявленные агентом доказательства и способ отката. Если ревьюер не может объяснить эти четыре пункта, одобрение превращается в формальность вместо контроля.

## Вайб-программированию место в песочнице

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

Граница проходит не по факту выхода кода в продакшен. Небольшая внутренняя утилита может раскрыть данные клиентов или удалить файлы, а изменение текста в продакшене иногда почти не несет операционного риска. Оценивайте радиус поражения, обратимость, чувствительность данных и возможность проверить результат. Если ошибка может списать деньги с клиента, повредить общее состояние, раскрыть секрет или незаметно повлиять на деловое решение, импровизация вышла за пределы безопасной зоны.

У прототипа должен быть срок годности. Команды попадают в неприятности, когда пятничный эксперимент становится инфраструктурой в понедельник, потому что он уже вроде бы работает. Запишите в репозитории исходное допущение, владельца, разрешенные данные и дату удаления. Если прототип переходит в рабочую систему, заново сформулируйте критерии приемки и проведите его через те же проверки, что и любой поддерживаемый компонент. Сгенерированный код не накапливает технический долг каким-то особым образом; он лишь позволяет набирать его с такой скоростью, что общий объем легко не заметить.

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

## Исполняемый контракт ставит агенту задачу

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

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

```yaml
task: reject expired password-reset tokens
owner: payments-platform
scope:
  allow:
    - services/auth/reset/**
    - tests/auth/reset/**
  deny:
    - db/migrations/**
    - infra/**
invariants:
  - valid unused tokens keep their current response shape
  - logs never contain token values
acceptance:
  - unit test covers expired, used, malformed, and valid tokens
  - integration suite auth-reset passes
  - changed lines receive human review
escalate_when:
  - schema change appears necessary
  - public API response would change
```

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

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

Агент должен вернуть отчет о завершении, связанный с контрактом. Потребуйте список измененных файлов, проверки приемки с фактическими кодами выхода, нерешенные предположения и пропущенную работу. Фраза `все тесты прошли` дает слабое доказательство. Команда и результат вроде `make test-auth-reset`, `exit 0`, `48 passed` позволяют ревьюеру повторить проверку и заметить, когда агент запустил узкий набор тестов вместо требуемого.

## Сначала ограничьте полномочия, затем увеличивайте автономность

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

Начните с изолированной рабочей среды, чистой ветки и синтетических либо обезличенных данных. Подключайте каталоги исходников осознанно. Не допускайте в среду по умолчанию учетные данные деплоя, продакшен-базы, системы поддержки клиентов и API биллинга. Если конкретная задача действительно требует один из этих ресурсов, создайте краткосрочные учетные данные с узкой ролью и запишите причину выдачи. Удобство не оправдывает передачу постоянного токена исполнителю с вероятностным поведением.

Для командных ограничений нужна семантика, а не черный список пугающих строк. Блокировка `rm` не помешает клиенту базы данных удалить таблицу, сборочному скрипту опубликовать пакет или HTTP-запросу изменить удаленное состояние. Разделите инструменты по эффекту: чтение локального состояния, запись локального состояния, доступ к сети, изменение общего состояния и выпуск артефакта. Затем задайте политику для каждого класса.

Разумная политика по умолчанию разрешает агенту читать репозиторий, менять свою ветку и запускать детерминированные локальные проверки. Перед загрузкой зависимостей или обращением к внешнему сервису агент спрашивает разрешение. Он не может сливать код, публиковать, выполнять деплой, менять права доступа или пользоваться продакшен-учетными данными. Подтверждение человека должно относиться к точному действию, включая цель и параметры. Разрешение `запустить миграцию` слишком расплывчато; разрешение на проверенную миграцию с конкретной контрольной суммой в указанной тестовой базе дает рабочую границу.

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

## Проверяйте доказательства и поведение

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

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

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

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

Автор контракта задачи не всегда должен оставаться единственным ревьюером. Для изменений с серьезными последствиями разделите утверждение требования и реализации. Первый человек подтверждает правильность запрошенного поведения; второй проверяет, что реализация и доказательства его поддерживают. В небольших командах роли можно объединить при низком риске, но такое решение нужно принять явно, а не позволять одному человеку одобрять собственные предположения через агента.

## Быстрый агент может скрыть медленный сбой

Типичный сбой начинается со скромной на вид просьбы: добавить повторные попытки при отправке исходящих вебхуков. Агент находит HTTP-клиент, оборачивает неудачные вызовы логикой экспоненциальных повторов, пишет тесты для кодов состояния и сообщает об успехе. Дифф выглядит чисто. Целевой набор тестов проходит. Через час пул-реквест попадает в продакшен.

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

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

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

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

## Используйте пятиуровневую модель зрелости

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

1. **Уровень один, личные эксперименты.** Люди используют агентов для объяснений, одноразового кода и локальных правок. Они не раскрывают секреты и не сливают сгенерированную работу без обычного ревью. Цель состоит в базовом навыке: запрашивать планы, проверять предположения и узнавать уверенные ошибки.
2. **Уровень два, помощь в реализации.** Агенты работают над обычными задачами бэклога в сессии разработчика. Человек выбирает файлы, запускает проверки и отвечает за пул-реквест. Команда добавляет инструкции репозитория и фиксирует обязательные проверки изменения. Успех означает, что сгенерированная работа проходит тот же путь ревью, что и написанная человеком.
3. **Уровень три, выполнение ограниченных задач.** Агент получает сохраненный в репозитории контракт изменения, работает в изолированной ветке, запускает разрешенные инструменты и открывает черновой пул-реквест с доказательствами. Политики ограничивают пути, учетные данные, сеть и изменения состояния. Люди по-прежнему утверждают исключения из дизайна и каждое слияние.
4. **Уровень четыре, согласованная доставка.** Несколько агентов могут разделить планирование, реализацию, тестирование и ревью по четко заданным интерфейсам. Конвейер записывает артефакты и не дает одному агенту одобрять собственный результат. Команды разрешают изменениям с низким риском автоматически двигаться через тестовую среду после прохождения контрактных проверок, но полномочия на релиз остаются под контролем политик.
5. **Уровень пять, управляемая автономность.** Агенты ведут отдельные классы работ от поступления до наблюдаемого релиза. Для этих классов команда доказала работоспособность отката, ответственности, аудита, контроля затрат и реакции на инциденты. Люди управляют целями, архитектурой, исключениями и продакшен-риском; им не приходится следить за каждой командой.

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

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

## Измеряйте завершенные результаты, а не созданный код

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

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

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

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

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

## Сначала меняются роли, затем численность команды

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

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

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

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

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

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

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

## Условия повышения сохраняют честную автономность

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

- Может ли команда сформулировать инвариант и критерии приемки до начала выполнения?
- Может ли она политиками ограничить файлы, инструменты, учетные данные, сеть и действия релиза?
- Может ли другой инженер воспроизвести доказательства агента по репозиторию и логам?
- Может ли владелец остановить и откатить плохое изменение, а затем найти причину за требуемое время?
- Снизили ли несколько сопоставимых изменений общие трудозатраты без роста дефектов в продакшене?

Ответ `нет` не запрещает агента. Он показывает, какой контроль нужно наладить. Оставьте агента на текущем уровне, исправьте контроль и запустите еще одну типичную задачу. Такой подход не позволяет превратить успешную правку документации в основание для автономных миграций схемы.

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

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

Не ставьте целью автономный инженерный отдел. Стройте отдел, который осознанно выдает автономность, наблюдает за результатом и спокойно забирает ее обратно. Когда контракт, полномочия, доказательства, владелец и путь восстановления видны, агент выполняет инженерную работу внутри системы. Если один из элементов исчезает, команда возвращается к вайб-программированию, как бы аккуратно ни выглядел интерфейс.