TL;DR
Исследователи гоняли модели по циклу «найди баг → исправь» до 100 раз на одном и том же коде — без памяти о предыдущих попытках — и смотрели, что происходит с кодом на длинной дистанции.
Главная находка: модель почти никогда не говорит «всё в порядке». Даже в идеально работающем коде она находит несуществующий баг и лезет его чинить. В итоге вероятность, что правильный код после такой правки стал неправильным, оказалась выше или сравнима с вероятностью, что неправильный код стал правильным. Хуже того — модель часто застревает в петле: добавляет правку, на следующем шаге сама же откатывает её, и так по кругу до бесконечности. Особенно это происходит, когда правки точечные («замени этот кусок»), а не переписывание целиком.
Практический вывод: точечные правки провоцируют больше бесконечных циклов и порчи, чем полная переписка текста или кода целиком. А без явного условия «когда остановиться» модель будет копаться в готовом результате бесконечно, придумывая всё новые несуществующие проблемы.
Схема метода (протокол безопасной итеративной правки)
ШАГ 1: Дай модели чёткое условие "стоп" (лимит раундов или явный критерий готовности) → без него проверка идёт до бесконечности
ШАГ 2: Разреши модели прямо сказать "ошибок нет" → без этого разрешения она вынуждена находить хоть что-то
ШАГ 3: Проси переписывать целиком (весь текст/код), а не точечно патчить кусок → снижает риск цикла "исправил-откатил"
Все три шага можно объединить в одном промпте, без отдельных запросов.
Пример применения
Задача: Основатель интернет-магазина просит ChatGPT несколько раз подряд «вычитать» карточку товара на Wildberries — проверить текст на ошибки и неточности и исправить. После третьего раунда правок текст выглядит хуже, чем после первого: некоторые формулировки то появляются, то пропадают.
Промпт:
Вот текст карточки товара:
{текст}
Проверь его на ошибки (грамматика, повторы, нелогичные фразы).
Если реальных ошибок не осталось — прямо напиши "ошибок нет" и не выдумывай мелкие
правки просто чтобы что-то исправить.
Если нашёл настоящую ошибку — перепиши весь текст целиком с исправлением,
а не только фрагмент фразы.
Сделай не больше 2 проверок подряд. Если после второй проверки ты снова
"находишь" проблему — остановись и зафиксируй текущую версию как финальную.
Результат: модель либо честно скажет «ошибок нет» уже на первом-втором проходе, либо выдаст полностью переписанный текст без разрозненных патчей. Это остановит эффект «то добавил запятую, то убрал» — типичный симптом бесконечной проверки без ограничений.
Почему это работает
Когда модель просят «искать проблемы» без чётких критериев, она склонна найти хоть что-то — как корректор, которого попросили найти ошибку в идеальном тексте: он найдёт, даже если придётся её выдумать. Это и есть слабость: модель плохо умеет честно говорить «всё нормально», особенно если её несколько раз подряд просят проверить ещё раз.
Сильная сторона модели — она хорошо держит в голове весь текст целиком при полной переписке и меньше противоречит сама себе, чем когда правит кусочки в отрыве от контекста.
Явный стоп-критерий и разрешение сказать «всё ок» убирают давление «найди хоть что-то». А переписка целиком не даёт правкам противоречить друг другу, как это бывает при точечных патчах.
Рычаги управления: - Лимит раундов (1, 2, 5) → для черновика хватит 1 прохода, для важного документа можно 3-5 - Фраза «не выдумывай правки просто чтобы что-то исправить» → без неё модель почти всегда найдёт что подправить - Точечная правка vs полная переписка → для текстов и кода с сильной внутренней логикой всегда выбирай полную переписку
Шаблон промпта
Вот {текст/код}:
{содержимое}
Проверь его на ошибки. Если реальных ошибок нет — прямо напиши "ошибок нет"
и не выдумывай правки просто чтобы что-то исправить.
Если нашёл настоящую ошибку — перепиши весь {текст/код} целиком с исправлением,
а не только фрагмент.
Сделай не больше {число} проверок подряд. Если после этого лимита ты снова
"находишь" проблему — остановись и зафиксируй текущую версию как финальную.
{текст/код} — что проверяешь, {содержимое} — сам материал, {число} — сколько раундов проверки разрешаешь (обычно 1-3 достаточно).
Ограничения
⚠️ Модели в исследовании: проверено на Gemini 2.5 Flash-Lite и Qwen2.5-7B — моделях среднего уровня. На топовых моделях склонность «выдумывать баги» может быть слабее, но сама тенденция, скорее всего, сохраняется в той или иной степени.
⚠️ Без памяти о прошлых попытках: эксперимент специально устроен так, что модель на каждом шаге видит только текущую версию кода, а не историю правок. В обычном чате, где весь диалог остаётся в контексте, эффект бесконечного цикла может быть слабее — но склонность находить лже-ошибки при повторных «проверь ещё раз» скорее всего остаётся.
⚠️ Проверено на коде с объективными тестами: там есть чёткий критерий «правильно/неправильно» (тесты прошли или нет). Для текстов, где нет такого объективного критерия, риск лже-правок может быть даже выше — не с чем сверить результат.
Как исследовали
Исследователи взяли датасет CodeContests+ — решения задач по спортивному программированию на C++, среди которых есть и рабочие, и сломанные версии. Выбрали 20 задач и по 40 решений на каждую — 800 файлов кода. Дальше запускали цикл: показывали модели (Gemini 2.5 Flash-Lite или Qwen2.5-7B) код, просили найти и исправить баг, брали результат и на следующем шаге показывали заново — без памяти о прошлых попытках, до 100 раундов. Сравнивали два способа правки: переписать весь файл целиком или менять только конкретный кусок (техника, которую используют реальные AI-инструменты для кода, например Aider).
Дальше считали две вероятности: как часто сломанный код становится рабочим (repair rate) и как часто рабочий код становится сломанным (damage rate). Оказалось, что damage rate почти везде выше или сравним с repair rate — особенно при точечных правках. Ещё интереснее: многие «циклы» вообще не сходятся — модель добавляет правку, а на следующем шаге сама же откатывает её, и так по кругу.
Отдельно исследователи залезли внутрь модели Qwen2.5-7B и нашли что-то вроде внутреннего «счётчика подозрительности» — направление в активациях, отвечающее за «в этом коде есть баг». Когда они искусственно усиливали это направление, модель начинала чинить (и портить) код агрессивнее; когда подавляли — модель вообще перестала трогать код, включая реальные баги. Это подтверждает: у модели есть что-то вроде отдельной «настройки паранойи», не жёстко привязанной к тому, есть баг на самом деле или нет.
Ресурсы
«If It's Not Buggy, Don't Fix It: On the Dynamics of Iterative Bug-fixing with LLMs» — Xietao Wang-Lin (University of Warwick), Anton Isopoussu, Louis Mahon (UnlikelyAI). Датасет: CodeContests+.