Промпт замкнуло В ИИ-разработке появился новый термин на смену промпт-инжинирингу, вайбкодингу и harness engineering. Теперь модно заниматься loop engineering: не писать запросы агенту, а создавать циклы, которые будут писать запросы за вас. Термин популяризировал Петер Штайнбергер, создатель OpenClaw. По его формулировке, разработчикам больше не следует самостоятельно промптить агентов. Нужно проектировать системы, которые будут делать это автоматически. В loop engineering человек описывает цель, правила и критерии готовности. Дальше система сама находит задачи, раздаёт их агентам, проверяет результат и запускает следующий круг. Например, каждое утро она просматривает новые баги и падения тестов. Один агент выбирает проблему, второй исправляет её в отдельной ветке, третий проверяет код по спецификации. Затем система запускает тесты, открывает pull request, обновляет задачу в трекере и сохраняет результаты работы. Руководитель Claude Code в Anthropic Борис Черни утверждает, что уже работает примерно так. Один его агент постоянно ищет способы улучшить архитектуру кода, другой — повторяющиеся абстракции, которые можно объединить. Они сами создают pull request, а поскольку кодовая база всё время меняется, цикл никогда не заканчивается. Технически для этого нужны расписание или триггер, инструкции о проекте, доступ к GitHub и другим сервисам, изолированные рабочие ветки, несколько специализированных агентов и внешняя память. Модель забывает предыдущий запуск, а файл в репозитории или карточка в Linear — нет. Если убрать новый ярлык, loop engineering похож на CI/CD-конвейер, только часть жёстко прописанных скриптов заменили вероятностными исполнителями. Один агент планирует, другой пишет, третий проверяет, а цикл повторяется, пока тесты не пройдут или не закончится бюджет. Но точка приложения инженерии действительно меняется. Раньше нужно было хорошо сформулировать очередной запрос. Теперь приходится проектировать всю систему: какие данные видит агент, какие действия ему разрешены, кто проверяет результат, где хранится состояние и по какому условию работа должна остановиться. Бывший директор Google Cloud AI Эдди Османи выделяет здесь три риска. Первый — верификация: сообщение агента «готово» остаётся утверждением, а не доказательством. Второй — долг понимания: чем больше система выпускает кода, который разработчик не писал и не читал, тем хуже он понимает собственный проект. Третий — когнитивная капитуляция, когда человек перестаёт принимать решения и просто соглашается с результатами автоматики. Поэтому потолок такой системы определяется не количеством агентов, а пропускной способностью человека, который должен разобрать их pull request. Автономность масштабирует производство кода быстрее, чем способность этот код проверять. @anti_agi