Вайб-инжиниринг требует больше дисциплины, а не меньше

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

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

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

Вайб-инжиниринг начинается с исполняемого контракта

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

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

task: retry invoice delivery
behavior:
  retry_on: [timeout, connection_reset, http_502, http_503]
  attempts: 3
  max_elapsed_ms: 8000
invariants:
  - reuse the existing idempotency key
  - never retry http_400 or http_401
  - preserve the public function signature
proof:
  - unit tests for each retryable status
  - integration test proving one invoice is created
  - log field retry_reason contains no request body

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

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

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

Скорость ИИ увеличивает масштаб непроверенных ошибок

Код от ИИ опасен тем, что непроверенное предположение быстро распространяется на множество файлов. Модели не обязательно выдумывать API, чтобы нанести ущерб. Она может применить разумный локальный шаблон там, где скрытое системное ограничение делает его небезопасным.

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

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

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

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

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

Контекст репозитория должен быть явным и актуальным

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

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

Не превращайте этот файл в справочник сотрудника. Агенты теряют важные ограничения в длинном тексте так же, как люди. Записывайте команды в точном виде и поясняйте необычные правила через ошибку, которую они предотвращают. Фраза «не обращайтесь к базе из HTTP-обработчиков, потому что повторы транзакций находятся в сервисном слое» дает границу и причину. Агент сможет изучить сервисный слой вместо того, чтобы выдумывать еще один шаблон.

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

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

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

Тесты должны атаковать поведение, а не повторять патч

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

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

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

Запустите узкий тест, затем соседний набор, после чего статические проверки. Сохраните команды и результат в записи о работе. Достоверный отчет агента выглядит так:

$ make test-invoice
42 passed, 0 failed
$ make lint
0 errors, 0 warnings
$ make verify-format
format checks passed

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

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

Secure Software Development Framework от NIST разделяет ревью читаемого человеком кода и тестирование исполняемого кода, включая автоматический анализ и проверку человеком. Здесь это различие существенно. Чистый результат статического анализа не доказывает правильность бизнес-поведения, а успешный сквозной тест не покажет небезопасный запрос в редкой ветке. Вайб-инжинирингу нужны оба вида доказательств, выбранные по уровню риска.

Проверяйте diff, не доверяя его автору

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

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

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

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

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

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

Доступ к инструментам должен соответствовать цене ошибки

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

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

Одни запросы разрешений проблему не решают. Разработчик, который видит двадцать обычных запросов, начнет подтверждать их ритмично, не вчитываясь. Объединяйте предсказуемые безопасные действия в проверенную политику, а прерывания оставляйте для значимых пересечений границы. Запрос должен объяснять точную команду, цель и причину. Фраза «Разрешить shell?» слишком широка для ответственного выбора.

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

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

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

Старым системам нужны более узкие границы агента

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

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

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

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

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

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

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

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

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

Сопровождение требует понятного репозитория

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

Спросите, уменьшает ли изменение словарь репозитория или расширяет его. Если один модуль называет клиента account, другой tenant, а патч вводит workspace, модель могла построить три чистых компонента вокруг одного запутанного понятия. Переименуйте сущности в пользу термина предметной области вместо документирования синонимов.

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

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

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

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

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

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

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

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

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

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

Team & AI Audit помогает найти, где инженерный процесс допускает безопасное сокращение команды, а где отсутствие тестов, ответственности или контроля продакшена делает такой шаг безрассудным. Экономию нужно искать во всей системе доставки, а не в количестве кода на одного человека.

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