Почему кодинг-агенты работают и почему ломаются

Та же модель. Та, что галлюцинировала в веб-чате, выдаёт фичу на 200 строк в Claude Code с первого раза. /goal Codex решает целый issue. Модель не стала вдруг умнее. Изменилась структура.

Почему работают

Цикл разговорного ИИ выглядит так:

LLM → человек → LLM → человек

Вся обратная связь — естественный язык. Вероятностная генерация, за ней вероятностная оценка. Точность деградирует как произведение.

Цикл кодинг-агентов другой:

LLM → генерация кода → сохранение файла → запуск теста → pass/fail → LLM
LLM → правка кода → сборка → успех/неудача → LLM
LLM → проверка типов → сообщение об ошибке → LLM

Внутри цикла стоят детерминированные шлюзы. Файловая система сохраняет ровно то, что записано. Тест — это pass или fail. Компилятор говорит «неправильно», когда неправильно. Эти элементы ненамеренно выступают в роли трещоток.

LLM — ненадёжный компонент. Но строить надёжный протокол поверх ненадёжных компонентов — основа инженерии. Фон Нейман в 1956 году математически доказал, что одного мажоритарного голосования достаточно, чтобы шумные элементы выполняли надёжные вычисления (Von Neumann, 1956). TCP строит надёжную доставку поверх ненадёжной сети. RAID строит надёжное хранение поверх ненадёжных дисков. ECC строит надёжные вычисления поверх ненадёжной памяти.

Причина, по которой кодинг-агенты работают, та же. Поверх ненадёжного LLM стоят детерминированные верификаторы (тесты, сборка, линтеры, чекеры типов). Исследование SWE-agent показало, что даже одна и та же модель демонстрирует кардинально разную производительность в зависимости от дизайна Agent-Computer Interface (Yang et al., NeurIPS 2024). Успех определяет топология, а не возможности модели.

Но почему ломаются?

Работают, сказал я. Но иногда ломаются. Почему?

Потому что трещотки, которые оказались на месте случайно, и трещотки, спроектированные сознательно — разные вещи.

Существуют зоны без трещоток

Когда агент правит код без тестов? Сборка проходит, линт проходит, но функциональность сломана. В зонах без детерминированных шлюзов LLM судит вероятностно, а вероятностные суждения деградируют как произведение.

Из 200 эндпоинтов у 180 есть тесты, у 20 нет. Агент безупречно обрабатывает 180 и тихо сажает баги в 20. Вот почему получается «почти готово, но что-то не так».

Информационность обратной связи недостаточна

Я провёл эксперимент с сортировкой 1000 слов. CPU: 0,08 мс при 100%. LLM: 438 секунд при 97,7%. Само по себе впечатляет — 97,7% чистым мышлением. Но настоящее открытие было в другом.

На тот же результат я менял только уровень обратной связи:

Обратная связь	Результат
Нет	6 ошибок (99,4%)
«Есть ошибки»	10 ошибок (99,0%) — хуже
«23 ошибки»	1 ошибка (99,9%)
«6 ошибок, вот они»	0 ошибок (100%)

Сказать только «ты ошибся» вызывает гиперкоррекцию и ухудшает результат. Указать количество — создаёт цель для поиска. Указать расположение — достигается совершенство.

Большинство агентов сегодня работают на втором уровне. Когда тест падает, они знают «что-то не так», но не передают структурную причину. Сообщения об ошибках есть, но это симптомы, а не причины.

Слепые пятна существуют, и повторы их не исправляют

В эксперименте с сортировкой LLM оставил 6 ошибок в R2. В R3 доложил «ошибок нет». В R4b снова доложил «ошибок нет». Пропустил те же 6 тем же способом.

Без подсказок, сколько ни повторяй, сходилось на 99,4%. Только когда сказали «осталось 6», наконец достигнуто 100%.

