Привет, меня зовут Янина. По основной работе я сейчас помогаю масштабировать стартап, а по вечерам — преподаю разговорный английский на темы продуктовой разработки.
Саммари вебинара ниже — это часть закрытого интенсива, который я собрала вокруг серии вебинаров с платформы 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 самостоятельно исправил баг, отправил пул‑реквест, и он прошёл все проверки. Это позволяет команде двигаться гораздо быстрее.
В заключение Лорен повторяет, что путь к доверию не имеет коротких обходных путей. Каждый разработчик имеет свои стандарты качества, и только через постоянное наблюдение, создание навыков и их автоматическую проверку можно достичь того уровня, когда агенты будут работать на автопилоте, а вы сможете сосредоточиться на более высокоуровневых задачах.
Комментарии (8)
german11235
08.09.2026 05:39Спасибо за перевод. Тема довольно интересная жаль только, что сам вопрос доверия — то ради чего статья существует вообще не раскрыт.
Риторика Лорен полна подменой понятий, противоречий и не подкрепленных утверждений поэтому не могу просто пройти мимо. Сюжетная канва вообще очень странно устроена. С одной стороны выдвигается тезис, что основная проблема в доверии, но в то же время на протяжении всего спича проблемой является отсутствие у агентов умения решать конкретные задачи без участия человека.
Дальше тезисно
Когда вы не доверяете агенту, вы вынуждены постоянно вовлекаться в процесс и проверять каждое действие. Это сильно ограничивает вашу продуктивность, вы не можете распараллелить работу и запустить сразу много агентов, потому что не верите ни одному из них.
Можем, просто результат придется проверять в конце. Мне не нравится, что количество строк кода и набор закрытых PR выдается за валидную метрику продуктивности. В каком году мы живем? Не думал, что мемы про индусский код и разработку через количество станут новой веткой реальности.
Лорен показала кривую, на которой по вертикали отложен уровень доверия, а по горизонтали — время
А рядом на заборе нарисовала граффити. Что доказывает кривая? В каких единицах измерения доверие отмечено? Корреляция с количеством агентов и доверием кем измерена?
Верификация означает способность агента самостоятельно запускать код, снимать CPU‑трассировки, открывать симулятор iOS или иным способом проверять свою работу в реальной среде
Верификация означает не это. Она означает, что у нас есть механизмы проверки кода на соответствие спецификации. Написанной людьми между прочим. Это могут быть как статические инструменты, так и человек в виде принимающего лица. Здесь проводится попытка провернуть слушателя на половом органе поскольку с одной стороны мы хотим доверять LLM через средства проверки и в то же время считаем, что LLM сама способна выступить в его роли. Нет тут гарантий никаких.
Верификация не гарантирует, что код будет хорошим в смысле архитектуры, но она гарантирует, что код будет корректным. А это уже огромный шаг вперёд к доверию.
То есть тупо проверили, что код компилится, проходит линтеры и проставили галочку "проверено". Нужен кто-то или что-то, что проверяет правильность того, что мы сделали и LLM здесь не подойдет поскольку она и есть источник кода. Так понимаю здесь речь идет о TypeScript, а если у нас не Rust/Go/Java, а что-то динамическое? Получается и этих механизмов нет, остается только доверять автотестам от той же LLM.
Лорен проводит параллель с управлением людьми. Если вы менеджер и не доверяете своей команде, вы начинаете микроменеджерить, тратить время на проверку каждого коммита. Точно так же с агентами.
За подобную софистику надо помидорами закидывать. Здесь попытка наделить LLM человеческими качествами через проведение аналогии. Нет их, агент это просто программа работающая на базе языковой модели. Да, иногда хорошо работает, а иногда и нет. Проверка как раз об этом.
В CI реализованы проверки на уровне графа зависимостей, чтобы код из рендерер‑процесса не импортировал тяжеловесные модули, которые должны работать только в главном процессе Electron. Запрещены все паттерны, которые плохо обрабатываются агентами: например, useEffect в React, потому что это частая причина проблем с производительностью и агенты часто используют его неправильно.
Ну опять же, это все про то как код выглядит, а не то как он работает. Самое важное понять что код выдает результат, что нам нужен.
Статья имеет нулевую ценность. Описан абсолютно тривиальный путь разработчика работающего с агентами. Сначала просто пробуешь работать с агентом, пишешь вручную весь контекст в диалоговом режиме. Через какое-то время понимаешь, что можно улучшить процесс через написание скилов и спецификации проекта. Потом осознаешь, что контекст не резиновый и начинаешь более качественно писать скилы и управлять им. Затем в помощь приходят готовые инструменты лучше встраивающие информацию о кодовой базе в контекст и т.д.
Описанный подход опирается на предположение, что LLM достаточно умна, чтобы сделать все правильно при наличии поданного контекста. Это утверждение никак не доказано и все механизмы нацеленные на подсовывание машине нужных инструкций это костыльные попытки заставить гомункула делать то, что нам надо. Сегодня одна модель, завтра другая. Новые веса, новый вендор, обучение на новом датасете и можем перестать уметь выполнять задачи которые раньше хорошо решались. Проблема тут в том, что LLM это статистическая модель работающая с вероятностями, а система проверки должна работать детерминировано.
Все время пишем скилы, спеку и инструменты, чтобы система работала автономно... где же тут автоматизация? :)
datamafia Автор
08.09.2026 05:39Автоматизация в том, что у коллег уже ai-native разработка и код руками они не пишут, не ревювят, и не тестируют, и результат - 800 PR как раз в том, что все скиллы и инструменты уже настроены.
Вы, видимо, не поняли, что Лорен все рассказала по тезису - основная проблема в доверии и как они ее решают, чтобы один человек мог управлять тысячами агентов.
Агенты умеют решать конкретные задачи без участия человека, поэтому у нее сейчас и 800 PR, и сотрудник в Курсоре вовлекается на уровне evals и governance.
Ну и вот это ваше высказывание "Описанный подход опирается на предположение, что LLM достаточно умна, чтобы сделать все правильно при наличии поданного контекста" - вообще не в тему ) Всю статью она рассказывает, как они выстроили тулзы контроля, чтобы LLM все сделала правильно )
german11235
08.09.2026 05:39Так, а где контроль то, что LLM сделала все правильно? Нет примера из разряда — вот у нас есть задача по которой есть спека, наш агент её выполнил так-то и так-то, затем рой агентов + некие утилиты доказали, что решение соответствует спеке. В этой точке в статье должно появиться описание инструментов и то как они гарантируют проверку логики. Некий способ доказать изоморфность постановки задачи к её решению. Метрики, цифры и так далее, описание дрифта с целевым решением на разных конфигурациях инструментов и LLM моделей. Без всего этого тезисы голословные и ничем не подкреплены.
Я тоже могу включить в yolo моде агента, заставить его писать код и настроить проверки в CI. Не бог весть какая задача, Claude такое за пару вечеров сварганит вот только доверия к этому подходу ровно столько насколько я уверен в промптах, инструкциях и возможностях модели.
Автоматизация в том, что у коллег уже ai-native разработка и код руками они не пишут, не ревювят, и не тестируют, и результат - 800 PR как раз в том, что все скиллы и инструменты уже настроены.
Количество не аргумент, можно и большие цифры выдавать хоть со скилами хоть без. Особенно при неограниченных ресурсах. Если код никто не ревьюит, и не тестирует, то как же так выходит, что мы думаем, что он соответствует логике? То, что принято сейчас называть автоматизацией не то, чтобы действительной ей является. Решение все равно создаю я. Описываю спецификацию, проектирую архитектуру и придумываю процессы. Написание кода агентом это финальная часть решения, которая не является боттлнеком сама по себе. Это ускорение клавиатуры. Нужна метрика подтверждающая, что описание достаточно точной задачи, которую агент сможет реализовать без уточнений будет эффективнее, чем написание самому с нуля иначе автоматизация иллюзорна.
Тейк про то, что скилы написаны и инструменты настроены я не принимаю. По Станиславскому «Не верю!». Пока продукт является конструктором из готовых компонент такой подход ещё с пивом покатит, однако достаточно сменить язык проекта, домен или вкорячить новую фичу на базе технологий под которую нет скилов и начинается новая итерация prompt engineering. Да и под каждую фичу все равно надо описать задачу. При этом если домен сложный, то без профильных знаний никуда, например разработка ОС или работа с медицинским оборудованием.
сотрудник в Курсоре вовлекается на уровне evals и governance
В статье этого нет, а стадии довольно интересные.
Лорен все рассказала по тезису - основная проблема в доверии и как они ее решают
Для Лорен сам факт наличия инструментов намеренных повысить качество кода повышает уровень доверия. Оно и понятно, степень ошибки в домене в котором она работает не столь высока. Насколько я могу догадываться речь идет ещё и о фронтенде за счет чего мы получаем быструю петлю обратной связи потому что можем увидеть проблему глазами.
datamafia Автор
08.09.2026 05:39"Так, а где контроль то, что LLM сделала все правильно?" - удивительно, что у вас столько времени здесь писать и нет времени погуглить (прочитайте про агентские циклы в ai-native sdlс, про то, как выстраивают evals и тд.) Я просто по второму разу вам отвечаю, что весь воркшоп про то - как выстроена система контроля, чтобы агенты сделали все правильно.
german11235
08.09.2026 05:39В стадии evals нет никакой магии, гуглить тут особо нечего. Это просто этап, где мы запускаем разнородные механизмы проверки и реализуем сценарии тестирования. Они делятся на два подмножества:
детерминированные (линтеры, типы, санитайзеры, срезы перформанса и т.п.) — измеримы, область применимости известна и вычислима
недетерминированные на базе LLM (judge-системы, агентская кросс-валидация и т.д.) — измерения возможны, но метрики шумные и границы применимости заранее неизвестны
В каждом проекте свой набор практик, но ключевое препятствие на пути к доверию как раз в недетерминированных гейтах. Дело в том, что мы не можем напрямую посчитать границы компетентности модели. Измерить можем, но только как эмпирическую частоту на своей выборке — условно, coverage по компетенциям не посчитать. Из того, что вчера задача из той же области решилась полностью автоматически, не следует, что сегодня задача X решится.
Помимо этого, ошибки судьи коррелируют с ошибками источника. Чтобы их избежать, можно взять разные модели для судейских агентов, но корреляцию они уберут не полностью. Модели обучаются примерно на тех же корпусах, по схожим методикам, поэтому в спорном месте спеки с высокой вероятностью выберут ту же развилку, и тогда проверка подтвердит корректное решение не той задачи. Многослойная проверка работает только при независимости слоёв, а здесь её нет.
Отсюда и вопрос, а может ли с принципиальной точки зрения LLM выступать наблюдателем на стадии верификации или нет, и если нет, то какими механизмами можем преодолеть это при помощи детерминированных проверок в CI. У меня нет ответа, да и ни у кого, пока проблема решается на человеческой тяге там, где ошибка чревата хоть какими-то последствиями, кроме перезалива PR.
Лорен не поставила эту проблематику и не привела пример метрик и механизмов, которые помогут быть уверенным в результате. Диагностика компилятора и прогон линтеров — это, конечно, хорошо, но они закрывают конкретный класс ошибок и ничего не говорят о соответствии спецификации. Агентское судейство на этапе верификации — рабочая практика, не спорю, но доказательства надёжности носят эмпирический характер и их надо предъявлять.
Например, можно было рассказать пару слов про мутационное тестирование: намеренно вносим в код дефекты и смотрим, сколько из них ловят тесты, написанные агентами. Доля пойманных (kill rate) как раз показывает, чего эти тесты стоят. Маленькая деталь, а даст неподготовленному читателю больше, чем весь спич.
По цифрам: и в заголовке, и в статье упоминаются 800 PR — в них нет смысла без контр-показателей. Предметный разговор случится, когда покажут долю PR, вернувшихся на доработку к человеку, процент откатов и хотфиксов, долю ошибок, доехавших до прода, и стоимость токенов на принятый PR. Тезис «руками не пишут, не ревьюят и не тестируют» вообще противоречит статье.
AI-native разработка — интересная и классная штука, чужой опыт полезен. Однако у всего есть цена, и она никак не отражена в статье. Восторженный доклад энтузиаста — это нормально, но нужно подтверждать громкие заявления цифрами. Если у Лорен всё так классно работает, как она пишет, то ей впору не PR мерджить, а патентовать пайплайн, потому что проблема сейчас на фронтире исследований и возможность практически выкинуть человека из цикла — как золото Эльдорадо, но пока в руках только лопаты :)
Lisa
08.09.2026 05:39Спасибо, всегда интересен чужой практический опыт, даже если он и не применим полностью
panzerfaust
Где-то в недрах мэрии Москвы проводят интенсив по перекладыванию плитки. Хвастаются, что за прошлый месяц переложили 1000 квадратных километров плитки, а за первые 12 дней этого месяца - уже 800. Причем благодаря выстроенной архитектуре Råspeel результат можно даже не проверять! Бригады работают автономно, а ты только подписываешь сметы! Автор доклада признаётся, что работает в условиях неограниченных бюджетов на благоустройство.