Сценарий знаком всем, кто дал агенту доступ к репозиторию. Первая неделя — восторг: фичи собираются за вечер, тесты пишутся сами. Вторая — лёгкое беспокойство: правки стали задевать соседние файлы. Третья — вы открываете проект и не узнаёте его. Три реализации одного и того же хелпера, конфиг в четырёх местах, тесты, которые проверяют существование функции, а не её поведение.
Это не «плохая модель». Это предсказуемый результат того, как агент принимает решения — и он лечится дисциплиной, а не сменой инструмента.
Механика деградации: агент не помнит, он реконструирует
Ключевое, что стоит понять: у агента нет памяти о вашем проекте между сессиями. Каждый раз он заново реконструирует картину по кускам, которые успел прочитать. Если он не нашёл ваш существующий `formatDate`, он напишет свой — и будет прав по своей логике, потому что задачу решил.
Дальше включается компаунд. Второй агентский проход видит уже две реализации и не понимает, какая каноническая. Он пишет третью — «правильную». Через десяток итераций у вас не код, а археологический слой. Причём каждый отдельный коммит выглядит разумно; катастрофа собирается только на дистанции.
Второй усилитель — асимметрия усилий. Написать новый файл агенту дешевле, чем разобраться в старом. Он всегда предпочтёт дописать, а не переиспользовать, если вы явно не потребуете обратного.
Приём первый: сузить область правки до боли
Самая эффективная привычка — не давать задачу в формате «почини авторизацию». Давайте её в формате «в файле `auth/session.ts`, в функции `refreshToken`, поправь обработку истёкшего рефреша; другие файлы не трогай».
Разница радикальная. Широкая формулировка даёт агенту право на самостоятельную интерпретацию — и он ею пользуется. Узкая превращает его из архитектора в исполнителя, а архитектором остаётесь вы. Для вайбкодинга это неприятная новость: именно в архитектурных решениях агент ошибается чаще всего, но именно их так соблазнительно делегировать.
Практический критерий: если после правки `git diff --stat` показал файлы, которых вы не называли, — это не «агент проявил инициативу», это сигнал откатиться и переформулировать.
Приём второй: карта проекта, которую агент читает первой
Заведите в корне файл с правилами: где что лежит, какие хелперы уже есть, что запрещено дублировать, каким соглашениям следовать. Большинство агентских инструментов читают такой файл автоматически.
Что туда писать по делу: - список «канонических» модулей с одной строкой назначения («даты — только через `lib/date.ts`»); - запреты («не добавляй новые зависимости без явной просьбы», «не создавай файлы в корне»); - команды проверки («после правки прогони `npm test` и линтер»); - решения, которые уже приняты и не обсуждаются («стейт — в url, не в контексте»).
Это единственный способ дать агенту память между сессиями. Файл на 40 строк экономит недели разгребания.
Приём третий: маленькие коммитабельные диффы
Инструмент, который делает одну огромную правку на пятнадцать файлов, плохо масштабируется даже с сильной моделью — вы физически не отревьюите такой дифф внимательно и начнёте пропускать. Требуйте от агента работать шагами: одна задача — один осмысленный дифф — прогон тестов — коммит.
Побочный эффект приятный: когда что-то ломается, вы откатываете один шаг, а не рабочий день.
Приём четвёртый: тесты, которые проверяют поведение
Агенты обожают писать тесты, которые ничего не проверяют: «функция существует», «возвращает не undefined». Такой тест зелёный всегда и не ловит ни одной регрессии.
Простой фильтр при ревью: если тест нельзя сломать, изменив логику функции, — он бесполезен. Требуйте кейсов с конкретными входами и ожидаемыми выходами, включая граничные: пустой массив, отрицательное число, отсутствующее поле.
Что остаётся человеку
Здоровое разделение получается такое: агент отлично делает то, что вы уже умеете, но делать лень — обвязку, тесты по образцу, миграции, рефакторинг по чёткому правилу. Плохо — то, чего вы сами не понимаете: выбор архитектуры, границы модулей, стратегию данных.
Если поймали себя на мысли «пусть он решит, как это устроить, я потом разберусь» — это и есть момент, после которого через две недели начнётся тот самый археологический слой. Решите сами, а исполнение отдайте.
