TL;DR
· В июне 2026 года несколько практиков AI-программирования почти одновременно предложили Loop Engineering. Stripe уже использует Minions для еженедельного слияния более 1300 AI-сгенерированных PR.
· Этот метод больше не полагается на последовательные подсказки человека, а позволяет системе автоматически обнаруживать задачи, передавать их, проверять, сохранять состояние и переходить к следующему витку.
· Надёжность по-прежнему зависит от независимых оценщиков, жёстких шлюзов и ручной проверки; долг проверки и снижение понимания могут обратно усилить риски.

Недавно инженер Anthropic опубликовал 11-страничный документ о «циклической инженерии агентных систем», поместив Loop Engineering после Prompt Engineering, Context Engineering и Harness Engineering, рассматривая его как ключевой метод для следующего этапа AI-программирования.

Этот документ вызвал интерес, потому что он точно попал в точку перелома дискуссий об AI-программировании в июне 2026 года. Addy Osmani, Boris Cherny и Peter Steinberger почти в одну неделю назвали новый этап AI-программирования Loop Engineering, а конвейер Minions от Stripe уже использует аналогичный подход, сливая более 1300 AI-сгенерированных Pull Request каждую неделю.

Эта цифра важна не потому, что AI написал ещё несколько строк кода, а потому что центр тяжести разработки ПО смещается от «человек говорит модели, что писать» к «человек проектирует систему, которая сама выстраивается в очередь, берёт задачи, пишет код, проверяет результаты, сохраняет состояние и продолжает работать».

За последний год нарратив об инструментах AI-программирования в основном вращался вокруг возможностей модели: более точные автодополнения кода, более длинные контекстные окна, агенты, способные выполнять более сложные задачи за один раз. Но Loop Engineering обсуждает другое: когда генерация кода сама по себе становится всё дешевле, инженеру на самом деле нужно спроектировать цикл, способный устойчиво работать. Машина может постоянно выдавать варианты решений, а человек должен решать, каким результатам можно доверять, какие необходимо блокировать, и какие долгосрочные затраты скрыты.

Недавно инженер Anthropic опубликовал 11-страничный документ о «циклической инженерии агентных систем», поместив Loop Engineering после Prompt Engineering, Context Engineering и Harness Engineering, рассматривая его как ключевой метод для следующего этапа AI-программирования. Эта статья использует данный документ как отправную точку, объединяя публичные обсуждения Boris Cherny, Addy Osmani и других, а также пример Stripe Minions, сливающих более 1300 AI-сгенерированных PR каждую неделю, чтобы объяснить, что такое Loop Engineering, почему оно внезапно стало обсуждаться повсеместно, и что на самом деле меняется не написание кода, а проверка, планирование и принятие решений в разработке ПО.

AI-программирование: от «одноразовой подсказки» к «непрерывному циклу»

Loop Engineering помещается после Prompt Engineering, Context Engineering и Harness Engineering как четвёртый уровень стека AI-инженерии.

Prompt Engineering решает вопрос «как спросить»; Context Engineering решает вопрос «что показать модели»; Harness Engineering решает вопрос «как подключить одноразовый запуск модели к инструментам, тестам и рабочим процессам». Loop Engineering идёт на шаг дальше: система не просто выполняет одну задачу, а может перезапускаться через фиксированные интервалы или по триггерам, используя предыдущий результат как вход для следующего витка.

Полный цикл обычно состоит из пяти действий.

Первый шаг — обнаружение работы, например сканирование сбоев CI, открытых Issue, коммитов кода или ожидающих задач; второй шаг — передача задачи, формирование контекста, который модель может обработать; третий шаг — независимая проверка, чтобы убедиться, что сгенерированный моделью код действительно работает, проходит тесты и не вызывает побочных эффектов; четвёртый шаг — сохранение результатов, запись состояния, решений и незавершённых задач в файл или систему; пятый шаг — планирование цикла, чтобы следующий виток запускался в подходящее время.

Самое важное здесь — не «генерация», а «проверка». Если цикл просто заставляет модель снова и снова писать код, а затем ту же модель хвалить свои результаты, он легко превращается в «цикл кивания»: каждый виток кажется прогрессом, но на самом деле лишь лучше упаковывает ошибки.

Утренний цикл triage Османи — личный пример: система ежедневно автоматически читает вчерашние сбои CI, открытые Issue и последние коммиты, генерирует файл состояния и помещает необработанные задачи в папку входящих для человека. Его ценность не в том, чтобы принимать за инженера все решения, а в том, чтобы провести первичный скрининг до того, как инженер проснётся, и оставить внимание для того, что действительно требует оценки.

1300 PR от Stripe: надёжность исходит из ограничений, а не из модели

Конвейер Minions от Stripe — самый впечатляющий корпоративный пример в этой дискуссии: еженедельно сливается более 1300 AI-сгенерированных Pull Request, причём код не пишется вручную построчно.

Но это не значит, что Stripe отдал производственную систему большой модели на откуп. Напротив, ключ Minions — в высококонтролируемом процессе: детерминированный оркестратор сначала собирает контекст, извлекая информацию о задачах из Jira, поиска по коду и внутренних инструментов; LLM генерирует код; затем жёстко закодированные линтеры, шлюзы коммитов и итоговая ручная проверка решают, можно ли слить.

