ИИ-агенты в редакторах кода всё чаще воспринимаются как волшебная кнопка: напиши запрос — получи готовый код. Но за фасадом удобства скрываются десятки мелких сбоев, которые накапливаются и превращают разработку в испытание для нервной системы. За 100+ часов работы с Composer 2.5 в Cursor я собрал типичные проблемы, которые встречаются и в других моделях этого класса. Эта статья — не жалоба, а попытка структурировать опыт и дать практические шаги, чтобы сохранить продуктивность и рассудок.

Почему работа с агентом похожа на отладку чужого кода

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

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

Типичные проблемы и их признаки

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

  • Потеря контекста. Агент забывает предыдущие инструкции или путает файлы, особенно если задача затрагивает несколько модулей. Признак: внезапное изменение стиля кода или использование не тех импортов.
  • Галлюцинации API. Модель уверенно вызывает несуществующие методы или передаёт неверные аргументы. Признак: код компилируется, но падает с ошибкой «undefined method».
  • Избыточные правки. Вместо точечного изменения агент переписывает весь файл, добавляет лишние комментарии или форматирование. Признак: диффы раздуваются, ревью становится сложным.
  • Игнорирование ограничений. Вы просите не трогать определённые файлы или не добавлять зависимости, но агент всё равно это делает. Признак: в проекте появляются новые пакеты или изменённые конфиги.
  • Зацикливание. Агент повторяет одни и те же действия, не продвигаясь к цели. Признак: в логах видно многократные попытки исправить одну и ту же ошибку.

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

Как выстроить процесс, чтобы не сойти с ума

Хорошая новость: большинство проблем решается дисциплиной и правильной настройкой. Вот конкретные шаги, которые я внедрил и которые помогли снизить раздражение.

  • Дробите задачи. Одна задача — одно изменение. Чем меньше scope, тем проще проверить результат и откатить. Вместо «сделай авторизацию» — «добавь эндпоинт логина с валидацией email».
  • Фиксируйте контекст в промпте. Указывайте ключевые файлы, используемые библиотеки и ограничения. Например: «Не меняй package.json, используй только существующие зависимости».
  • Проверяйте диффы построчно. Не принимайте изменения вслепую. Настройте отображение diff и просматривайте каждое изменение, особенно в критичных файлах.
  • Используйте контроль версий. Коммитьте перед запуском агента, чтобы можно было легко откатиться. Это банально, но спасает нервы.
  • Ограничивайте автономность. В Cursor можно настроить, чтобы агент спрашивал подтверждение перед выполнением команд или изменением файлов. Да, это медленнее, но безопаснее.
  • Ведите журнал проблем. Записывайте, какие промпты приводят к сбоям, а какие работают стабильно. Через неделю у вас будет личная база знаний.

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

Критерии выбора: когда агент оправдан, а когда лучше без него

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

  • Задача шаблонная и хорошо описана. Например, создание CRUD-эндпоинта по существующему образцу. Агент справится быстро.
  • Нужно исследовать незнакомую библиотеку. Агент может сгенерировать примеры использования, но их придётся проверять.
  • Задача требует глубокого понимания бизнес-логики. Здесь агент часто ошибается, и время на исправления превышает выигрыш.
  • Критична безопасность или производительность. Лучше писать самому или использовать строгие линтеры и тесты.
  • У вас есть время на ревью. Если дедлайн горит, а проверить некому, агент может навредить.

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

Примеры из практики: что пошло не так и как исправили

Один из показательных случаев: я попросил агента добавить кэширование для функции, которая делает запросы к внешнему API. Агент предложил использовать библиотеку, которой не было в проекте, и добавил её в зависимости. При этом он не учёл, что в проекте уже есть собственный модуль кэша. Пришлось откатывать изменения и переписывать промпт с явным указанием: «Используй только существующий модуль cache из src/utils/cache.js». После этого задача решилась с первого раза.

Другой пример: при рефакторинге компонента агент изменил пропсы, которые использовались в других файлах, но не обновил их. В результате приложение упало. Решение — перед запуском агента я добавил в промпт список файлов, которые нельзя менять, и попросил явно перечислить все затронутые файлы. Это заставило модель быть внимательнее.

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

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