Как заставить компанию внедрить ИИ-агентов для кодинга (и не завалить проект багами) — Эяль Блум, Figma

AAI Engineer
Computing/SoftwareManagement

Transcript

00:00:00Эяль Блам: Добрый день, меня зовут Эяль Блам, я инженер-программист в Figma, и
00:00:17в сегодняшнем выступлении мы поговорим о том, как мы адаптировали или адаптируем агентов в
00:00:25наш рабочий процесс в Figma, сохраняя при этом высокое качество нашей кодовой базы.
00:00:32Как вы знаете, Figma — это браузерный редактор, где дизайн, разработка и теперь уже
00:00:40ИИ-агенты сотрудничают вместе для выпуска кода.
00:00:44Figma очень решительно переориентировалась с традиционного инструмента на инструмент с приоритетом ИИ,
00:00:52но в этом выступлении я буду говорить не о нашем продукте, а больше о нашей
00:00:55внутренней организации и о том, как наша инженерная структура адаптирует ИИ-агентов.
00:01:04И внутри компании мы обнаружили, что как для организаций, компаний, так и для отдельных лиц существует
00:01:11трехактный процесс внедрения ИИ.
00:01:16Вы начинаете с того, что берете что-то — будь то многие люди в этой комнате,
00:01:21которые глубоко увлечены ИИ и пользуются им уже давно, — берут что-то и добиваются того,
00:01:27чтобы простые вещи работали отлично, в 10 раз быстрее.
00:01:30Затем вы начинаете применять те же практики к более крупным задачам, и ИИ справляется с этим довольно плохо, выдает плохой результат,
00:01:40множество багов.
00:01:41Доверие, которое вы построили, разрушается, и с этого момента вы начинаете нарабатывать настоящий навык — то есть
00:01:50учитесь правильно использовать ИИ, ставить правильные защитные барьеры, делать правильные промпты,
00:01:55обеспечивать нужный контекст и всё то, о чем мы весь день говорили здесь и во всех выступлениях, чтобы действительно развить реальный навык.
00:02:02И одна вещь, которая происходит внутри компании: по мере того как мы внедряем ИИ (команды или отдельные лица), это внедрение происходит неравномерно.
00:02:12У нас есть команды, которые очень ориентированы на ИИ и уже полностью перестроили свои рабочие процессы, а есть команды, которые все еще экспериментируют на более раннем этапе и/или потеряли уверенность, и всем им нужно работать вместе, чтобы выпускать наш продукт.
00:02:28Поэтому они должны сосуществовать в организации, и нам нужно найти способ поддерживать их, одновременно привлекая всех к этому путешествию и доводя каждого до третьего акта истории.
00:02:44Помимо этой основной точки трения, мы заметили и другие трудности, возникающие при внедрении ИИ.
00:02:54Одна из вещей, о которых часто говорят разработчики и которые замечают менеджеры, заключается в том, что снижение самостоятельности разработчиков заставляет инженеров терять часть удовлетворения от работы.
00:03:04Многие люди раньше получали большую гордость и удовольствие от написания кода и вхождения в состояние потока, и многим кажется, что это было утеряно или что они теряют большую часть этого элемента и переходят к циклу промптов, где они просто ждут вывода от ИИ и общаются с ИИ, а это уже не так весело, как раньше.
00:03:22Мы заметили еще одну интересную вещь: на самом деле наши лучшие инженеры хотят держать весь контекст в своей голове, и в итоге они сталкиваются с огромной нагрузкой. Получается так: они знают все подводные камни, они с помощью ментального скотча удерживают вместе все места, где агенты работают плохо, и предотвращают проникновение по-настоящему плохих вещей, либо у них есть весь институциональный контекст, который никогда
00:03:52не был записан — он держится у них в голове, и они принимают на себя такую нагрузку, что становятся узкими местами и сильно разочаровываются, поэтому в итоге они внедряют нововведения даже медленнее, так как первыми видят все проблемы.
00:04:04Это еще одна крупная проблема, с которой мы столкнулись, и она, я уверен, отзовется у каждого здесь: внезапно все проектные документы, все сообщения в Slack и все электронные письма стали в три или четыре раза длиннее, и мы получаем в два-три раза больше писем, при этом они содержат примерно столько же пользы, сколько и раньше.
00:04:28Таким образом, коммуникация стала довольно неэффективной, и ориентироваться в том, что является действительно качественным и важным, а что — не очень, стало сложно.
00:04:40Поэтому следующие несколько минут я потрачу на то, чтобы рассказать о некоторых извлеченных нами уроках и о том, как мы пытаемся их применять.
00:04:50Это долгий путь, мы еще не вышли на финишную прямую, но видим весьма интересный прогресс по многим направлениям.
00:04:57Я думаю, многие выступающие здесь касались этого, но инвестиции в верификацию — это, пожалуй, самое ценное, что мы можем сделать для нашей кодовой базы.
00:05:11Всякий раз, когда мы можем сместить что-то влево в нашем рабочем процессе — от необходимости выполнения человеком к возможности проверки агентом.
00:05:19Например, когда появился Playwright MCP, вместо того чтобы заставлять людей вручную исследовать код, теперь агент может сам изучать код, и это стало мощным толчком к росту производительности для многих наших команд.
00:05:33Это действительно всегда большая победа для нас.
00:05:37Более того, когда вы находите что-то, что агент счел полезным, найдите время взять это и зафиксировать в виде детерминированного процесса.
00:05:51Детерминированный процесс, который можно легко повторять, экономит токены и время для вас, а также гарантирует, что вы используете LLM тогда, когда ей действительно нужно рассуждать.
00:06:01Но когда у вас есть что-то уже известное, что в принципе можно закодировать в виде теста, затраты времени на это всегда окупаются сторицей.
00:06:11И еще один совет: если вы скажете своим навыкам или вашему агенту писать код так, как пишете его вы — в стиле TDD (от красного к зеленому), — это практически всегда дает лучшие результаты.
00:06:26Потому что вы задаете цель, а затем говорите агенту стремиться к этой цели.
00:06:30Это почти всегда дает лучшие результаты при написании кода и последующем написании тестов, потому что тогда тест подгоняется под код, а не код подгоняется под прохождение критериев проверки.
00:06:42И это пирамида тестирования — классическая пирамида тестирования из прошлого, если вспомнить сами тесты: сквозные тесты (E2E), интеграционные и модульные (unit) тесты.
00:06:54Здесь подход очень похожий: смещайте как можно больше вниз, к детерминированному анализу — линтингу, компилятору и самим модульным тестам. Все, что можно легко покрыть, может проверяться агентом на основе критериев
00:07:12и архитектурных стандартов, которые были...
00:07:15И архитектурные стандарты, которые были легко закодированы в кодовой базе, можно переложить на агента.
00:07:19И лишь на самом верху вам понадобится какая-то человеческая проверка, которая обычно касается функциональности. Оставляйте людям только то, чем действительно должны заниматься люди.
00:07:31И еще одна действительно важная вещь — это планирование в противовес промптингу. Это напрямую связано с возвращением разработчикам самостоятельности и поиском замены ремеслу написания кода.
00:07:50Поэтому трата большого количества времени на составление плана с последующей отправкой его агенту в качестве готовой задачи для автоматической реализации — это то, что, как мы обнаружили, действительно возвращает радость создания в этот процесс.
00:08:07И поэтому нет ничего необычного в том, чтобы потратить неделю на написание очень подробного плана, принятие всех решений, их проработку, итерации и отправку коллегам на рецензию.
00:08:17И только когда всё готово и вы продумали каждое решение, вы можете отправить это агенту, и агент вернет вам уже реализованный код.
00:08:26И это оказалось очень успешным как в плане ускорения, так и в плане возвращения радости в процесс разработки.
00:08:36Итак, что же делает план хорошим? Очень важно начинать с «почему» в самом верху.
00:08:43Это очень помогает предотвратить отклонение агента от курса (drift), если у вас есть жирный крупный раздел вроде того, что бывает при написании проектного документа.
00:08:49Вам нужно указать там краткое содержание для агента, иначе со временем он начнет отклоняться от курса; и убедитесь, что агент не станет возвращаться и менять это просто потому, что ему так захотелось.
00:08:58Поэтому мы начинаем с «почему» и следим за тем, чтобы план можно было разбить на небольшие части, каждую из которых можно проверить независимо.
00:09:08И мой личный способ понять, какой размер является подходящим: захочу ли я рецензировать PR, соответствующий этой части, если он окажется слишком большим, чтобы прочитать его за один присест?
00:09:18Тут примером служит мысль: «Мне нужно выпить чашку кофе перед тем, как читать это».
00:09:22Это значит, что задача слишком велика, и я захочу разбить ее на части.
00:09:26И затем я убеждаюсь, что каждую часть можно проверить независимо, потому что я не хочу получить ситуацию, когда есть пять этапов, первый из которых написан, но не проверен, а все остальное строится поверх этих непроверенных предположений.
00:09:41Поэтому наличие некоего шлюза валидации или критериев приемки для каждого этапа очень помогает сделать план устойчивым к отклонениям.
00:09:51Конечно, есть множество технических нюансов управления контекстом и создания поверх этого некоей «фабрики ПО».
00:09:58Но как только у вас есть план, вы можете использовать любой цикл или любой рабочий процесс, который захотите, чтобы его реализовать.
00:10:05И это скриншот плана, который я случайно выбрал, но вот что я обычно ищу.
00:10:12Краткое содержание в самом верху.
00:10:14Фазы разбиты на части, и каждая из них детализирована настолько, чтобы я мог просто передать ее субагенту.
00:10:20И субагент может независимо работать над этим, ни о чем больше не беспокоясь.
00:10:24Конечно, существуют и другие рабочие процессы или иные структуры планов.
00:10:29Я считаю, что одна из прекрасных особенностей ИИ-процессов заключается в том, что каждый может настроить то, что работает лучше всего именно для него.
00:10:41Нет, спасибо.
00:10:43Каждый может очень легко настроить рабочий процесс, который подходит исключительно ему.
00:10:47Поэтому попытки централизовать всех на чем-то одном приносят лишь убывающую отдачу.
00:10:51Но пока это работает для их потока и другие могут взаимодействовать с ними, я считаю, что в целом это работает очень хорошо.
00:10:58И это просто пример — своего рода похвальба — того, каким может быть результат реализации плана.
00:11:04Здесь, пожалуй, штук 20 PR (пулл-реквестов).
00:11:07Некоторые из них содержат строк по 10, некоторые — по 100, но вряд ли что-то больше этого.
00:11:12И это позволяет нам... В мире до появления ИИ над таким планом работали бы неделю.
00:11:19Я бы согласовывал его с тремя другими командами еще неделю, а затем просто отправил агенту на реализацию за ночь.
00:11:26И он вернулся... (это, наверное, по двум планам, а не по одному), но по сути шесть недель работы над кодом заняли всего одну неделю.
00:11:36Так что вот откуда берется пятикратное ускорение.
00:11:40Если учесть цикл ревью в конце, о котором всегда нужно помнить.
00:11:45Переходя от планирования обратно к проблеме со скептиками и людьми, на которых падает больше всего работы.
00:11:53Убедитесь, что вы привлекаете их и очень серьезно относитесь к их отзывам.
00:11:59Они скептичны, потому что видят, где вам не хватает валидации, где ваши инструменты дают сбой.
00:12:05Так что их отзывы — это по сути дорожная карта того, как улучшить вашего агента и взаимодействие с кодовой базой.
00:12:12Просто привлеките их к делу, вместо того чтобы пытаться заставить их использовать ИИ.
00:12:19Поручите им руководить дорожной картой по обеспечению безопасности ИИ в вашей организации.
00:12:25И они присоединятся, как только увидят, что улучшения, которые они вносят, действительно делают их жизнь лучше.
00:12:33И как вы можете видеть, они без стеснения скажут вам, что именно нужно исправить.
00:12:37Это результат менее чем часового совещания с группой людей.
00:12:40И это плоды мозгового штурма.
00:12:45Еще одна вещь, которая очень помогла именно моей команде (и мы работаем над внедрением этого в организации в целом),
00:12:53— это обеспечение коммуникации с учетом человеческого внимания.
00:12:58В эпоху ИИ человеческое внимание — дефицитный ресурс.
00:13:01Думаю, я слышал это на нескольких выступлениях, и многие пришли к такому же выводу.
00:13:06Вы не можете получить больше внимания людей.
00:13:08Поэтому то, на что вы тратите время и что читаете, становится очень важным.
00:13:13И поскольку это такой дефицитный ресурс, различие между тем, что сгенерировано ИИ, и тем, что написанно человеком, очень помогает понять, сколько времени нужно потратить на чтение,
00:13:24и на какую глубину проработки можно рассчитывать в этой части коммуникации.
00:13:31И это своего рода создание новой культуры вокруг такого стиля общения.
00:13:35Это очень помогает.
00:13:36И, например, в команде, с которой я работаю, мы решили, что каждое описание PR всегда будет начинаться с чего-то подобного.
00:13:45То, что я написал от руки, может быть очень кратеньким описанием того, что это делает, а затем уже идет описание от ИИ.
00:13:54Просто... я, наверное, это прочту.
00:13:55Я, вероятно, отредактирую это, чтобы убрать ошибки, но ведь не каждую строчку здесь писали они.
00:14:00Поэтому они должны быть более подозрительными, уделять больше внимания тому, что я написал наверху, и при необходимости переписывать это.
00:14:05Подобные вещи в Slack, в электронной почте — просто признание того факта, что все знают, что вы используете ИИ для составления сообщений,
00:14:15но не бойтесь сказать им, что стоит прочитать внимательно, а чему можно уделять меньше внимания.
00:14:21И я помню, как в начале года я попытался... у нас в компании были старшие инженеры, которые были большими скептиками по отношению к ИИ,
00:14:35и я попытался обратиться к ним, чтобы понять, в чем проблема, что происходит, и сказал, что попытался запустить анализ некоторых написанных ими комментариев к PR,
00:14:42и, конечно же, я использовал для этого ИИ.
00:14:45И при этом я не слишком четко разделил то, что написал сам, и то, что сгенерировал ИИ, и они очень расстроились.
00:14:54Они такие: почему ты присылаешь... я никак не ожидал от человека, которого так сильно уважаю, получить нечто настолько небрежное.
00:15:02И тогда я... я извинился.
00:15:05Я понял, что должен был четко все пометить и обозначить свои намерения.
00:15:08Мол, вот что написал я.
00:15:10А это написал ИИ, и мне нужен ваш отзыв, потому что у меня нет контекста, чтобы понять, небрежно это или нет.
00:15:15И именно об этом я вас прошу.
00:15:17Так что подобные уроки и изменение культуры важны ровно так же, как и некоторые инженерные проблемы, с которыми мы сталкиваемся.
00:15:28Еще одна вещь, которая очень помогает во внедрении — по мере продвижения вперед мы внедряем множество очень навороченных инструментов и рабочих процессов.
00:15:41Но одним из самых эффективных подходов является просто позволить людям использовать ИИ там, где они есть.
00:15:47Это действительно помогает нормализовать использование ИИ для повседневных задач и снижает барьеры.
00:15:54Пожалуй, одна из самых мощных возможностей — это способность упомянуть агента в сообщении в Slack вместе с кем-то и сказать: можешь просто сделать это для меня?
00:16:02И сделать так, чтобы агенты доводили дело до конца прямо в треде?
00:16:07И такие вещи действительно впечатляют.
00:16:09А поверх этого можно настроить всю эту автоматизацию и прочие сложные штуки.
00:16:14Но если вы общаетесь с тем, кто еще не до конца вовлечен, можно без пассивной агрессии упомянуть агента и сказать: давай попробуем и посмотрим, справится ли агент на этот раз.
00:16:26И если они доводят дело до конца, и это оказывается удачным опытом, это помогает людям попробовать применить это самостоятельно в других ситуациях.
00:16:33И наше путешествие продолжается.
00:16:37Мы все еще учимся: несмотря на то, что мы внедряем ИИ для внешних пользователей, наш процесс его принятия и эксперименты идут постоянно, а автоматизация пока еще не полностью доведена до ума.
00:16:50Мы все еще пытаемся понять, когда и как мы можем эффективно использовать Cloud Agent, учитывая все зависимости нашей системы сборки.
00:16:58Так что мы продолжаем учиться.
00:17:01Это культурный сдвиг.
00:17:02Это инженерный сдвиг.
00:17:03И не знаю как вы, а я работаю в Долине последние 15 лет, и это на порядки крупнейшее изменение из всего, что я видел в плане культуры и технологий.
00:17:16Так что мы все здесь вместе и вместе во всем разбираемся.
00:17:19И именно об этом я хотел сегодня с вами поговорить.
00:17:22Спасибо.
00:17:28Спасибо.

