Тысячи PR в месяц: как Лорен Тан работает с агентами

21 сентября Лорен Тан (Lauren Tan, poteto) выложила в X доклад под заголовком «here's how i shipped 2,500 PRs last month to production». Его готовили для конференции Cursor Compile в Лондоне, но Лорен не смогла приехать и опубликовала запись сама. К 25 октября у поста больше 4 миллионов просмотров и 19 тысяч лайков, он закреплён у неё в профиле. 2 октября Мэтт Покок (Matt Pocock) позвал её в прямой эфир и построил разговор как разбор этого доклада. Запись эфира идёт час пять минут.

Лорен работала в Netflix и Meta, входит в команду React Compiler и написала набор скилов pstack, который мы разбирали в отдельной статье. В эфире она говорит, что пришла в Cursor в марте и что Cursor теперь называется SpaceX AI. В профиле X у неё сейчас указано, что она делает Grok Bot.

По эфиру, докладу и постам Лорен в X мы собрали, как один инженер с агентами доводит до продакшена тысячи PR (пул-реквестов) в месяц и что из этого можно перенести в свою работу.

Что стоит за цифрой

2500 PR не означают 2500 фич. В эфире Лорен говорит, что большая часть работы уходит на «садоводство»: рефакторинг, производительность, исправление багов, инструменты для команды. В X она перечисляет, откуда берутся PR: постоянная работа над производительностью, баги из пользовательских репортов, рефакторинг кода Grok Bot под агентов, улучшение своих скилов, новые фичи, полировка интерфейса, харнес, инструменты релиза и мониторинга, сторонние проекты. Отдельный PR, по её словам, занимает несколько сотен строк. Дойти до такого объёма, как она пишет, заняло около полугода и много рефакторинга.

Лестница доверия

Путь начался с проекта, который Лорен писала в отпуске после Meta. Она заметила, что часами микроменеджит одного агента. В Cursor ей поручили ускорить окно агентов, и первое время она вручную разбирала флеймграфы и снимки памяти. В эфире она называет себя тогдашнюю живой прослойкой между агентом и Chrome DevTools: агент не видел, что происходит в программе, и всё ему пересказывала она.

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

Мэтт спросил её, теряет ли сейчас ценность экспертиза в предметной области. Лорен ответила, что наоборот: модели стали настолько сильными, что узким местом стала способность человека ясно передать агенту замысел и цель.

Агент должен видеть результат

Главный скил, по словам Лорен, это проверка (verification). Агенту дают «руки и глаза»: он сам запускает программу, пользуется ей как человек, снимает трейсы и снимки памяти. Это был её первый скил в Cursor, и именно он позволил подняться по лестнице доверия. Остальные скилы помогали меньше, потому что результат по-прежнему проверяла она сама.

Лорен считает, что без проверки цикл агента не работает. Если у задачи есть рубрика или метрика, агент может раз за разом улучшать результат, и это лаборатории называют hill climbing. В её команде, как она говорит, у каждого приложения есть свой скил проверки, и он обновляется автоматически. В X она уточняет, чего ждёт от проверки: агент приносит артефакт, который показывает, что работа верна и совпадает с замыслом, и который проще посмотреть, чем весь PR. Для интерфейса это видео или скриншоты. Ночной цикл с такими критериями мы описывали в статье про Ralph loop.

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

Кодовая база как память

Вторая опора после проверки это сам код. Для приложений Grok Bot команда написала закрытый фреймворк Dune, который Лорен описывает как внутренний Next.js для приложений на Electron. В нём строгие правила линтера, и почти всё делается одним способом: у каждой фичи своя папка, фичи находятся через реестр. Первые версии Grok Bot, по её словам, состояли из восьми файлов минимум по 10 тысяч строк, и агент, как и человек, дописывал бы новый код туда же.

Рабочий приём простой. Лорен смотрит, где агенты ошибаются, и каждую повторяющуюся ошибку превращает в правило линтера или переделывает код так, чтобы ошибка стала невозможной. Она сравнивает это с сужением типов в TypeScript: из широкого типа шаг за шагом получается узкий, и пространство возможных решений сжимается. В X она формулирует это короче: кодовая база служит агентам памятью, агенты любят повторять то, что уже есть, поэтому плохой паттерн расползается по коду. Порядок, в котором стоит закрывать ошибки, она описала как перевёрнутую пирамиду, о ней в статье про pstack.

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

Кухня вместо фабрики

Слово «фабрика софта» Лорен не любит: фабрика плохо вяжется с качеством и ремеслом. Она говорит о мишленовской кухне. Домашний повар всё режет и моет сам. Шеф уже не готовит каждое блюдо, он устраивает кухню: что заказать, где хранить, кто что делает. За результат при этом отвечает он. Инженер с агентами, по её словам, в той же роли, и скилы, окружение и код становятся новыми ингредиентами.

