Привет, меня зовут Янина. По основной работе я сейчас помогаю масштабировать стартап, а по вечерам — преподаю разговорный английский на темы продуктовой разработки.
Саммари вебинара ниже — это часть закрытого интенсива, который я собрала вокруг серии вебинаров с платформы Maven про ИИ‑кейсы из американского бигтеха. Сначала мы смотрим прямой эфир с практиками из Cursor, Meta, Netflix и подобных компаний, а на следующий день — разбираем в мини‑группе. Мы смотрим не адаптированный учебный английский, а живую речь людей, которые прямо сейчас строят продукты на агентах, и вытаскиваем оттуда лексику и лайфхаки.
Вебинар, из которого я сделала статью, провела Лорен Тан из компании Cursor. Тема вебинара — доверие к ИИ‑агентам в разработке: как дойти до того, что агенты сливают PR без твоего участия (про выстроенную систему верификации).
Ниже — саммари для тех, кто хочет разобраться в кейсе на русском. Enjoy )
Лорен Тан пришла в Cursor пять месяцев назад, до этого она работала в Meta над React‑компилятором и в Netflix техническим лидом. Она рассказывает о том, как выстроила работу с агентами, которая позволяет ей просыпаться и видеть 20 уже объединённых пул‑реквестов без необходимости лично проверять каждый из них перед мерджем. Она считает, что ключевая проблема при работе с агентами — это доверие. Когда вы не доверяете агенту, вы вынуждены постоянно вовлечекаться в процесс и проверять каждое действие. Это сильно ограничивает вашу продуктивность, вы не можете распараллелить работу и запустить сразу много агентов, потому что не верите ни одному из них.
Лорен проводит параллель с управлением людьми. Если вы менеджер и не доверяете своей команде, вы начинаете микроменеджерить, тратить время на проверку каждого коммита. Точно так же с агентами. Но если вы можете выстроить систему, которая даёт вам уверенность в их работе, вы переходите на новый уровень, где агенты работают автономно, а вы только просматриваете уже принятые изменения.
Лорен показала кривую, на которой по вертикали отложен уровень доверия, а по горизонтали — время. Еще год назад, когда мало кто использовал агентов для написания кода, разработчики были вынуждены сидеть рядом с агентом, читать каждый вывод, поправлять промпты и не могли запустить больше нескольких агентов параллельно. Лорен признаётся, что её первый месяц в Cursor был не очень продуктивным, потому что она только осваивалась в кодовой базе и не понимала, что делают агенты. Однако по мере того как она нарабатывала навыки управления агентами, её личная продуктивность резко выросла. В прошлом месяце она объединила тысячу пул‑реквестов, а за первые 12 дней текущего месяца уже почти 800. Это звучит невероятно, и она понимает, что у слушателей возникает вопрос о качестве такого кода. Длина PR от 50 до 1000 строк.
Главный навык, по мнению Лорен, в арсенале любого, кто работает с агентами — это верификация (AI Evals). Верификация означает способность агента самостоятельно запускать код, снимать CPU‑трассировки, открывать симулятор iOS или иным способом проверять свою работу в реальной среде. Это замыкает цикл. Верификация не гарантирует, что код будет хорошим в смысле архитектуры, но она гарантирует, что код будет корректным. А это уже огромный шаг вперёд к доверию.
В качестве примера Лорен рассказывает историю с окном агента в Cursor, которое внутри компании называют Glass. Когда она пришла, ей поручили помочь с этим компонентом, так как он написан на React, а у неё был соответствующий опыт. Но сроки были очень сжатыми, и она поняла, что не может разобраться в проблемах производительности в одиночку. Она открывала Chrome DevTools, смотрела на флейм‑графы, но кодовая база была для неё новой. Тогда она решила привлечь агента, но агент тоже не имел понятия, что ему делать. Процесс шёл медленно, потому что она была единственным верификатором — она запускала сборку, видела, что не работает, копировала ошибки и скриншоты, передавала агенту, ждала правок, и так по кругу. Это было узким горлышком.
Тогда она создала skill под названием control glass, который позволял агенту самостоятельно управлять процессом, то есть запускать локальную сборку, подключаться через Chrome DevTools Protocol, снимать трейссы и анализировать их. Но даже после этого агент не знал, как устроено само окно агента. Если кто‑то сообщал, что левая боковая панель тормозит или вкладка PR не работает, агент начинал беспорядочно искать в коде, не понимая, как добраться до нужного элемента интерфейса. Это делало его почти бесполезным.
Решением стала карта функций — feature map. Это файл, в котором описаны все основные элементы интерфейса — как до них добраться, какие есть сочетания клавиш, какие DOM‑атрибуты используются для выделения элементов через CDP. Лорен реализовала это в своём плагине Pstack, который можно найти по запросу «Pstack cursor». В нём есть команда create verification skill, которая анализирует код и строит начальную карту функций. Это позволяет агенту обрабатывать даже очень расплывчатые отчёты, например просто скриншот с тремя вопросительными знаками. Агент знает, где находится та или иная функция, как воспроизвести действие и что искать.
Плагин Pstack — предоставляет агентам улучшенный контекст о кодовой базе, функциях и способах навигации по ним. Этот плагин опирается на библиотеку Pretext (Лорен рекомендует глянуть что это такое) для обеспечения надежной верификации и снижения необходимости в постоянном ручном контроле.
Плагин Pstack родился не как отдельный продукт, а как набор skills, которые Лорен писала для себя, наблюдая за сбоями агентов. Она замечала, что агент часто уверенно заявляет о причине ошибки, не прочитав код, который мог бы быть затронут. Тогда она создала навык HAL, который предписывает агенту не гадать, а всегда читать соответствующий код и использовать субагентов для поиска. Это похоже на работу с новым инженером, который не знает бизнес‑контекста. Вы даёте ему инструкции, и через навыки вы можете вытянуть из модели гораздо больше интеллекта, потому что LLM работают по принципу предсказания следующего токена, и если вы дадите им качественные начальные токены, они будут следовать более разумному паттерну.
Но skills.md нужно поддерживать, потому что продукт меняется. Для этого Лорен использует evals — по сути модульные тесты для агентов. В Pstack есть eval playbook, где главный агент‑координатор создаёт рубрику того, что должен делать skill, запускает множество субагентов в отдельных директориях, причём названия директорий подобраны так, чтобы агент не догадывался, что его тестируют, иначе он может изменить поведение. Затем оценивается результат, причём можно использовать разных моделей‑судей для перекрёстной проверки. Лорен запускает такие evals каждый раз, когда меняет skills, и использует циклы (по, чтобы довести оценку до идеала.
Однако ваше наблюдение и чуйка остаются критически важными. Лорен советует быть активным водителем, а не пассивным наблюдателем. Открывайте каждый вызов инструментов, читайте блоки размышления агента, ищите места, где он спотыкается, и превращайте каждое такое место в новый навык.
Когда локальная верификация отлажена, можно переходить к облачным агентам. Лорен подчёркивает, что это следующий уровень, но прыгать сразу от полного контроля к тысяче облачных агентов не стоит — вы только потратите много токенов и денег. Нужно постепенно наращивать доверие.
Внутри Cursor разработчики используют агента по имени Benny, который автоматически обрабатывает все входящие отчёты об ошибках. Вenny запускается в облаке, открывает свой собственный экземпляр Cursor, использует те же skills верификации для навигации по приложению и пытается воспроизвести проблему. Если баг уже исправлен в основной ветке, Вenny подтверждает это, и остаётся только выпустить новую сборку. Это экономит часы ручного труда и даёт информацию всей команде, а не только отдельному разработчику.
Отдельная тема, которую Лорен затрагивает — это рефакторинг и переписывание кода. Она говорит, что несмотря на то, что в МЕТА десятки тысяч классных разрабов, общее качество кода — не очень хорошее (про текущее качество кода с агентами в Cursor она ничего не сказала, кроме того, что фитбек часто очень плохой). Лорен считает, что проекты, созданные с нуля с помощью вайбкодинга, особенно опасны. Когда нет никаких ограничений, агенты решают каждую задачу самым коротким путём, и со временем кодовая база превращается в хаос, который уже никто из людей не понимает и сами агенты по‑своему в нём разбираются и выстраивают его так, чтобы решать задачи кратчайшим путём, а не так, чтобы это было понятно человеку. В больших компаниях, вроде Meta или Google, есть жёсткие фреймворки, регламенты и защитные механизмы, рассчитанные на самых неопытных инженеров. В такой среде агенты уже могут работать хорошо, потому что ограничения уже встроены опытными инженерами.
Для Grokbot, нового продукта Cursor, который позволяет оркестрировать агентов, Лорен создала архитектуру под названием Dune. Это не открытая библиотека, а набор принципов, которые можно перенять для себя. Главная идея — сделать самый короткий путь одновременно и самым правильным. Например, каждая функция помещается в свою директорию, и агенты знают, что для изменения конкретной функции нужно работать только в этой папке.
СI раздражает своей строгостью, строгие CI‑проверки (запрет useEffect, запрет комментариев, проверки графа зависимостей и так далее) делают процесс написания кода дотошным и раздражающим. В CI реализованы проверки на уровне графа зависимостей, чтобы код из рендерер‑процесса не импортировал тяжеловесные модули, которые должны работать только в главном процессе Electron. Запрещены все паттерны, которые плохо обрабатываются агентами: например, useEffect в React, потому что это частая причина проблем с производительностью и агенты часто используют его неправильно. Даже комментарии в коде запрещены, потому что агенты любят вставлять бессмысленные заметки вроде «Лорен сказала никогда так не делать», что только загромождает код.
Лорен выстраивает систему из нескольких уровней. Самый сильный — это статический анализ и проверки CI, которые жёстко пресекают нарушения. Затем идут линтеры и диагностика компилятора. И только потом правила и навыки, которые агент может забыть применить. Она предупреждает, что если вы полагаетесь только на правила в виде текста, кодовая база быстро превратится в мусор. Поэтому любые замечания, которые вы часто пишете в ревью, должны превращаться в автоматические проверки.
Говоря о затратах на токены, Лорен признаёт, что работает в компании с практически неограниченным бюджетом на токены, но она предлагает рассматривать вопрос как ROI. Да, на начальный рефакторинг и создание навыков уходит много токенов, но если вы решитесь выбрать модель разработки, где агенты пишут большую часть кода, то затраты окупятся за счёт сокращения найма персонала и повышения скорости команды. Кроме того, недавно выпустили модель Grok 4.6, которая при той же стоимости токена стала значительно умнее, что ещё больше улучшает соотношение цена‑качество.
Лорен отмечает, что текущая архитектура приносит пользу не только разработчикам. В Grokbot дизайнеры и продакт‑менеджеры тоже могут отправлять код, потому что строгие ограничения делают процесс безопасным даже для тех, кто не является профессиональным инженером. Например, один из PM самостоятельно исправил баг, отправил пул‑реквест, и он прошёл все проверки. Это позволяет команде двигаться гораздо быстрее.
В заключение Лорен повторяет, что путь к доверию не имеет коротких обходных путей. Каждый разработчик имеет свои стандарты качества, и только через постоянное наблюдение, создание навыков и их автоматическую проверку можно достичь того уровня, когда агенты будут работать на автопилоте, а вы сможете сосредоточиться на более высокоуровневых задачах.
