« Loop engineering » : новая дисциплина или переупаковка cron-задач?

Термин "monte" устоялся, расследование Pragmatic Engineer приходит к выводу, что это смесь триггеров, cron-задач и некачественных LLM. Остаётся принципиальный вопрос: кто обладает надёжностью цикла наблюдение-решение-действие, движимого LLM?

Факт

The Pragmatic Engineer (Гергely Orosz) публикует 14/07/26 расследование о термине «loop engineering», который возвращается в лексикон команд по ИИ. Его вывод, как резюмируется в начале статьи: под этим словом скрывается смесь триггеров, cron-задач, оркестровки LLM и «slop» — а также элемент моды.

Наше мнение

Слово не новое. То, что оно в себя включает, — уже чуть новее: когда система повторяет в цикле наблюдение → решение → действие, подпитываемое LLM, кто несет ответственность за устойчивость этого цикла? Не модель, у которой нет состояния между ходами. Не классический DevOps, который не разбирается в тонкостях недетерминированности. Появляется новая ниша: инструментировать прогоны, сдерживать отклонения, управлять идемпотентными повторными попытками, измерять стоимость за ход, предусматривать откат, когда решение затрагивает внешнюю систему. Эти темы уже освещаются SRE для агентов — просто лексика пытается их обозначить, что скорее признак принятия, чем моды.

На заметку

Настоящий сигнал — не изобилие инструментов с упоминанием «loop» на их лендинговых страницах. Это будут публичные постмортемы, которые напрямую говорят о «loop failure» — отклонениях, шторме повторных попыток, дорогостоящих циклах — а не об «галлюцинациях». В этот день дисциплина будет состоявшейся.