Key Takeaway

Переход инженерных команд на ИИ-агентов требует смещения верификации влево, детального планирования задач перед промптингом и учета дефицита человеческого внимания при коммуникации.

Highlights

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

  • Смещение верификации влево с помощью таких инструментов, как Playwright MCP и модульных тестов, позволяет агентам проверять код по архитектурным стандартам до участия человека.

  • Написание детального плана на неделю перед передачей задачи агенту возвращает разработчикам радость создания и ускоряет процесс написания кода в пять раз.

  • Разделение коммуникации на созданную человеком и сгенерированную ИИ экономит дефицитный ресурс внимания в инженерной команде.

  • Привлечение скептиков к управлению дорожной картой безопасности ИИ превращает их критику в карту улучшений для кодовой базы.

Timeline

Трехактный процесс внедрения ИИ и возникающие трудности

  • Внедрение ИИ в организациях делится на три акта: быстрый старт на простых задачах, кризис качества на сложных задачах и освоение защитных барьеров.
  • Использование ИИ снижает самостоятельность разработчиков и лишает их удовольствия от погружения в процесс написания кода.
  • Лучшие инженеры берут на себя колоссальную нагрузку, пытаясь удерживать весь контекст в голове и предотвращать ошибки агентов.
  • Объемы проектных документов и писем в Slack выросли в три-четыре раза без пропорционального роста их пользы.

