Одна и та же модель. Та самая, что галлюцинирует в веб-чате, в Claude Code поднимает 200-строчную фичу с первого раза. /goal в Codex решает issue целиком. Модель не стала вдруг умнее. Изменилась структура.
Почему работает
Цикл диалогового AI выглядит так:
LLM → человек → LLM → человек
Обратная связь полностью на естественном языке. За вероятностной генерацией следует вероятностная оценка. Точность деградирует мультипликативно.
Цикл кодинг-агента устроен иначе:
LLM → генерация кода → сохранение файла → запуск тестов → pass/fail → LLM
LLM → правка кода → сборка → успех/неудача → LLM
LLM → проверка типов → сообщение об ошибке → LLM
Внутри цикла встроен детерминированный шлюз. Файловая система сохраняет ровно то, что записано. Тест — либо pass, либо fail. Компилятор говорит «неправильно», если неправильно. Всё это непреднамеренно выполняет роль храповика.
LLM — unreliable component. Но строить reliable protocol поверх unreliable component — основа инженерии. TCP создаёт reliable delivery поверх unreliable network. RAID создаёт reliable storage поверх unreliable disk. ECC создаёт reliable computation поверх unreliable memory.
Кодинг-агент работает по той же причине. Поверх unreliable LLM поставлен deterministic verifier (тесты, сборка, линтер, проверка типов). Причина успеха — не производительность модели, а topology.
Но почему тогда ломается
Сказано: работает. Но порой ломается. Почему?
Потому что случайно встроенный храповик и осознанно спроектированный — не одно и то же.
Существуют участки без храповика
Что если агент правит код без тестов? Сборка проходит, линт проходит, а функциональность сломана. На участках без детерминированного шлюза 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 решает «всё в порядке», при повторной попытке пропускает то же место. Retry — не решение. Слепая зона — структурное ограничение, вытекающее из вероятностной природы модели, а не недостаток усердия.
На масштабе работает умножение
Два последовательных шага с точностью 97,7%: 0,977² = 95,4%. Три — 93,2%. Десять — 79,2%.
Агент отлично правит один файл. Но рефакторинг на 100 файлов? Даже если каждый шаг — 97%, после 100 шагов: 0,97¹⁰⁰ = 4,8%. Провал практически гарантирован.
Это математическое объяснение того, почему «vibe coding ломается на 200 эндпоинтах». В маленьком проекте цепочка короткая, и вероятность держится. В большом — умножение действует разрушительно.
Что необходимо
Причина работоспособности и причина поломки указывают в одну точку: наличие или отсутствие детерминированного верификационного шлюза.
Нынешние агенты опираются на случайно встроенные храповики (тесты, сборка, линтер). Если проектировать их осознанно — система станет сильнее.
Что значит осознанно проектировать храповик:
Во-первых, выявить участки без храповика. Код без тестов, API без схемы, данные без типов. Каждое место, где агент судит вероятностно, — уязвимость.
Во-вторых, повысить информативность обратной связи. Если возвращать только pass/fail — это провоцирует перекоррекцию. Нужно структурированно передавать «где, почему и чем результат отличается от ожидаемого».
В-третьих, встраивать детерминированные шлюзы между звеньями цепочки. Десять шагов за один раз — и умножение разрушительно. Но если после каждого шага фиксировать храповиком — деградация сбрасывается.
LLM — поразительный генератор. 1000 слов отсортированы чистым мышлением с точностью 97,7%. Человеку такое не под силу. Но всё, что ниже 100%, при повторении разрушается. 0,977 в квадрате — уже 0,954.
Кодинг-агент работает не потому, что модель умна. А потому, что внутри цикла есть детерминированный шлюз. Ломается — потому что этого шлюза нет.
Генерация может быть вероятностной. Верификация должна быть детерминированной.
Связанные статьи
- Ratchet Pattern — Как заставить агентов доводить дело до конца — Структура и принципы паттерна храповика
- IQ модели менее важен, чем топология обратной связи — Структура обратной связи определяет производительность
- Ограничения — это контракты — Рациональные ограничения освобождают системы
- filefunc — Один файл, одна концепция — Нативная структура кода для LLM
- Мышление первыми принципами с ИИ — Как думать вместе с ИИ