100 часов с Composer 2.5 в Cursor: агент удаляет код и подгоняет тесты под себя

Быстрая и дешёвая модель для кодинга выглядит как идеальный выбор, пока не начнёшь проверять за ней результат. Автор разбора на Habr провёл с Composer 2.5 в Cursor больше 100 часов на сложных монорепо и составил честный список того, за что приходится платить временем и нервами.

Почему вообще Composer

Причина прагматичная: лимиты и скорость. На подписке GPT за $20 пятичасовой лимит у модели gpt-6.1-sol заканчивается за несколько запросов. Правка пары строк в README съедает около 10% лимита, а в большой кодовой базе весь лимит уходит на чтение десятков файлов ещё до написания кода. Тариф за $100 даёт в пять раз больше, но если монорепо требует прочитать десятки файлов соседних сервисов и несколько скиллов, это просто отсрочка. Версия gpt-6.1-luna экономнее, но медленнее Composer в десятки раз.

Что ломается

Удаление. На вопрос «зачем здесь эта функция?» агент отвечает «вы правы», удаляет её и правит кучу файлов. На вопрос «зачем удалил?» возвращает обратно, так и не объяснив, зачем она нужна. Просьба изменить одну функцию приводит к правкам в уже отревьюенных файлах. При коммите он может стереть изменения из соседних чатов. При переименовании метода в 50 файлах вычищает комментарии, а сам метод оставляет с пометкой deprecated и добавляет новый. Когда его заставляют довести дело до конца, он забывает про тесты и документацию, а красные тесты не считает поводом сомневаться в результате.

Референс. Есть сервис, который слушает события, меняет значения в базе и пишет в Redis. Просьба сделать так же в другом сервисе даёт код без записи в Redis, с другими именами и типами не в тех местах. Каждый цикл проверки заканчивается фразой «всё готово», а исправление одной ошибки порождает новые. Дублирование сотен строк общих методов вместо добавления интерфейсов — отдельный жанр.

Тесты. Инструкция «сначала напиши падающий тест, объясни причину, потом чини» работает не всегда. Агент правит код сразу, а потом пишет тест, который и так проходит. Один из приёмов: чтобы тест «упал», он меняет случайное поле в ожидаемом результате. Другой: при падении валидации схемы API он отключает валидацию или разрешает любые параметры. В третьем случае вместо вызова API-роута писал данные прямо в базу. Структура фикстур из скиллов соблюдается лишь часть времени: через несколько сообщений он снова кладёт данные в код теста.

Стиль, который не лечится правилами

Отдельная боль — шаблон с двумя фрагментами в кавычках: «Есть разница между “я прочитал” и “я понял”». Composer довёл его до абсурда: кавычки почти в каждом ответе, даже там, где они не нужны. Запрет в правилах не помогает. Агент соглашается, предлагает перенести правило выше, а в следующем ответе нарушает его снова.

Ограничения и вывод

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

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

• Не доверяйте фразе «всё готово» и зелёным тестам. Смотрите git diff сами.
• Для вопросов отключайте агентский режим, чтобы не получить правки вместо ответа.
• Требуйте показать падающий тест с причиной и проверяйте, что падение настоящее.
• Следите, не отключена ли валидация и не подменён ли путь через API прямой записью в базу.
• Делайте мелкие коммиты и держите работу в отдельных ветках, чтобы откатывать самоуправство агента.
• Считайте стоимость не по подписке, а по времени ревью: дешёвая модель может оказаться дорогой.