Адаптация ИИ-агентов в Figma происходит неравномерно между командами, создавая точки трения. Простой перенос привычек на крупные задачи приводит к падению доверия из-за багов. Инженеры сталкиваются с профессиональным выгоранием, превращаясь в проверяющих чужой текст, а переизбыток сгенерированной информации размывает фокус внимания.

Инвестиции в верификацию и смещение тестов влево

  • Смещение верификации влево за счет инструментов вроде Playwright MCP автоматизирует исследование кода агентами.
  • Перенос успешных сценариев в детерминированные процессы экономит токены и время на рассуждения LLM.
  • Стиль TDD от красного к зеленому заставляет агента писать код под заранее заданную цель, повышая качество тестов.
  • Пирамида тестирования перекладывает линтинг, компиляцию и модульные тесты на плечи агента, оставляя людям функциональную проверку.

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

Планирование задач как замена прямому промптингу

  • Траты времени на составление подробного плана перед передачей задачи агенту возвращают разработчикам творческую радость.
  • План должен начинаться с раздела «почему», чтобы предотвратить отклонение агента от курса.
  • Разбиение плана на независимые части с критериями приемки позволяет независимо проверять каждый пулл-реквест.
  • Шесть недель работы над кодом без ИИ сокращаются до одной недели при грамотном разбиении на задачи для субагентов.

Простое написание промптов не заменяет инженерное мышление. Создание подробного плана на неделю вперед требует проработки всех решений заранее. Критерий готовности PR измеряется желанием прочитать его за один присест без чашки кофе. Полученные десятки мелких пулл-реквестов собираются в масштабные релизы в разы быстрее традиционных методов.

Работа со скептиками и управление вниманием в коммуникации

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

Опыт работы со скептиками показывает важность прозрачности в использовании ИИ. Отсутствие разделения авторства в комментариях к коду вызывает разочарование коллег. Культурные изменения требуют новой этики общения, где каждый открыто обозначает роль ИИ в созданных документах, сохраняя при этом доверие и продуктивность команды.

Community Posts

No posts yet. Be the first to write about this video!

Write about this video