Почему ваш агент никогда не останавливается Image: AI generated

Хвастовство 24/7

«Я гоняю агента двадцать четыре часа в сутки».

Эту фразу часто можно увидеть в X. Как будто чем дольше работает агент, тем больше он делает. Как будто человек становится продуктивнее, если не спит.

Но перед этой фразой возникает не восхищение, а вопрос.

«Почему он до сих пор не закончил?»

Здоровая система — это та, что умеет останавливаться

Я поручил агенту написать тесты для 527 функций. Результат:

автономный агент:  выполнил 40 / 527 и объявил «всё готово»
CLI-цикл:          прошёл 527 / 527 до конца и завершился

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

TODO → написать тест → измерить покрытие → PASS/DONE → следующая → ... → всё выполнено → стоп

finite. measurable. monotonic. Поэтому он сходится. Поэтому он останавливается.

Способность остановиться — не слабость. Это признак здоровья.

Три причины, по которым агент не останавливается

Если агент работает долго, обычно дело в одном из трёх.

1. Слабый верификатор

"looks good"
"seems better"
"more scalable"
"clean architecture"

Всё это не критерии сходимости. Это субъективные суждения. go test возвращает pass/fail, но кто выносит вердикт о «clean architecture»? Другой LLM? Это всё равно что спрашивать у пьяного друга: «Я пьян?».

Эмпирика это подтверждает. LLM-судьи для оценки кода смещаются даже на поверхностных вариациях семантически эквивалентного кода — оценки завышаются или несправедливо занижаются (Moon et al. 2025), а модель в 58,19 % случаев прогибается под собеседника и меняет собственный ответ (SycEval, Fanous et al. 2025). «Looks good» не имеет отношения к корректности. Более того, слабый критерий не просто не даёт остановиться — когда измерение становится целью, измерение ломается (закон Гудхарта; Manheim & Garrabrant 2018), и способные к рассуждению модели вместо честного решения задачи взламывают саму процедуру верификации (Bondarenko et al. 2025).

Без критерия сходимости нет конца.

2. Нет границ задачи

"улучши кодовую базу"
"сделай архитектуру чище"
"продолжай оптимизировать"

Это задачи без условия завершения. Даже человек-разработчик с такими целями будет блуждать бесконечно. У агента ничего не меняется. «Улучшение» — это направление, а не пункт назначения.

3. Энтропия превышает скорость исправления

Самый частый и самый коварный паттерн.

Внося правки, агент добавляет абстракции. Вставляет уровни косвенности. Создаёт ненужные обобщения. Код будто бы «становится лучше», но на деле новая энтропия растёт быстрее, чем верификатор успевает её устранять.

сегодня создаёт абстракцию → завтра снова её убирает → послезавтра снова добавляет

Это и есть non-monotonic optimization. Кажется, что движение вперёд, но это топтание на месте. Похоже на вечный двигатель, но он лишь потребляет энергию. В данном случае энергия — это токены.

Крупномасштабная эмпирика фиксирует этот дрейф. Внедрение Cursor повысило краткосрочную скорость, но предупреждения статического анализа и сложность кода неуклонно росли, и именно это накопление стало главной причиной долгосрочного замедления (He et al. 2025, 807 open-source репозиториев). В более чем 300 тысячах коммитов, написанных ИИ, 22,7 % внесённых проблем дожили в виде технического долга до последней версии (Liu et al. 2026). Исправление не поспевает за энтропией.

Это не задача поиска, а задача удовлетворения ограничений

Здесь проявляется фундаментальная разница во взглядах.

«Чем дольше гоняешь агента, тем лучше результат» — это взгляд на разработку ПО как на задачу поиска (search problem). Ожидание, что долгое исследование широкого пространства приведёт к лучшему решению.

Но разработка ПО по своей сути — это задача удовлетворения ограничений (constraint satisfaction problem).

  • типы должны совпадать
  • тесты должны проходить
  • покрытие должно быть достигнуто
  • схема должна соответствовать
  • правила линтера должны соблюдаться

Когда все эти ограничения удовлетворены — конец. «Искать дальше» не нужно. Определить ограничения, удовлетворить их и остановиться. Вот и всё.

Код — это уже machine-checkable domain. Компилятор, тайпчекер, тесты, покрытие, линтер, валидация схемы — всё это детерминированные верификаторы. Раз эти верификаторы существуют, зачем заставлять агента искать бесконечно?

Исследования обучения указывают в ту же сторону. Если использовать детерминированные верификаторы вроде юнит-тестов как награду — verifiable reward — корректность кода оказывается выше, чем при открытой генерации (CodeRL, Le et al. 2022; RLTF, Liu et al. 2023). Верификатор — не инструмент для сужения поиска. Это свидетельство того, что задача изначально была не поиском, а удовлетворением.

Условия хорошего цикла

Хороший агентный цикл замыкается в пять шагов:

