Привет, я Игорь, пишу бэкенд. За последний год ИИ-агент из игрушки превратился в рабочий инструмент: даёшь задачу — он сам лезет в файлы, правит код, гоняет тесты и приносит готовый результат. Экономит часы. Но у этой лёгкости есть обратная сторона, о которой редко предупреждают: агент без границ ведёт себя как очень старательный джун, которому дали ключи от всего проекта и сказали «сделай хорошо». И вот он делает хорошо — по своему разумению — в тех местах, куда его никто не просил.
Расскажу, почему агент опасен без рамок и как выстроить эти рамки так, чтобы он оставался помощником, а не источником ночных инцидентов. Без хайпа и без страшилок — просто то, что реально работает у меня и у команды.
Почему агент опасен без границ
Языковая модель по своей природе стремится быть максимально полезной. Дай ей широкую формулировку — и она «поможет» шире, чем нужно. У этого есть три предсказуемых сценария, которые бьют по проекту.
Тихий дрейф архитектуры. Ты попросил починить одну функцию, а агент заодно переписал импорты по всему файлу, поменял сигнатуру метода и обновил синтаксис «на посвежее». По отдельности всё выглядит разумно, но вместе это тихо ломает договорённости, на которых держится код.
Расползание задачи. Границы задачи размываются: правка в одном модуле тянет за собой «а тут заодно отрефакторим», и вот уже диф на пятьсот строк вместо десяти. Ревьюить такое невозможно, а значит, оно уедет в прод как есть.
Уверенная чушь. Там, где агенту не хватило информации, он не остановится и не спросит — он заполнит пробел статистически правдоподобным умолчанием. Выглядит убедительно, компилируется, а на проде выясняется, что токены обновления теперь живут в памяти и слетают при рестарте пода.
Хороший результат от агента — это не про то, чтобы вежливо попросить. Это про управление ограничениями: чем чётче рамки, тем меньше сюрпризов.
Что задавать: рамки вместо надежды
Главный сдвиг в голове простой: агенту нужно не описание мечты, а диагностический снимок реальности и жёсткие берега. Вместо «у нас сервис авторизации, надо бы его причесать» — конкретика: «есть сервис на NestJS в src/auth/auth.service.ts, он выдаёт JWT; обновление токена сейчас держит состояние в массиве в памяти и теряет его при рестарте». Чем точнее ситуация, тем меньше агент додумывает.
Ситуация, цель и запреты
Я держу в голове четыре обязательных куска любого задания агенту.
Ситуация. Где мы сейчас: пути к файлам, версии стека, текущее поведение и его ограничения. Не рассказ о продукте, а снимок кода как он есть.
Что читать, а что менять. Явно разделяю: вот эти файлы — только для чтения, справочно; вот эти — цель правок. Иначе агент решает сам.
Критерий готово. Проверяемая цель: какие тесты должны позеленеть, что именно считается решением. «Сделай лучше» — это не критерий, это приглашение к дрейфу.
Список запретов. Самое недооценённое. Прямым текстом: не менять публичные сигнатуры, не обновлять зависимости, не форматировать строки, которых не касался, не удалять «неиспользуемый» код. Запрет работает надёжнее, чем надежда, что агент сам догадается.
Маленькие шаги и тесты
Даже с идеальным заданием не давайте агенту откусывать большой кусок за раз. Правило, которое спасает: одна задача — один диф, который можно прочитать глазами за пару минут. Большой рефакторинг разбивается на цепочку мелких шагов, и после каждого вы смотрите результат, прежде чем идти дальше. Так ошибка ловится на десяти строках, а не на пятистах.
Второй рубеж — тесты. Если критичный код уже обложен зелёными тестами, агенту гораздо труднее тихо сломать соседнее: сломал — тест покраснел, вы увидели. Если тестов нет, честный первый шаг — попросить агента написать тесты на текущее поведение, убедиться, что они проходят, и только потом менять логику. Это не занудство, это страховка, которая окупается на первом же спасённом вечере.
Ревью и git — последний рубеж
Никакие рамки не отменяют главного: код, который написал агент, читаете вы. Не «выглядит норм», а построчно — что изменилось и зачем. Если не понимаете, почему появилась строка, это не повод её принять «на доверии»: это повод спросить агента или откатить. Агент не несёт ответственности за инцидент в три часа ночи — несёте вы.
И держите git наготове как ремень безопасности. Отдельная ветка под задачу, частые мелкие коммиты, осмысленные сообщения. Пошло не туда — не разбираете руины на боевом сервере, а делаете git reset и заходите заново с более узкой формулировкой. Возможность в один шаг вернуться к рабочему состоянию превращает эксперименты с агентом из риска в нормальную инженерную практику.
Короткий чек-лист
Перед тем как отпустить агента в кодовую базу, пробегитесь по списку.
1. Задал границы: какие файлы можно трогать, какие только читать.
2. Дал снимок реальности: пути, версии, текущее поведение.
3. Сформулировал проверяемый критерий «готово».
4. Явно перечислил запреты — что трогать нельзя.
5. Разбил работу на маленькие шаги, один диф за раз.
6. Прикрыл критичное тестами до того, как менять логику.
7. Прочитал diff построчно, а не «на доверии».
8. Держу отдельную ветку и готов к git reset.
Это не бюрократия ради бюрократии. Это ровно те привычки, которые и хорошего живого разработчика удерживают от глупостей, просто теперь они особенно важны.
Агент — мощный инструмент, и он тем полезнее, чем яснее берега, которые вы ему задаёте. Границы, тесты, ревью и здравый смысл превращают «страшную нейросеть, которая всё переломает» в очень быстрого напарника, за которым вы приглядываете. А как у вас: вы уже пускаете агента в реальный проект — и что стало вашим главным правилом, чтобы он не наломал дров?
Пока нет комментариев