Грядущий цикл: человек как режиссер машинного кода
Матвей Борис Черни заметил: «Я больше не даю промпты Claude, у меня крутятся циклы, которые сами себя промптят и решают что делать. Моя работа, писать циклы».
Теория Арминда развивает эту идею дальше. Внутри каждого ИИ-агента уже крутится цикл: модель вызывает инструменты, читает результаты, вызывает новые инструменты. Но есть второй, внешний цикл, цикл хозяйства: задача в очередь, машина пытается, останавливается, хозяйство решает продолжать ли, менять контекст ли, или отправить другой машине.
Это работает удивительно хорошо. Но есть проблема: когда машина пишет код, не контролируемая человеком, она пишет оборонительно-нервный код. Слишком много fallback-ов вместо сильных инвариантов, слишком много локальных защит от невозможного, слишком мало архитектурной ясности. И если каждую итерацию добавляется еще одна маленькая защита, система постепенно становится менее понятной, хотя выглядит более робастной.
Арминд указывает на домены, где это работает хорошо: porting больших кодовых баз (как перевод Bun из Zig в Rust), performance benchmarking (машина пробует варианты, отсеивает), security scanning, любое исследование. Общее: либо трансформация существующего кода, либо код временный и экспериментальный.
Но для долгого кода, который живет годами? Это чувствует себя опасно. Особенно если это инфраструктура или данные. Разработчик хочет понимать систему, объяснить её человеку без помощи машины. Современные модели этого не дают.
Еще хуже: оптимизироваться из этого может быть невозможно. Атакующие уже используют машины в циклах против защиты. Конкуренты будут использовать их для скорости. Если не запустить собственный цикл, проиграешь. Это создает зависимость от LLM API и когнитивную зависимость: код, написанный машинами, может быть понят только машинами.
Ключевые факты
- Два уровня циклов: внутри агента (инструменты) и снаружи (оркестр задач); второй становится нормой
- Машинный код слишком оборонительный и нелокальный в рассуждениях, защиты вместо инвариантов
- Работает для портирования, бенчмарков, security research; не работает для долгого кода с требованием понимания
- Конкурентное и безопасностное давление заставит даже противников циклов включить их
- Риск когнитивной зависимости: код, поддерживаемый только машинами, теряет человеческое понимание
Почему это важно
Граница между ИИ как инструментом и ИИ как системой управления кодом стирается. Если большинство кода пишется машинами в циклах, а люди только смотрят со стороны, меняется сама природа software engineering. От детерминированной машины к живому организму, который диагностируют как врача: видишь симптом, гадаешь про корень, пробуешь лечение.
Кому это важно
Разработчикам, ведущим долгие проекты (инфраструктура, ядро систем, критичные данные). Startup-ам, которые считают на скорость. Security-специалистам, которые видят, что attackers уже в цикле. Младшим разработчикам, которых могут научить плохим привычкам, если циклы без контроля.
Как это применить
Для экспериментов, портирования, бенчмарков, включить циклы, машина это делает лучше. Для долгого кода, держать человека в середине: машина предлагает, человек решает, машина выполняет. Документировать инварианты явно, чтобы машина их видела.
Можно ли доверять
Арминд, опытный разработчик, работал с Claude Code и агентами. Пишет на основе наблюдений, но не первооткрыватель (ссылается на Борис Черни, Daniel Stenberg). Его опасения про оборонительный код подтверждаются распространенной критикой LLM-кода.
Риски и подводные камни
Полная зависимость от LLM API; если доступ ограничить (sanctions, cost) или модели слабеют, системы, построенные на циклах, могут стать нежизнеспособными. Код становится менее понятен человеку, даже если работает. Младшие разработчики привыкают думать только машинным способом, локально, оборонительно.
«I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.»
— Борис Черни