Когда одна кухня настроена, можно открывать сеть ресторанов. Лорен различает два цикла. Внутренний цикл составляют агенты, которые пишут код под замысел. Внешний приносит новую информацию: баг-репорты в Slack, Linear, X. Раньше эту информацию носила агентам она сама. Теперь боты Grok Bot с подключениями к почте, Slack, X и Linear следят за каналами по расписанию и отправляют находки в проект Cursor. В проекте работает агент-координатор: сам он код не пишет, раздаёт задачи субагентам и следит за ходом работы. Если за раз пришло 30 похожих репортов, координатор видит их вместе. Отдельный агент на каждый баг продублировал бы работу и не заметил бы общей причины.

Лорен часто спрашивает себя, где она сейчас узкое место и почему агенту нужна она, чтобы ответить на вопрос. Она вспоминает принцип Netflix «context, not control»: вместо контроля давать контекст и учить агента самому его добывать. Ещё один приём касается очереди. Одна из её рутин ищет в коде запрещённые паттерны React, но ничего не исправляет, а записывает находки в документ. Раз в несколько дней Лорен его читает и видит, что десять находок оказываются одной проблемой.

Ревью выборкой

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

В её проектах агенты сливают свои PR сами. Режим полного автопилота в pstack запускает на каждый PR несколько агентов-проверяющих, которые устраивают фаззинг: работают с приложением как пользователи, ищут регрессии и баги, исправляют их и повторяют проверку. Это дорого по токенам, и Лорен советует сократить десять проверяющих до одного, если бюджет не позволяет. Утром она читает историю коммитов, откатывает неудачное и добавляет правила. Первую ночь в таком режиме она называет страшной.

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

Мэтт спросил, что делать там, где изменение необратимо, например в медицине или финансах. Лорен ответила, что всё упирается в то, насколько работу можно проверить: где проверка надёжна, необратимое решение становится обратимым. Для областей, где проверить программно трудно, готового ответа у неё нет. Надежду она связывает с формальной верификацией и языками вроде Bend, где доказательства пишутся прямо в коде. В октябре в pstack появился скил для формальной верификации, пока в бете, и Лорен пишет, что уже нашла с ним несколько багов через TLA+.

Скилы как свои ножи

В конце Мэтт спросил, как сочетать его скилы и pstack. Лорен считает их совместимыми: скил, по её словам, это просто процесс, записанный словами в Markdown. Она советует просмотреть свои прошлые чаты с агентом и найти места, где вы его поправляли. Это и есть ваш настоящий процесс. Повторяющиеся поправки стоит превратить в правила линтера или новые скилы. Для этого в pstack есть скил /recall, а у Мэтта похожую задачу решает /retro, о его наборе мы писали в статье про скилы Мэтта Покока.

Лорен ожидает, что скилы будут становиться короче. В прошлогодних скилах было много точных команд, а с новыми моделями эти части можно удалить и оставить только последовательность шагов. Повар, говорит она, переходит в новый ресторан со своими ножами, и у каждого инженера набор будет свой.

Как это обсуждали в X

Доклад и эфир вызвали спор, и это мнения разных людей. Эмиль Ковальски (Emil Kowalski, раньше Linear и Vercel) спросил, зачем вообще выпускать сотни PR в день. В ответах писали, что большая часть таких PR чинит то, что агент сломал час назад. Сам Эмиль заметил, что идею тратить больше токенов чаще всего продвигают люди из компаний, которые эти токены продают. Лорен ответила длинным постом: объём важен, потому что с агентами каждый может работать как самые продуктивные инженеры больших компаний, а стоимость стоит считать в цене за интеллект, а не в токенах. Гергей Орос (Gergely Orosz, The Pragmatic Engineer) согласился, что большинство разработчиков ещё не поняли, что их работой станет строить машину, которая строит софт.

Сильнее всего спорили о комментариях. Лорен предложила удалить почти все комментарии в коде, потому что агенты копируют временные обходы вместе с поясняющими их комментариями. Дэвид Крамер (David Cramer, Sentry) назвал это плохим советом: комментарий передаёт замысел, которого нет в логике, например при миграции. Лорен ответила, что комментарий о том, что код устарел, ничего не запрещает, а правило линтера запрещает. Кун Чен (Kun Chen) предложил добавить к её определению хорошего кода удобство поддержки, Лорен ответила, что с агентами это уже не так важно. Нэн Ю (Nan Yu, Codex в OpenAI) возразил, что рядовой инженер в большой компании не может поменять практики всей организации. Алекс Клеммер (Alex Clemmer) спросил, как подход переносится на базы данных и компиляторы, где проверка и так держится на тестах свойств и проверке моделей.

Были и одобрительные отзывы. Роберт Мартин (Uncle Bob) написал, что в принципах pstack заложена серьёзная мудрость. Цифру PR Лорен называет сама, и независимо её никто не проверял.

Что взять себе завтра