Конспект лекции Лорен Тан (SpaceX AI): команда ИИ-агентов, которой можно доверять

Лорен Тан — инженер SpaceX AI, раньше работала в React Core и Meta. Сейчас её агенты сами вмёрживают код: за месяц у неё выходит больше 1000 пулл-реквестов, а однажды она проснулась и увидела 20 уже принятых за ночь. В часовой лекции она рассказывает, как к этому пришла — и главное там вовсе не «запусти сто агентов».

Ниже — конспект лекции на русском по таймкодам, без воды. В конце — чек-лист, три готовых промпта для Claude и ссылки на запись и инструменты.

Проверь: это про тебя?

• Работаешь с ИИ-агентами, но тратишь больше времени на проверку их работы, чем экономишь.
• Агент уверенно говорит «нашёл причину», а потом оказывается, что нет.
• Боишься дать агенту больше самостоятельности, потому что не понимаешь, что он сделает.
• Хочешь запускать несколько агентов параллельно, но всё упирается в тебя.

Конспект по таймкодам

00:00 — ИИ как напарник, а не замена мышлению

Лучшее применение ИИ — работа в паре, как с коллегой, а не способ перестать думать. Погоня за «сотней PR в неделю» без понимания кода ведёт к тому, что ты больше времени проверяешь и исправляешь, чем экономишь.

01:00 — Главная проблема: доверие

Когда агент угадывает, галлюцинирует и уверенно ошибается в сотый раз, доверие пропадает. Без доверия работа с агентами превращается в микроменеджмент: как руководитель, который не доверяет команде и стоит у всех над душой. А микроменеджмент не масштабируется.

03:00 — Кривая доверия

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

06:00 — Главный навык: верификация

Верификация — это когда агент сам запускает то, что сделал: открывает приложение, снимает трейсы и снимки памяти, запускает симулятор — проверяет так же, как это увидит пользователь. Это «замыкает петлю». Верификация не гарантирует красивый код, но гарантирует правильный — а это огромный шаг к доверию. Без неё верификатор — ты сам: копируешь скриншоты и ошибки, гоняешь агента по кругу и становишься бутылочным горлышком.

10:00 — Карта фич (feature map)

Научить агента запускать приложение мало — он не знает, где что находится. Лорен добавила файл-карту: какие есть функции, как до каждой добраться в интерфейсе, горячие клавиши, нужные элементы страницы. Теперь даже размытая жалоба вида «тут что-то сломалось» плюс скриншот превращается в понятную задачу. В её наборе pstack есть скиллы, которые сами строят такую карту и поддерживают её в актуальном виде.

13:00 — Как родился pstack

Лорен не собиралась делать плагин. Она просто наблюдала, где агенты ошибаются, и каждую ошибку превращала в скилл: «не угадывай — найди и прочитай код», «используй сабагентов», «перестань галлюцинировать». Скилл — это обычный текстовый файл с инструкциями. Хорошо написанные инструкции переключают модель в более «умный» режим. Аналогия: способный новичок без контекста — скилл даёт ему этот контекст.

17:00 — Эвалы: юнит-тесты для скиллов

Чтобы понять, работает ли скилл, она пишет эвалы — проверки поведения агента. Координатор составляет критерии оценки, запускает несколько сабагентов в папках с нейтральными названиями (если агент понимает, что его тестируют, он ведёт себя иначе), а агент-судья другой модели перепроверяет оценки. Дальше — по кругу (/loop), пока все пункты не станут 10 из 10. Поддержка скиллов требует вкуса и наблюдательности: смотри, где агент спотыкается, и закрывай это скиллом.

22:00 — Ты шеф-повар, а не повар

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

24:00 — Начинай локально, потом облако

Начинать стоит локально: видно, как агент взаимодействует с приложением. Когда навык верификации отлажен, облачные агенты окупаются многократно — и не только для тебя, а для всей команды. Пример: агент, который сам берёт баг-репорты, поднимает приложение в облаке, воспроизводит баг и сообщает, исправлен он уже или нет.

29:00 — Переписывать ли код

Старые большие проекты обычно уже обвешаны ограничениями, и агентам там проще. Самый большой риск — новые навайбкоженные прототипы: без рамок агенты решают задачи самым коротким путём, и код расползается. Поэтому новый проект стоит с самого начала строить с жёсткими правилами. Лорен потратила около 600 PR на перестройку своего продукта под новую архитектуру — и теперь почти не смотрит в код.

36:00 — Небольшие PR и правила, которые ломают сборку

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

42:00 — Слои ограничений

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

47:00 — Токены и окупаемость

На старте это дорого: перестройка кода и правил съедает много токенов. Но это вопрос окупаемости: вместо найма большой команды ты один раз вкладываешься в среду, где даже небольшая модель пишет хороший код.

52:00 — Не только для инженеров

Благодаря строгим рамкам код начинают выпускать и не-инженеры: продакты и дизайнеры. Агент, который каждое утро собирает сводку «что сделано за ночь», — простой пример.

Бонус 1: чек-лист «кривая доверия»

1. Один агент — и ты наблюдаешь его шаги: где он угадывает, где ошибается.
2. Каждую повторяющуюся ошибку — в правило или скилл.
3. Дай агенту способ проверять себя: запускать результат и сравнивать с ожиданием.
4. Опиши «карту»: что где лежит и как до этого добраться.
5. Проверь скилл на нескольких запусках, а не на одном удачном.
6. Только после этого — второй, третий агент параллельно.

Бонус 2: три промпта для Claude

Промпт 1. Навык самопроверки.

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

Промпт 2. Карта проекта.

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

Промпт 3. Из замечаний — в правила.

«Вот мои замечания к твоей прошлой работе: [вставь]. Преврати каждое в короткое правило, которое можно проверить, и раздели их на жёсткие (нарушать нельзя никогда) и мягкие (по ситуации)».

Бонус 3: ссылки

• Лекция целиком на YouTube: запись 1 · запись 2 (на английском, можно включить автоперевод субтитров).
• pstack — набор скиллов Лорен Тан (оригинал для Cursor): github.com/cursor/plugins/tree/main/pstack
• Неофициальный порт pstack для Claude Code: github.com/adjohn/pstack (сторонний проект — посмотри код перед установкой).

Задание на сегодня

Возьми одну задачу, которую регулярно отдаёшь ИИ, и добавь к ней шаг самопроверки (промпт 1). Посмотри, сколько ошибок агент теперь ловит сам, до того как результат попадёт к тебе.

Что дальше

Всё, о чём говорит Лорен, — скиллы, правила, самопроверка, карты — работает не только в коде. Это то, что превращает Claude из чата в помощника, которому можно доверить работу. Я так и работаю: у меня Claude по своим правилам собирает контент, пишет тексты и настраивает воронки.

Отправить статью в Telegram