Другими словами, надёжность исходит не из того, что «модель внезапно стала достаточно умной», а из ряда ограничений. Модель предлагает кандидатные изменения, система ограничивает, к чему она может прикасаться и какие проверки должна пройти, а человек принимает окончательное решение, попадать ли изменения в основную ветку.

В этом и состоит различие между Loop Engineering и обычными AI-скриптами программирования. Обычные скрипты часто сосредоточены на «заставить модель выполнить задачу»; циклическая система должна учитывать, откуда берутся задачи, как обрабатывать сбои, как сохранять состояние, как контролировать бюджет и кто предотвращает попадание ошибок в производственную среду.

Без таких ограничений 1300 PR в неделю — это не скачок эффективности, а машина по производству технического долга.

Генератор и оценщик должны быть разделены

Один из ключевых принципов Loop Engineering — разделение генератора и оценщика.

Генератор отвечает за написание кода, изменение файлов и представление кандидатных результатов. Оценщик отвечает за поиск ошибок, причём лучше по умолчанию предполагать, что код содержит проблемы. Они не могут выполняться одним и тем же «оптимистичным агентом», потому что модель при самооценке склонна одобрять собственный вывод, особенно если описание задачи размыто, тестовое покрытие недостаточно или контекст неполон.

Независимый оценщик может быть проще, более подозрительным и более удобным для настройки. Ему не нужно творчески решать проблемы, достаточно проверить, открывается ли страница, проходят ли тесты, нарушены ли граничные условия, соответствует ли код установленным правилам. Некоторые практики заставляют оценщика фактически кликать по странице с помощью инструментов автоматизации браузера, а не просто читать код и выдавать заключение.

Это объясняет, почему «проверка» — самый сложный этап из пятиэтапного цикла. Генерация кода становится всё дешевле, но доказать, что код действительно корректен, всё ещё дорого. Особенно в крупных кодовых базах ошибки не всегда проявляются сразу, а тесты не всегда покрывают реальные бизнес-пути. Чем быстрее работает цикл, тем быстрее накапливаются непроверенные предположения.

Скрытые затраты могут усиливать друг друга

Риск Loop Engineering не в том, что он может написать неправильный код, а в том, что он может затруднить команде осознание того, что она потеряла понимание.

Первый тип затрат — долг проверки. Ошибки, не покрытые тестами, накапливаются в цикле, пока не проявятся массово при слиянии или развёртывании. Второй тип — снижение понимания. Кодовая база непрерывно растёт, но инженер не участвовал лично в ключевых проектных решениях, и его ментальная карта застряла в старой версии. Третий тип — когнитивная капитуляция. Люди начинают по умолчанию принимать выводы машины, выполняя лишь формальное одобрение. Четвёртый тип — взрывное потребление токенов. Повторные попытки, суб-агенты, длинные контексты и многоэтапная проверка могут быстро увеличить счёт.

Эти четыре вида затрат питают друг друга: недостаток тестов приводит к долгу проверки; рост долга проверки снижает желание инженеров глубоко разбираться; снижение понимания превращает ручную проверку в резиновую печать; а проверка-резиновая печать стимулирует больше автоматических повторных попыток и более высокие затраты.

Таким образом, один и тот же набор циклических компонентов может приводить к совершенно противоположным результатам в руках разных инженеров. Люди с сильным чутьём и чёткими границами могут использовать цикл для усиления своего понимания системы, превращая машину в неутомимый исполнительный слой; те, у кого слабое чутьё или чрезмерная зависимость от автоматизации, через несколько месяцев могут стать «привратниками» своей собственной системы, способными только одобрять или отклонять, но не объяснять, почему система работает именно так.

После того как код подешевел, дорогими становятся решения

Loop Engineering выдвигает долгосрочный тренд на более чёткое место: код, планы, PR и разбивка задач становятся почти бесплатными, но «что действительно правильно» не подешевело.

Для бизнеса это означает, что приоритет инвестиций в AI-программирование может сместиться с покупки более мощных моделей на проектирование более стабильных процессов: границы задач, сборка контекста, независимая оценка, сохранение состояния, бюджетные лимиты, точки ручной проверки и механизмы остановки цикла при аномалиях. Возможности модели по-прежнему важны, но они лишь часть системы.

Для инженеров роли также меняются. Раньше основная работа заключалась в написании кода, теперь всё больше труда уходит на проверку кандидатных ответов, сгенерированных машиной: соответствует ли он требованиям, не нарушает ли архитектуру, лишь ли выглядит разумным на первый взгляд, не переносит ли сложность на будущих сопровождающих.

Это не означает, что программисты уже заменены. Напротив, Loop Engineering больше похож на усилитель суждений. Он позволяет одному инженеру выполнять объём изменений, который раньше требовал целой небольшой команды, но также может превратить лень, слепое доверие и отсутствие привычки к проверке в производственные аварии.

Реальное разделение в том, сохраняет ли человек достаточно сильное право на суждение и вето. AI может постоянно отправлять PR, но то, можно ли слить, стоит ли разворачивать, не подорвёт ли это систему в долгосрочной перспективе, по-прежнему зависит от человека.

Нажмите, чтобы узнать о вакансиях в BlockBeats

Добро пожаловать в официальное сообщество BlockBeats:

Telegram-подписка: https://t.me/theblockbeats

Telegram-чат: https://t.me/BlockBeats_App

Twitter-аккаунт: https://twitter.com/BlockBeatsAsia