К основному содержимому
к странице архива
#AI4SDLC

Warp: поправили агента. Чему научилась система? (Рубрика #AI4SDLC)

Интересная история от создателя Warp, которая продолжает разбор Factory, где мы обсуждали, как организовать исполнение и проверку агентных задач, а также разбор Conductor, где мы говорили о том, а как человеку управлять несколькими исполнителями. Но после обоих остаётся вопрос: если сегодня пришлось поправить агента, что изменится в его работе завтра?

Zach Lloyd, основатель и CEO Warp, предлагает сделать такие исправления материалом для улучшения всего процесса. Его доклад «Software Engineering Is Becoming Factory Engineering» прошёл на AI Engineer World's Fair 30 июня 2026 года, а отдельная запись появилась 27 сентября.

По мысли Lloyd, инженер будет всё больше заниматься системой, которая производит изменения в продукте. Warp продаёт инфраструктуру для такого процесса, поэтому интерес компании понятен. Сам процесс узнаваемый: разобрать задачу, подготовить спецификацию, написать код, проверить, выпустить и наблюдать за результатом. Люди у Lloyd продолжают проверять спецификации, код и поведение продукта.

Мне здесь интереснее второй цикл — работа над самим процессом. Агент делает ревью, опытный инженер исправляет его замечание. Агент-наблюдатель разбирает эту обратную связь и предлагает обновить skill — инструкцию для следующих ревью. Так исправление может пережить текущий PR и помочь другим участникам команды. Это хорошо продолжает историю Vercel d0: там повторяющиеся запросы превращались в навыки, а я задавался вопросом, кто дальше проверяет и обновляет накопленное. Warp предлагает использовать для этого в том числе замечания людей.

Причём после доклада идея стала конкретнее. В июльском руководстве Warp агент уже открывает PR с изменением навыка ревью. А в документации, обновлённой 24 сентября, предлагаемые исправления связаны с неудачными запусками и требуют человеческой проверки. Здесь «самоулучшение» означает изменение инструкций и процесса; обучение весов модели из этого не следует.

Со способом оценивать успех я бы поспорил. В обращении к команде Lloyd предлагает считать работу с агентом в ручном интерактивном режиме неудачей, из которой нужно извлечь урок. Цель — увеличивать долю автоматических изменений.

Повторные объяснения уже известного правила хочется убрать. А совместный поиск решения для новой задачи может быть полезной работой, даже если снижает долю автоматических изменений. Здесь снова вспоминается Dex Horthy из HumanLayer с его вниманием к проектированию и пониманию системы. Я бы оценивал, какие вмешательства удалось убрать и что стало с качеством результата. Процент автономных задач сам по себе этого не покажет. Правда надо отметить, что и человеческое замечание тоже может быть ошибочным. Если сразу превратить его в общую инструкцию, завтра агент начнёт старательно повторять уже нашу ошибку.

Из этого я бы забрал три практических шага:

1️⃣ Найти одну повторяющуюся правку Посмотреть последние ревью, сформулировать правило и сохранить пример ошибки. Начать с небольшого навыка, пользу которого можно проверить. 2️⃣ Проверить новую инструкцию на других задачах Сравнить старую и новую версии, включая случаи, где раньше всё работало. Принимать изменение после проверки и сохранять возможность отката. 3️⃣ Посчитать полную стоимость результата Включить время на постановку, ревью и переделки, расходы на модели и обслуживание автоматизации. Затем проверить, стало ли меньше повторных исправлений при сопоставимом качестве.

#AI4SDLC #AI #Agents #PlatformEngineering #Evals

Открыть видео на YouTube