Промпт замкнуло — 25 июня 2026 г. в 14:38:22.258
Промпт замкнуло В ИИ-разработке появился новый термин на смену промпт-инжинирингу, вайбкодингу и 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