В блоге CNCF вышел текст Энди Андерсона, мейнтейнера KubeStellar Console. Он почти в одиночку с помощью двух кодинг-агентов в параллельных сессиях терминала собрал дашборд для управления мультикластерами Kubernetes и довёл принятие пул-реквестов до 81%. Цифра вынесена в заголовок, и именно поэтому я хочу поговорить про всё кроме неё.
Потому что 81% — это приманка. А интересна там механика, которая к этой цифре привела. И ещё интереснее проблемы, которые автор честно проговаривает.
Сразу замечание: я всё-таки не разработчик, хоть и в ИТ очень давно, поэтому старался не влезать в дебри, которые могу понимать не до конца. Но, надеюсь, моих знаний было достаточно, чтобы перевести и разобрать для вас этот материал.
Узнаваемая драматургия
Первые две недели у Андерсона были эйфорией: код выходил быстрее, чем он успевал читать, трёхдневные задачи закрывались за два часа. Потом всё рухнуло. Сборки ломались так, что причину не отследить. Вчерашние архитектурные решения тихо переписывались. Объём задач увеличивался сам собой. И главная проблема — каскад ошибок: чинишь одно, ломаются три. В какой-то момент откаты стали занимать больше времени, чем ревью, и он решил перепридумать весь подход.
Кажется, что от «гениально» до «я трачу на исправление ошибок больше времени, чем сэкономил» — путь короткий и, судя по всему, универсальный. Ценность статьи в том, что она не заканчивается на этой фрустрации, а объясняет, почему обычный рецепт выхода из неё не работает.
Рычаг работает в обратную сторону
Стандартный совет индустрии в этой точке: дайте агенту больше автономии. Пусть работает дольше, трогает больше файлов, сам себя исправляет. Андерсон говорит ровно обратное: по его опыту этот сценарий только усугубляет проблему.
И дальше, на мой взгляд, самая ценная мысль во всём тексте:
Интеллект в кодовой базе с AI-ассистированием живёт не столько в модели, сколько в петлях обратной связи, которыми оборачивается кодовая база.
Из этого такой вывод: чтобы агент делал больше, не модель должна стать умнее, а среда вокруг неё должна давать больше сигналов для контроля и улучшения. Автономия без сигналов — это не ускорение, это разгон в тумане.
Под «петлёй» имеется в виду контур обратной связи — замкнутый цикл, где результат работы агента кто-то или что-то измеряет, и это измерение возвращается обратно и меняет поведение системы. Не «модель стала умнее», а «вокруг модели крутится цикл: сделал → измерили → подправили → снова сделал».
Противоположность петли — открытая труба: агент генерит, никто не проверяет, дрейф накапливается. Ровно это автор описывает в сцене «всё рухнуло» — петли ещё не было, был неконтролируемый поток.
Пять петель и что в них реально работает
Андерсон укладывает свой путь в «модель зрелости AI-кодовой базы»: Assisted → Instructed → Measured → Adaptive → Self-Sustaining. Названия можно не любить, но порядок честный — переставить ступени нельзя, и это важнее самих ярлыков. Пройдусь по тем, где у меня есть что комментировать.
Instructed — выносите наружу то, что постоянно исправляете. Самое дешёвое вмешательство с самой высокой отдачей. Гайд, каталогизирующий причины, по которым он отклонял сгенерированные PR, покрыл около 90% его критериев отклонения. Тут я соглашаюсь без оговорок — это ровно то, чем я занимаюсь со своими контент-агентами. Большая часть «магии» промптинга на дистанции оказывается банальным внешним сводом правил: не держать критерии «хорошо» в голове, а вынести их в файл, который читают все сессии.
Measured — тесты как слой доверия, а не только корректности. Вот здесь начинается самое интересное и самый недооценённый тезис статьи. Тест в человеческом процессе и тест в автономном — это два разных артефакта, потому что у них разный потребитель сигнала.
Нестабильный тест в человеческом процессе — раздражение. В автономном — медленная, тихая эрозия всей модели доверия.
Сформулирую то, что у Андерсона осталось между строк. Изменился не набор инженерных практик — тесты, документация, CI, конвенции были важны всегда. Изменился их читатель. Раньше сигналы вашего репозитория потреблял человек, который умеет прощать пробелы своим суждением. Теперь их потребляет агент, который прощать не умеет — он буквально не видит того, чего нет в сигнале. Отсюда и переоценка ROI на дисциплину, которую все «и так знали»: цена флаки-теста, неполного покрытия, устных договорённостей и недописанной доки в автономном контуре резко выросла, потому что заткнуть дыру «ну тут и так понятно» больше некому.
Adaptive — не автоматизируйте, пока не можете измерить. Когда показатели принятия пишутся в лог, автоматизация становится безопасной. Веса ротации, решающие, на чём фокусироваться, начинают подстраиваться по данным: PR по доступности принимались на 62% — вес подняли; PR категории operator принимались на 8% (11 мёржей против 129 закрытых) — вес обнулили, циклы CI перенаправили. Принцип формулируется одной строкой: сначала измерение, потом автоматизация. Обратный порядок — это и есть способ, которым автономные системы сходят с рельсов.
Здесь у меня есть скептическая ремарка. «Принятие пул-реквеста» в системе, где агент и генерирует, и судит по правилам мейнтейнера, — это во многом метрика согласованности генератора с судьёй, а не внешнего качества. 81% частично означает «агент научился попадать в мои же критерии». Это не обесценивает результат, но это не то же самое, что «81% кода объективно хорош». За цифрой принятия нужно держать вторую метрику — что происходит в проде, — иначе легко построить замкнутый контур, который красиво сходится сам с собой. Андерсон, буду справедлив, это частично закрывает: у него ежечасный GA4-запрос заводит issue по всплескам ошибок в проде раньше, чем жалуются пользователи. То есть внешний сигнал в петле есть. Но в пересказах он обычно теряется, а без него вся конструкция превращается в метрики ради метрик.
Одна привычка в промптинге, которая стоит остальных
Вместо «исправь этот баг» Андерсон стал спрашивать: «Почему ты это не отловил?» Первая формулировка даёт патч. Вторая — анализ первопричины и, как побочный продукт, новый тест, инструкцию или правило, которое блокирует целый класс похожих сбоев. Команды дают цепочку изолированных заплаток. Вопросы накапливаются в систему.
Это переносится далеко за пределы кода. В контент-ревью работает та же замена: не «перепиши этот абзац», а «почему редактор-агент это пропустил». Первое чинит абзац. Второе чинит правило, по которому абзацы такого типа больше не проходят.
Где я бы притормозил с восторгом
И хорошо, что значительную часть из них автор проговаривает сам, не дожидаясь скептиков.
n=1. Один мейнтейнер, один проект в Sandbox CNCF. Он начал с нуля в декабре, без легаси, без двадцати лет накопленных компромиссов в коде. Перенесите это на legacy-монолит с сорока контрибьюторами, мутной историей и кусками, которые «работают, и не трогай», — и стоимость входа в ступень Measured вырастает на порядок. Сам автор пишет ровно это: масштабируется ли подход за пределы single-maintainer sandbox-проекта — вопрос открытый, и ему правда хотелось бы знать ответ.
63 воркфлоу, 32 ночных набора, покрытие 91% по двенадцати шардам — это не бесплатно. Это и есть та самая «интеллектуальная инфраструктура», в которую переехала вся сложность. Тезис «модель — взаимозаменяемый компонент; перестройка петель — работа на квартал» верен, но у него есть оборотная сторона: вы не убрали труд, вы его переместили — из написания кода в построение и поддержку контура, который этот код измеряет. Для проекта с правильным доменом и одним владельцем суждения это выгодный обмен. Для команды без культуры тестов это просто другой, не менее тяжёлый труд под новым названием.
Зачем это тем, кто строит агентов не для кода
Я вожусь не с кодинг-агентами, а с контентными. И развивал я их также: эйфория, потом каскад правок, потом понимание, что автономию надо не наращивать, а обкладывать сигналами и проверками. Меня в своё время удивило ровно то же, что Андерсона: упирается всё не в широту возможностей модели, а в тяжёлую работу, которую должна делать среда вокруг неё.
Показательно, что перевод оригинальной статьи, который лёг в основу этого разбора, я делал не сам, конечно, и он прошёл через пайплайн translator → editor → verifier — это та же логика петель, просто применённая к тексту, а не к коду. Редактор-агент ловит то, что не удержит в голове человек; верификатор отлавливает то, что пропустил редактор.
Главный вывод я бы сформулировал так. Перестаньте выбирать идеальную модель — это взаимозаменяемая деталь. Стройте петли обратной связи, потому что именно в них, а не в весах модели, живёт прикладной интеллект вашей системы. И не гонитесь сразу к последней ступени: большинство команд застряли на первой — пишут промпты и проверяют вывод глазами. Смысл не в том, чтобы добраться до самоподдерживаемой системы. Смысл в том, чтобы честно увидеть, какая петля блокирует именно вас сейчас, и закрыть следующей именно её.
Подписывайтесь на мой канал, там немного вещаю про ИИ для задач контента и не только.
ссылка на оригинал статьи https://habr.com/ru/articles/1041914/