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

Разработчица Grok Bot и автор pstack о лестнице доверия, проверке работы самим агентом, ревью выборкой и кодовой базе, в которой агенту трудно ошибиться.

- Автор: Guide DAO
- Опубликовано: 2026-10-25
- Теги: Claude, AI-агенты, Вайбкодинг
- Страница: https://www.guidedao.xyz/blog/poteto-tysyachi-pr-s-agentami

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

Лорен работала в Netflix и Meta, входит в команду React Compiler и написала набор скилов pstack, который мы разбирали в [отдельной статье](https://www.guidedao.xyz/blog/pstack-poteto-mode). В эфире она говорит, что пришла в Cursor в марте и что Cursor теперь называется SpaceX AI. В профиле X у неё сейчас указано, что она делает Grok Bot.

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

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

2500 PR не означают 2500 фич. В эфире Лорен говорит, что большая часть работы уходит на «садоводство»: рефакторинг, производительность, исправление багов, инструменты для команды. В X она [перечисляет](https://x.com/poteto/status/2108279582088671583), откуда берутся PR: постоянная работа над производительностью, баги из пользовательских репортов, рефакторинг кода Grok Bot под агентов, улучшение своих скилов, новые фичи, полировка интерфейса, харнес, инструменты релиза и мониторинга, сторонние проекты. Отдельный PR, по её [словам](https://x.com/poteto/status/2107555957584937373), занимает несколько сотен строк. Дойти до такого объёма, как она [пишет](https://x.com/poteto/status/2108320890333388854), заняло около полугода и много рефакторинга.

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

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

Отсюда метафора лестницы доверия. Когда агенту не доверяешь, остаётся сидеть рядом и проверять каждый шаг. Это отнимает всё время, и его не остаётся на то, чтобы улучшить инструменты. Ещё в апреле Лорен [писала](https://x.com/poteto/status/2048092593087721736), что это похоже на управление людьми: чем больше доверия, тем больше можно делегировать. По её словам из эфира, модели даже самого высокого уровня склонны срезать углы и делать то, что проще. Поэтому её скилы в основном о том, чтобы простой путь для агента совпадал с правильным.

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

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

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

Лорен считает, что без проверки цикл агента не работает. Если у задачи есть рубрика или метрика, агент может раз за разом улучшать результат, и это лаборатории называют hill climbing. В её команде, как она говорит, у каждого приложения есть свой скил проверки, и он обновляется автоматически. В X она [уточняет](https://x.com/poteto/status/2109436202554372476), чего ждёт от проверки: агент приносит артефакт, который показывает, что работа верна и совпадает с замыслом, и который проще посмотреть, чем весь PR. Для интерфейса это видео или скриншоты. Ночной цикл с такими критериями мы описывали в статье про [Ralph loop](https://www.guidedao.xyz/blog/ralph-loop-dolgie-zadachi).

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

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

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

Рабочий приём простой. Лорен смотрит, где агенты ошибаются, и каждую повторяющуюся ошибку превращает в правило линтера или переделывает код так, чтобы ошибка стала невозможной. Она сравнивает это с сужением типов в TypeScript: из широкого типа шаг за шагом получается узкий, и пространство возможных решений сжимается. В X она формулирует это короче: кодовая база служит агентам [памятью](https://x.com/poteto/status/2109699980248408574), агенты любят повторять то, что уже есть, поэтому плохой паттерн расползается по коду. Порядок, в котором стоит закрывать ошибки, она описала как перевёрнутую пирамиду, о ней в [статье про pstack](https://www.guidedao.xyz/blog/pstack-poteto-mode).

Мэтт сделал из этого свой вывод и на следующий день после эфира [написал](https://x.com/mattpocockuk/status/2106425743479546343), что в эпоху агентов абстракций нужно больше. Вместе с жёсткими правилами линтера они сужают для агента выбор решений до хороших, а сильная абстракция позволяет написать меньше кода и потратить меньше токенов.

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

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

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

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

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

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

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

В X она [уточняет](https://x.com/poteto/status/2108283057581195413): каждый PR оценивает агентное ревью, и PR с низким и средним риском сливаются без человека. Для критичных частей кода, по её [словам](https://x.com/poteto/status/2093624029504745541), человеческое ревью остаётся обязательным.

Мэтт спросил, что делать там, где изменение необратимо, например в медицине или финансах. Лорен ответила, что всё упирается в то, насколько работу можно проверить: где проверка надёжна, необратимое решение становится обратимым. Для областей, где проверить программно трудно, готового ответа у неё нет. Надежду она связывает с формальной верификацией и языками вроде Bend, где доказательства пишутся прямо в коде. В октябре в pstack появился скил для формальной верификации, пока в бете, и Лорен [пишет](https://x.com/poteto/status/2111926622278521253), что уже нашла с ним несколько багов через TLA+.

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

В конце Мэтт спросил, как сочетать его скилы и pstack. Лорен считает их совместимыми: скил, по её словам, это просто процесс, записанный словами в Markdown. Она советует просмотреть свои прошлые чаты с агентом и найти места, где вы его поправляли. Это и есть ваш настоящий процесс. Повторяющиеся поправки стоит превратить в правила линтера или новые скилы. Для этого в pstack есть скил `/recall`, а у Мэтта похожую задачу решает `/retro`, о его наборе мы писали в [статье про скилы Мэтта Покока](https://www.guidedao.xyz/blog/skily-mehtta-pokoka).

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

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

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

Сильнее всего спорили о комментариях. Лорен [предложила](https://x.com/poteto/status/2110149626133438732) удалить почти все комментарии в коде, потому что агенты копируют временные обходы вместе с поясняющими их комментариями. Дэвид Крамер (David Cramer, Sentry) [назвал](https://x.com/zeeg/status/2110151014540300611) это плохим советом: комментарий передаёт замысел, которого нет в логике, например при миграции. Лорен [ответила](https://x.com/poteto/status/2110164056422465845), что комментарий о том, что код устарел, ничего не запрещает, а правило линтера запрещает. Кун Чен (Kun Chen) [предложил](https://x.com/kunchenguid/status/2109117159951790521) добавить к её определению хорошего кода удобство поддержки, Лорен ответила, что с агентами это уже не так важно. Нэн Ю (Nan Yu, Codex в OpenAI) [возразил](https://x.com/thenanyu/status/2109793837266956645), что рядовой инженер в большой компании не может поменять практики всей организации. Алекс Клеммер (Alex Clemmer) [спросил](https://x.com/hausdorff_space/status/2112335192656613422), как подход переносится на базы данных и компиляторы, где проверка и так держится на тестах свойств и проверке моделей.

Были и одобрительные отзывы. Роберт Мартин (Uncle Bob) [написал](https://x.com/unclebobmartin/status/2110476094704910407), что в принципах pstack заложена серьёзная мудрость. Цифру PR Лорен называет сама, и независимо её никто не проверял.

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

Первое: дайте агенту способ проверить свою работу. Ему нужно запускать программу и приносить доказательство: вывод, скриншот, видео. Без этого всё остальное мало что даёт. Второе: каждую поправку, которую вы делаете агенту второй раз, превращайте в правило линтера, тип или тест, а не в строку в промпте. Третье: детерминированные шаги, которые агент каждый раз изобретает заново, вынесите в скрипт внутри скила. Четвёртое: пройдитесь по своим прошлым чатам и найдите места, где поправляли агента. Пятое: автоматическое слияние включайте только там, где изменения можно проверить и откатить, а ревью делайте выборкой, разбирая повторяющиеся ошибки.

На наш взгляд, первые два шага стоит сделать даже тем, кто не собирается выпускать тысячи PR: они окупаются и на одном агенте.

Как настроить проверку, скилы и субагентов в Claude Code, разбираем на курсе.

Курс Guide DAO: [Основы Claude Code](https://www.guidedao.xyz/claude)