Вам понадобятся железные нервы для работы с ИИ-агентами

Здесь речь больше пойдет про Composer 2.5 в Cursor. Возможно, этих проблем нет в opus-5.5 или gpt-6.1-sol-pro-max-ultra-thinking-fast. Но, например, в gpt-6.1-luna все из перечисленных проблем есть. И многие из этих проблем я наблюдал раньше в gpt-5.5 и opus-4.6. Есть ли они в новых ИИ моделях, которые вышли недавно, я не знаю.

Что мне нравится в Composer 2.5: лимиты и скорость.

Для сравнения возьмём 2 одинаковые подписки за 20$ в GPT и Cursor. 5-часовой лимит при использовании gpt-6.1-sol у меня заканчивается за несколько запросов. Если я прошу его поменять пару строк в readme файле, это расходует 10% лимита. Если я прошу его поменять что-то в большой кодовой базе, весь лимит заканчивается на прочтении десятков файлов даже без написания кода.

Но ведь в GPT есть тариф за 100$, который даёт в 5 раз больше лимитов. И на сколько мне их хватит? У меня сложные монорепо проекты. Для правок в одном сервисе нужно прочитать десятки файлов в других и несколько скиллов. Если тариф за $20 расходуется на прочтении 20 файлов, то лимит за $100 закончится на чтении 100 файлов?

Поэтому я не использую Sol, а использую Luna. Но она очень медленная. В сравнении с Composer 2.5 она медленнее в десятки раз.

Поэтому я не использую GPT Luna, а использую Composer 2.5. Он очень быстрый и очень дешёвый. И за эту скорость и экономию я получаю трату своего времени и нервов. Какие-то из этих проблем я встречал в Deepseek и других открытых моделях. В каких-то моделях есть одни проблемы и нет других. Количество и частотность проблем меняются даже при использовании одной модели в зависимости от фазы луны.

Ниже приведён список проблем, которые я обнаружил за 100+ часов работы с Composer в Cursor.  

Удаление

Агент пишет код, меняет десятки файлов. Я начинаю проверять код, и происходит такой диалог:

— Зачем здесь эта функция?
— Вы правы. Эта функция здесь не нужна. (Удаляет функцию и меняет много файлов)
— Зачем ты её удалил?
— Вы правы, я не должен был удалять эту функцию. Возвращаю обратно. (Опять меняет много файлов)

При этом ответ на вопрос, зачем нужна эта функция, я так и не получил.

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

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

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

Ещё если я его прошу сделать рефакторинг кода, например, переименовать метод в 50 файлах, он может удалить все комментарии, которые найдет в этих файлах. Что к рефакторингу метода вообще не имеет отношения.

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

А ещё при выполнении задачи он может убрать важный параметр в конфиге или в методе, который вообще к задаче не относится. На вопрос, зачем он это убрал, он утверждает, что ничего не убирал. Нужно явно просить его посмотреть git diff, потому что сам он не догадается.  

Просто сделай как в референсе

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

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

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

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

Тестирование

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

Что делает ИИ агент: сразу меняет код. Затем создаёт тест, который НЕ падает, и пишет мне, что задача выполнена. В итоге я не могу проверить, упал бы тест до исправления кода или нет. И исправил ли этот код что-то или нет.

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

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

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

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

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

Был ещё такой случай. Я попросил агента написать тест на добавление данных через API запрос. Он долго что-то пытается сделать, но тесты у него никак не становятся зелёными. И он решает просто не вызывать API роут в тестах, а напрямую записать данные в базу. Тесты действительно начали проходить, данные добавляются в базу, но никакой API запрос не выполняется.  

Невозможность поменять стиль ответов

В последние месяцы я всё чаще замечаю новый шаблон построения предложений. Вот примеры:

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

В каждом предложении два фрагмента в кавычках, построенных по одному стилистическому шаблону. Я не знаю, откуда появился этот шаблон, но я не видел его раньше. А сейчас так общаются нейросети, и я замечаю этот стиль в статьях и видео. Может, это улучшенная версия “Это не X, это Y”? Хотя здесь не совсем антитезы.

Сколько бы я ни пытался изменить правила и скиллы для агентов, они продолжают использовать этот приём. Более того, Composer взял худшее из этих двух приёмов и теперь пишет мне такое:

Это не “API не включается”. Это “фронтенд не может подключиться”.

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

Я “подключил API” к сервису.
Сервис “запускается”, но не может “обработать” входящие запросы.
Я добавил “проверку состояния” перед отправкой запроса.

Я устал читать такой текст от него. А если указать ему на это, происходит такой диалог:

— В правилах запрещено использовать кавычки в тексте. Почему ты снова их использовал?
— Вы правы, я не должен был использовать кавычки. Теперь вы мне об этом указали, и я больше никогда не буду использовать кавычки.
— Но твоя память не переносится между чатами.
— Вы совершенно правы. Чтобы я всегда следовал этому правилу в новых чатах, его нужно перенести в самое начало списка.

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

Конец статьи

Теперь вы знаете, что вас ждёт, если вы захотите использовать Composer 2.5 в Cursor.

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