То же самое происходит с кодинг-агентами. Агент создаёт баг, делает self-review «всё нормально», и при повторной просьбе исправить — пропускает то же место. Huang et al. (2024) показали, что без внешней обратной связи самокоррекция ошибок рассуждения LLM фактически ухудшает производительность (Huang et al., ICLR 2024). Вот почему retry — не ответ. Слепые пятна — структурное ограничение вероятностной природы модели, а не недостаток усилий.

Умножение работает на масштабе

97,7% точности в цепочке дважды: 0,977² = 95,4%. Трижды: 93,2%. Десять раз: 79,2%.

Агент, правящий один файл, справляется хорошо. Но попросите рефакторить 100 файлов? Даже при 97% на шаг, 100 шагов дают 0,97¹⁰⁰ = 4,8%. Неудача фактически гарантирована.

Это математическое объяснение того, почему «vibe coding рушится на 200 эндпоинтах». В маленьких проектах число звеньев достаточно мало, чтобы вероятность держалась. В больших проектах умножение становится катастрофическим.

Что необходимо

Причины работоспособности и причины поломок указывают в одно место: наличие или отсутствие детерминированных верификационных шлюзов.

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

Что значит проектировать трещотки сознательно:

Во-первых, выявить зоны без трещоток. Код без тестов, API без схем, данные без типов. Каждое место, где агент судит вероятностно, — это уязвимость.

Во-вторых, повысить информационность обратной связи. Возвращать только pass/fail вызывает гиперкоррекцию. «Где, почему и чем фактическое отличается от ожидаемого» должно передаваться в структурированном виде.

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

LLM — замечательные генераторы. Они сортируют 1000 слов с точностью 97,7% чистым мышлением. Человек так не может. Но всё, что ниже 100%, рушится при повторении. 0,977 в квадрате — 0,954.

Кодинг-агенты работают не потому, что модель умна. Они работают потому, что внутри цикла стоят детерминированные шлюзы. Ломаются потому, что этих шлюзов нет.

Генерация может быть вероятностной. Верификация должна быть детерминированной.

Источники

Von Neumann, J. (1956). “Probabilistic Logics and the Synthesis of Reliable Organisms from Unreliable Components.” In Shannon, C.E. & McCarthy, J. (Eds.), Automata Studies, Annals of Mathematical Studies, No. 34, Princeton University Press, pp. 43-98.
Saltzer, J.H., Reed, D.P., & Clark, D.D. (1984). “End-to-End Arguments in System Design.” ACM Transactions on Computer Systems, 2(4), 277-288.
Patterson, D.A., Gibson, G., & Katz, R.H. (1988). “A Case for Redundant Arrays of Inexpensive Disks (RAID).” Proceedings of the 1988 ACM SIGMOD International Conference on Management of Data, pp. 109-116.
Hamming, R.W. (1950). “Error Detecting and Error Correcting Codes.” The Bell System Technical Journal, 29(2), 147-160.
Yao, S. et al. (2023). “ReAct: Synergizing Reasoning and Acting in Language Models.” ICLR 2023.
Shinn, N. et al. (2023). “Reflexion: Language Agents with Verbal Reinforcement Learning.” NeurIPS 2023.
Jimenez, C.E. et al. (2024). “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?” ICLR 2024.
Yang, J. et al. (2024). “SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering.” NeurIPS 2024.
Huang, J. et al. (2024). “Large Language Models Cannot Self-Correct Reasoning Yet.” ICLR 2024.
Kamoi, R. et al. (2024). “When Can LLMs Actually Correct Their Own Mistakes? A Critical Survey of Self-Correction of LLMs.” TACL, 12, 1298-1318.
Cemri, M. et al. (2025). “Why Do Multi-Agent LLM Systems Fail?” arXiv:2503.13657.
Arbuzov, M.L., Shvets, A.A., & Beir, S. (2025). “Beyond Exponential Decay: Rethinking Error Accumulation in Large Language Models.” arXiv:2505.24187.