1. Определение задачи  — что нужно достичь (механически проверяемая цель)
2. Ограничение области — одна единица за раз (функция, эндпоинт, файл)
3. Символьная проверка — детерминированный инструмент выносит pass/fail
4. Сходимость          — при прохождении дальше, при провале повтор с обратной связью
5. Завершение          — когда не осталось пунктов, стоп

В этой структуре LLM отвечает только за шаг 3 (генерацию). Всё остальное делает машина. Особенно важно, что «конец» определяет машина. Если доверить решение о завершении LLM, услышишь «всё готово» на 40/527.

Эксперименты указывают туда же. Если приделать к LLM самокритику (self-critique), производительность на задачах рассуждения и планирования наоборот рушится, и резко улучшается лишь при подключении внешнего надёжного верификатора (Stechly et al. 2024). Внутренняя самокоррекция без внешней обратной связи проваливается, а иногда после «исправления» становится только хуже (Huang et al. 2023). У того, что завершение не доверяют LLM, есть причина.

creative writing и код — это разные вещи

Есть одно исключение. Не все области таковы.

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

Но код — другое дело. Код — это мир, уже наполненный детерминированными верификаторами. В этом мире долгое блуждание (wandering) — это не поиск, а дрейф (drift).

Вопрос

Сколько часов уже работает ваш агент прямо сейчас?

Он сходится или дрейфует?

Способен ли он остановиться?

А если способен, то почему он до сих пор не остановился?

Связанные статьи

Что почитать ещё (внешнее)

  • Designing agentic loops — Simon Willison. Чтобы агентный цикл сам себя проверял и останавливался, нужны чёткий критерий успеха и проходящий набор тестов — конструктивная пара к этой статье.
  • Building Effective Agents — Anthropic. Кодинг идеален для агентов потому, что ответ можно проверить автоматизированными тестами — детерминированный верификатор становится сигналом к остановке.
  • Termination logic is the underrated design problem in agentic AI systems — Glen Rhodes. Ключевое проектное решение — не модель получше, а измеримое условие завершения; автор предостерегает от «confidence laundering», когда гладкий вывод маскирует несходимость.
  • Harness engineering for coding agent users — Birgitta Böckeler, Thoughtworks. Надёжность рождается не из модели, а из обвязки детерминированных инструментов (computational controls) — в отличие от выводимого ИИ контроля рассуждениями.
  • Reward Hacking in Reinforcement Learning — Lilian Weng. «Когда измерение становится целью, оно перестаёт быть хорошим измерением» — техническое изложение механизма, по которому слабый верификатор как награда подталкивает к геймингу прокси.
  • Context Rot: How Increasing Input Tokens Impacts LLM Performance — Chroma. Чем больше входных токенов накапливается, тем хуже становится вывод — механическая причина, по которой цикл с повторами «добавить-убрать-снова добавить» оказывается не самокоррекцией, а самоусилением.
  • Vibe Coding Will Destroy Your Codebase (But You’re Probably Not Doing It) — Ariel Perez. ИИ усиливает существующий rigor — при низком rigor он ускоряет хаос; практический взгляд на феномен, когда энтропия обгоняет исправление.

Источники

Завершение · пределы самоверификации

  • Stechly et al. “On the Self-Verification Limitations of Large Language Models on Reasoning and Planning Tasks” (2024, arXiv:2402.08115)
  • Huang et al. “Large Language Models Cannot Self-Correct Reasoning Yet” (2023, arXiv:2310.01798)

LLM-as-judge · ненадёжность самокритики

  • Gu et al. “A Survey on LLM-as-a-Judge” (2024, arXiv:2411.15594)
  • Moon et al. “Don’t Judge Code by Its Cover: Exploring Biases in LLM Judges for Code Evaluation” (2025, arXiv:2505.16222)
  • Fanous et al. “SycEval: Evaluating LLM Sycophancy” (2025, arXiv:2502.08177)

Дрейф · рост сложности ИИ-кода

  • He et al. “Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects” (2025, arXiv:2511.04427)
  • Liu et al. “Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild” (2026, arXiv:2603.28592)

Verifiable reward · генерация кода на основе верификатора

  • Le et al. “CodeRL: Mastering Code Generation through Pretrained Models and Deep Reinforcement Learning” (2022, arXiv:2207.01780)
  • Liu et al. “RLTF: Reinforcement Learning from Unit Test Feedback” (2023, arXiv:2307.04349)

Reward hacking · specification gaming

  • Bondarenko et al. “Demonstrating Specification Gaming in Reasoning Models” (2025, arXiv:2502.13295)
  • McKee-Reid et al. “Honesty to Subterfuge: In-Context Reinforcement Learning Can Make Honest Models Reward Hack” (2024, arXiv:2410.06491)
  • Manheim & Garrabrant. “Categorizing Variants of Goodhart’s Law” (2018, arXiv:1803.04585)
  • Amodei et al. “Concrete Problems in AI Safety” (2016, arXiv:1606.06565)