Transcription
[МУЗЫКА ИГРАЕТ]
ЭНДРЮ МАКВИН: Привет всем. Как дела? Ну что, поехали. Как настроение? Взволнованы? Отлично. Может быть, немного ошеломлены? Любопытны? Надеюсь, любопытны. Хорошо, мы — Эндрю и Николь. Мы оба являемся руководителями команды Developer Intelligence здесь, в Google. И вместе мы посвящаем свою карьеру изучению инженеров-программистов — людей, процессов, инструментов, систем, культуры. И мы хотим начать с признания того, что это важный момент для разработки программного обеспечения. Вы видите такие цитаты, которые действительно подчеркивают не только масштаб момента, но и скорость, с которой происходят изменения. Наша цель сегодня — поделиться некоторыми нашими исследованиями, некоторыми нашими знаниями о том, что мы видим внутри Google, и в конечном итоге ответить на этот вопрос. Как мы, инженеры-программисты, можем продолжать процветать в эпоху, ориентированную на ИИ? Мы сделаем это, рассмотрев эту Т-образную роль инженера-программиста, важность которой действительно растет. Мы подробно рассмотрим некоторые из моделей, которые мы видим в том, как ведется разработка программного обеспечения, навыки и возможности, которые, как мы видим, воплощают лучшие инженеры, и предложим несколько практических советов о том, как вы можете думать о своей роли. Но сначала мы хотим задать тон. Мы хотим убедиться, что мы все на одной волне. Как мы уже говорили, это важный момент. Но что на самом деле происходит? Прежде всего, мы наблюдаем довольно повсеместное внедрение инструментов ИИ для разработки программного обеспечения — вероятно, это ни для кого здесь не сюрприз. Большинство технических специалистов используют ИИ и полагаются на него, во многих случаях, в значительной степени. Мы также видим глубокое влияние. Так, внутри Google 3/4 всего кода пишется ИИ. В то же время люди вполне справедливо спрашивают, действительно ли это повышает производительность? И если да, то на 10%, 10x, 100x? Правда в том, что в некоторых местах наблюдается даже парадокс производительности. Есть некоторые исследования, проведенные нашей командой DORA путем изучения нескольких компаний, которые показывают, что увеличение внедрения ИИ может привести к индивидуальным преимуществам в производительности, в то же время снижая преимущества на уровне команды. За последний год внутри Google мы наблюдали появление действительно интересных закономерностей. Прежде всего, мы видим много преимуществ. Мы не только видим, как ИИ генерирует все больше кода с большей и большей автономией. Мы видим, что при правильной системе, при правильной среде этот код действительно сохраняется. Эта презентация посвящена навыкам и возможностям, которые действительно позволяют этому произойти. Во-вторых, есть некоторые действительно интересные эмерджентные поведения, выходящие за рамки этих основных показателей. Например, мы видим, что инженеры, которые больше всего используют ИИ, фактически тратят больше времени на написание кода, больше времени на обдумывание идей и больше времени на сотрудничество со своими коллегами. Это, возможно, контринтуитивно. Правда в том, что они делают больше этих действий. Форма их просто выглядит немного иначе. Наши лучшие инженеры более активны, а не менее, даже несмотря на то, что они делегируют все больше и больше работы ИИ. Теперь важно отметить, что эти преимущества ИИ не обязательно являются однородными. Мы все знаем старую поговорку: "мусор на входе, мусор на выходе". И мы видели много исследований, посвященных необходимости не только действительно освоить работу с ИИ, но и контекст и область, в которой вы применяете этот ИИ. Кроме того — и это, вероятно, проповедь хору здесь — разработка программного обеспечения — это гораздо больше, чем просто написание кода. И написание кода никогда не было узким местом. Мы говорим здесь о чрезвычайно сложной задаче. Чтобы получить истинные преимущества, нам нужно действительно признать еще две вещи. Во-первых, нам нужно думать об ИИ для всего жизненного цикла разработки программного обеспечения и, по сути, для всего жизненного цикла разработки продукта. Нам нужно думать об ИИ далеко за пределами генерации кода. Во-вторых, речь идет не только о применении ИИ к старым способам работы. Магия на самом деле происходит, когда эти традиционные процессы развиваются и даже трансформируются. Мы переживаем несколько парадигмальных сдвигов. Мы видим появление совершенно новых процессов с совершенно новыми людьми, занимающими новые роли в жизненном цикле разработки программного обеспечения. Итак, я возвращаюсь к вопросу, который мы представили в начале. Это много изменений, с которыми нужно справляться. Ну, надеюсь, сегодня у меня есть для вас две хорошие новости. Первая — как бы вы себя ни чувствовали, поверьте мне, вы не одиноки. Есть много исследований на эту тему, как внутри, так и за пределами Google, и возникает много действительно сложных эмоций. Ничего из этого не удивительно, учитывая масштаб и скорость изменений. Восторг реален. Возможности реальны. Но это много. Вторая хорошая новость заключается в том, что этот разговор действительно о том, как вы можете подняться над всем этим и продолжать процветать в эту эпоху, ориентированную на ИИ. Волшебных палочек нет, но есть способы процветать. Мы видим убедительные доказательства того, что, несмотря на новую форму роли инженера-программиста, когда к изменениям подходят намеренно, это действительно может и должно быть самым захватывающим временем для работы в этой области.
НИКОЛЬ ФОРСГРЕН: Спасибо, Эндрю. Хорошо, давайте поговорим немного о закономерностях, которые мы наблюдаем у наших самых высокопроизводительных инженеров, которые действительно внедряют подход, ориентированный на ИИ. Здесь мы представим некоторые интересные поведения, которые мы наблюдаем. А затем мы соберем все вместе, чтобы поговорить об этой действительно расширенной роли разработки программного обеспечения. Как упомянул Эндрю, наша работа заключается в том, чтобы действительно изучать и измерять инженерную систему и все ее составляющие. Поэтому мы измеряем сквозное время, сколько времени требуется, чтобы пройти от первоначального зародыша идеи до того, как эта идея дойдет до реальных пользователей. Здесь мы думаем не только о разработке программного обеспечения и написании кода, но и фактически о всем процессе разработки продукта. В этой системе наши самые продуктивные инженеры, ориентированные на ИИ, делают несколько вещей по-другому. Мы рассмотрим пять закономерностей, которые мы наблюдаем. Первая заключается в том, что эти инженеры работают на более высоких уровнях. Они сочетают свои инженерные знания, но также применяют свое понимание бизнес-контекста и потребностей пользователей. Они глубоко задумываются о том, почему они это строят, а не только о том, что они строят или как. Теперь, если мы подумаем об этом, это всегда было ожидаемо от старших инженеров. Но теперь, когда ИИ ускоряет выполнение, делать это хорошо никогда не было так важно. Во-вторых, они смещаются влево по намерению. Я знаю, что некоторые из нас слышали это сегодня на конференции. Традиционно смещение влево означало перемещение тестирования или безопасности раньше в жизненный цикл разработки программного обеспечения. Но сегодня все больше и больше работы выполняется автономно агентами. Поэтому теперь нам нужно смещаться влево по намерению. Нам нужно тратить больше времени и энергии на то, чтобы действительно планировать, объяснять эти четкие инструкции, говорить о компромиссах, предоставлять правильный контекст. Это означает, что фундаментальный источник истины перемещается от самого кода. И он действительно смещается в сторону структурированного намерения, которое происходит заранее. Наши инженеры пишут файлы спецификаций, которые, если подумать, являются действительно продуктовым мышлением, сделанным явным. Это помогает лучше направлять наш ИИ, а также документирует решения гораздо более явно, чем некоторые из нас делали в прошлом. И это критически важно, потому что, поскольку агенты берут на себя все больше и больше выполнения, им нужно знать эти компромиссы и эти решения по мере их создания. Я знаю, что создавать без фиксации намерения действительно заманчиво — это весело делать в выходные, возможно. Но мы рискуем получить прототипы, для которых никто не понимает обоснования. Поэтому, когда мы активно организуем эти постоянно развивающиеся знания, это одна сильная стратегия для предотвращения серьезной когнитивной перегрузки. Продолжая предыдущий пункт, который я только что сделал, наши лучшие инженеры не просто пишут код "наобум". Они не просто запрашивают код. Они проектируют среды. Они устанавливают ограничения. Они создают системы, чтобы агенты и люди могли работать вместе для достижения цели и более широкой цели. Думайте об этом как о создании системы рассуждений, чтобы мы могли работать в масштабе, превышающем возможности одного человека. Поэтому это также включает в себя настройку агентов, команд агентов, предоставление им правильного контекста, предоставление им правильных навыков для действий. Наши лучшие инженеры — я знаю, кто-то еще упоминал это в другой сессии. Они хотят не просто быстрый код. Они хотят проверенный, высококачественный код. Поэтому, когда мы делегируем этим командам агентов и делегируем это выполнение, как мы поддерживаем высокую планку? Как агенты узнают, когда действовать, и даже где спорить друг с другом, чтобы найти лучшие решения? Все это исходит из второго шаблона и файлов спецификаций и намерений, которые мы только что обсуждали. И даже несмотря на то, что мы смещаемся влево по намерению и фиксируем это и специфицируем это заранее, циклы обратной связи действительно важны для этого процесса. Далее, ИИ меняет не только то, как люди строят, но и кто может это делать. Он действительно разделяет роль человека от типов вещей, которые он может делать, и задач, которые он выполняет. Мы также наблюдаем рост микрокоманд, небольших кросс-функциональных гибких групп. У них меньше накладных расходов на связь и более тесные циклы сотрудничества. Эти команды могут работать в действительно большом масштабе и с хорошей скоростью благодаря агентам, которых они используют и развертывают. Но опять же, это возможно только в том случае, если мы смещаемся влево по намерению, потому что это помогает нам освоить делегирование агентам. Мы должны четко сформулировать контекст, ограничения, цели, компромиссы, критерии успеха, чтобы агенты могли справиться с "как" и не повторять ошибки или продолжать итерации и создавать то, что они уже узнали. Поэтому нам также нужно спроектировать систему так, чтобы наши агенты могли получить доступ к правильным инструментам, навигировать по данным и затем итерировать с вами в дальнейшем. Пятая и последняя закономерность заключается в наличии научного мышления и в том, как мы все должны постоянно исследовать. Если мы собираемся работать на переднем крае, мы должны быть открыты к неудачам. Все движется так быстро, что редко бывает правильно — идея редко заключается в том, чтобы сделать все правильно с первого раза. Это научиться тому, что мы можем, когда движемся, а затем итерировать и вносить вклад в обучающуюся организацию. Теперь каждую неделю наши инженеры экспериментируют с новыми подходами и инвестируют в кодификацию этого обучения обратно в систему. Опять же, намерение и циклы обратной связи здесь ключевые. Это не научное мышление, если мы просто случайно исследуем и никогда не фиксируем и не применяем эти знания. Итак, собрав все это вместе, мы говорим о смещении влево, смещении вверх и проектировании систем. Теперь проектирование систем включает в себя среду, действующих лиц в этой среде, людей, агентов и инструменты, и, конечно же, культуру, которая связывает все это воедино. Это позволяет нам сосредоточить наши усилия на самых важных проблемах, чтобы действительно учиться и адаптироваться как можно быстрее, а затем эффективно выполнять, возвращая идеи в систему. Хорошо, мы только что рассмотрели пять закономерностей, которые мы наблюдаем во время этого сдвига. И если мы вернемся к цели на сегодня, мы хотим собрать это в способ мышления о ключевых навыках, которые нам нужны, чтобы действительно процветать в эту эпоху, ориентированную на ИИ. Мы будем повторяться несколько раз. Но мы действительно хотим помочь связать точки и подчеркнуть некоторые из вещей, которые мы видим в этой эволюции. Как мы уже упоминали, наши лучшие исполнители все чаще становятся Т-образными, и идея Т-образного разработчика не нова. Мы слышали об этом раньше. Да, мы довольно хорошо с этим знакомы. Однако мы наблюдаем несколько новых тенденций. Теперь для тех, кто не слышал о Т-образном инженере, основная предпосылка заключается в том, что эта верхняя полоса, горизонтальная полоса Т, представляет собой широкую основу знаний в более широкой экосистеме разработки программного обеспечения. Это не означает, что у нас есть опыт во всех областях, но у нас есть хорошее понимание того, как работают ключевые части системы. А затем вертикальный стебель Т представляет собой глубокие, специализированные знания и практический опыт, которыми обладает инженер-программист. Это может быть в конкретной области, такой как финтех. Это может быть определенный стек технологий или фреймворк. Но это наша глубокая экспертиза. Однако мы наблюдаем интересную эволюцию этой Т-образной формы. Во-первых, существует новый уровень горизонтальной экспертизы, который нам нужен. И это действительно эффективно работать с ИИ и взаимодействовать с ним. Не подлежит обсуждению, что инженеры, ориентированные на ИИ, могут действительно понимать ограничения ИИ в контексте конкретной задачи. Мы должны уметь оценивать результаты и качество и в конечном итоге эффективно управлять ИИ. Мы также наблюдаем некоторые дополнения на крыльях Т. Мы видим, что требуется больше широты. Поскольку ИИ имеет более низкий порог входа и действительно увеличивает пропускную способность написания кода, как никогда важно понимать этот контекст. Поэтому на одной руке у нас есть смежная инженерия. Поскольку ИИ создает все больше и больше функционального кода, ключевые соображения и компромиссы, которые мы принимаем, должны быть на переднем плане того, о чем мы думаем здесь. Вторая область здесь — смежная неинженерная. И, в частности, это касается бизнес-контекста и контекста пользователя. Поскольку теперь ИИ может обрабатывать "как" написания кода, нам нужно убедиться, что мы думаем и понимаем бизнес-контекст и контекстные потребности, которые мы решаем. Я думаю, интересно то, что это уже ожидается от наших старших разработчиков. Мы немного говорили об этом. Но теперь, когда наши инженеры работают на все более высоких уровнях, мы можем делать больше с агентами. Поэтому разница здесь действительно в том, что, А, существует фундаментальное предположение об эффективном использовании ИИ. И Б, по многим причинам, которые мы обсуждали, ИИ делает потребности в глубине и широте немного более острыми. Мы замечаем их немного больше. Нам нужны смежные знания. Нам нужна глубина технических знаний. В противном случае ИИ может просто заставить нас делать неправильные вещи быстрее.
ЭНДРЮ МАКВИН: Отлично. Спасибо, Николь. Вы с нами? Пока все хорошо? Хорошо, мы немного подробнее разберем модель. Мы пройдемся по каждой из областей Т-образных навыков. И для каждой мы дадим вам несколько историй, несколько анекдотов из Google. Мы действительно хотим подчеркнуть несколько вещей. Прежде всего, как все на самом деле происходит сегодня, что мы узнаем, и действительно прояснить важность всей Т-образной формы. Затем мы соберем все вместе, поделившись некоторыми практическими советами, которые мы упоминали, которые действительно помогут вам приобрести или воплотить в жизнь поведения и рекомендуемые практики. Хорошо, давайте начнем с основных навыков разработки программного обеспечения. И чтобы понять, как развиваются эти навыки, я хочу поделиться историей из нашей поисковой организации. Прямо сейчас у нас есть менеджеры по продуктам, которые выпускают функции вплоть до живых экспериментов. Теперь они не пишут традиционный код. Они используют некоторые из наших внутренних платформ, которые помогают переводить их намерения — то есть потребности пользователя или бизнеса — в рабочие функции на нашем реальном производственном технологическом стеке. Теперь, со стороны, вы могли бы подумать: "Эй, если менеджеры по продуктам пишут код для производства, какую роль играют эти традиционные основные навыки разработки программного обеспечения?" Реальность такова, что ничего из этого невозможно без невероятно продвинутой платформы. Глубокая экспертиза в системных архитектурах, различные нити различных языковых фреймворков — все это встроено в платформу, как и требования к масштабируемости, требования к надежности и т. д. Теперь это, для меня, действительно хороший пример того, как инженер работает все выше и выше по стеку абстракций. Инженер не создает вручную эти отдельные функции. Он точно инженерит экосистему, которая позволяет этим функциям безопасно существовать. Теперь это требует большей инженерной глубины, а не меньшей. Итак, учитывая эту общую траекторию, давайте поговорим о трех конкретных сдвигах, которые мы наблюдаем в отношении этих навыков. Во-первых, поскольку генерация кода происходит все быстрее и быстрее, эффективная проверка может стать узким местом. ИИ может выступать в качестве мощного множителя силы, но вы должны обладать глубокой экспертизой, необходимой для оценки, интеграции и поддержания его результатов. Однако, учитывая масштаб, в котором может работать ИИ, это не обязательно ручная проверка каждой строки за строкой. Это когнитивно невозможно. Речь идет о настройке эффективных циклов обратной связи, обеспечении надежного выявления проблем в условиях низкой ставки и использовании этих данных для обеспечения того, чтобы вы, как инженер, ваше внимание было сосредоточено на самых ценных, наиболее необходимых вещах. И поэтому наши внутренние платформы действительно разработаны так, чтобы позволить нам быстро тестировать функции, безопасно собирать данные о производительности и использовать эти циклы обратной связи для действительно нацеливания инженеров там, где их экспертиза наиболее необходима. Именно там они привлекаются к процессу. Теперь это приводит нас ко второму пункту. И Николь уже упоминала это. Наши инженеры не пишут код "наобум". Они контролируют. Они действительно точно инженерируют. Если вам не хватает глубокого инженерного понимания, если вы не понимаете системы, против которых строите, ИИ может создать технический и когнитивный долг с невероятной скоростью. Именно поэтому наши команды работают над этими внутренними платформами. Они делают разработку от намерения до функционирующего, высококачественного, надежного и безопасного кода. Наши инженеры думают о настройке границ и ограничений системы. Например, они специфицируют тонкие соглашения о руководствах по стилю, которым должны следовать агенты, с правильными проверками и балансами для обнаружения, когда агенты начинают отклоняться. Теперь мы знаем, что некоторые из этих моделей имеют тенденцию звучать невероятно уверенно. Мы знаем, что, когда они работают в масштабе, может быть слишком легко просто принимать изменения оптом. Мне нравится поговорка: "делегируйте задачи, а не суждения". Крайне важно, чтобы именно ваши основные инженерные навыки направляли модель в правильном направлении. Опять же, речь идет о создании среды — системы, где проблемы могут быть выявлены и устранены с минимальным риском. Чего мы не хотим, так это интеллектуальной пассивности. Вот почему циклы обратной связи здесь так важны. Речь идет о получении обратной связи от конечных пользователей, обратной связи о производительности и использовании этих данных для измерения соответствия намерению. Наблюдаемость имеет решающее значение, чтобы мы могли определить, где могут отсутствовать ограничения, или агенты делают неправильные предположения, потому что у них нет правильного контекста. Хорошо, легко стоять здесь и говорить: "поддерживайте свою глубокую экспертизу". Но как вы на самом деле это делаете в этой быстро меняющейся, постоянно меняющейся среде? Вот три практических совета, которые принимают наши лучшие команды. Во-первых, мы действительно рекомендуем перереализацию в качестве обучающего инструмента. Поскольку ИИ может быстро генерировать решения, не просто принимайте первый черновик. Попросите ИИ разобрать его и перереализовать. Попросите его документировать свою логику, почему он подошел к этому по-другому и что он узнал в процессе. Это невероятно полезно для проверки первоначальных предположений, определения того, где может отсутствовать контекст, и обдумывания последствий различных подходов. Во-вторых, мы призываем наши команды проводить обзоры чужого кода, системных архитектур и трассировок решений агентов. Мы просим инженеров объяснить код или системы, которые они не писали сами, чтобы помочь построить общую ментальную модель и теорию системы, которую мы знаем как очень важную. Теперь аналоговые подходы работают здесь очень хорошо. И поэтому мы фактически видели, как команды все больше и больше используют доски для рисования, чтобы помочь сформулировать эту логику в системе. Для нас код все чаще не является первоклассным результатом. Это соответствие этому намерению, ваша способность достигать бизнес-целей и целей конечных пользователей, а также общее понимание системы, которое должно быть намеренным результатом. В-третьих, я уверен, что вы все видели растущую практику использования файлов навыков, файлов правил и т. д. для явной кодификации командных практик, ожиданий и институциональных знаний в ваших агентах последовательным и масштабируемым образом. И это то, что мы видели, как становится все более важным. Мы говорим о способах контекстного инжиниринга в масштабе с большей надежностью. Наши лучшие команды не просто используют агентов "из коробки". Они создают, курируют и поддерживают структурированные профили ролей агентов, предоставляя им очень специфические поведенческие атрибуты и предоставляя им рецепты для эффективной работы в нашей системе. Опять же, будучи вынужденным последовательно размышлять о том, что такое хорошо — какое поведение является хорошим для агента? Это действительно хороший способ оставаться острым в своих основных инженерных навыках. Это гарантирует, что у вас есть актуальное понимание системы, которую вы пытаетесь построить, и что вы создаете циклы обратной связи, чтобы знать, что работает, что нет, и как сделать ваших агентов более эффективными. Теперь, важно отметить, что эти навыки, правила, системные спецификации должны рассматриваться так же, как и другой код, с соответствующим контролем версий и практиками наблюдаемости.
НИКОЛЬ ФОРСГРЕН: Спасибо. Хорошо, далее мы поговорим об использовании GenAI. Мы хотим немного больше рассказать о том, как наши инженеры работают с ИИ и как они строят правильные системы, чтобы их ИИ мог быть эффективным. Здесь мы действительно выходим за рамки эпохи улучшения ИИ к инженерии, ориентированной на ИИ. Это большой сдвиг в ментальной модели от дирижера одного агента к действительно оркестратору всей системы. Поэтому здесь мы наблюдаем появление трех принципов. Наши оркестраторы управляют командами асинхронных ИИ-агентов. У каждого есть свое окно контекста. У каждого есть своя конкретная область ответственности. А затем человек-инженер-программист сверху — это тот, кто устанавливает среду и направляет поток. Наши инженеры напрямую и косвенно учат агентов действовать, предоставляя им навыки, которые упомянул Эндрю, что, по сути, означает предоставление им точных рецептов, инструментов и знаний предметной области, которые им необходимы для выполнения их задач. Этот сдвиг к оркестрации — новый навык. Нам нужно знать, когда делегировать, а когда нет. Наши лучшие команды действительно помогают избежать этой ловушки автоматизации, устанавливая четкие человеческие базовые уровни для своей работы и измеряя накладные расходы на проверку. Чтобы помочь выиграть, мы проводим эксперименты и находим задачи, где вероятность успеха самая высокая. Это позволяет нам удерживать внимание человека на задачах, которые, как мы знаем, агенты пока не могут выполнить, или где вкус и суждение действительно важны. Поскольку стоимость оценки является новым критическим узким местом, наши инженеры должны глубоко заниматься своими навыками системного мышления. Там, где мы не видим достаточного успеха, мы начинаем анализировать трассировки агентов и строим общее понимание того, как наша система может улучшиться, будь то что-то вроде удобства использования инструментов, которые агенты не используют, или навыки, которыми сами агенты были оснащены. Один из примеров — агенты для состязательного обзора. Здесь мы видим, как инженеры развертывают их, чтобы проверить решения и проверить их на крайних случаях. Трассировки документируются, а затем обновляются правила намерения и агента, потому что мы учимся на том, что мы сделали. Ничего из этого невозможно без глубокого понимания базовых программных систем, при этом обладая навыками ИИ, которые понимают сильные и слабые стороны модели и агентов, с которыми мы работаем. Внутри Google мы наблюдаем существенный рост объема кода, который нуждается в проверке. Поэтому мы создаем агентов для проверки кода. Их цель — оценивать функциональность, надежность, производительность, удобство использования, безопасность и даже поддерживаемость. Наша цель — не заменить человеческих рецензентов кода ИИ, а, скорее, создать более тесные циклы обратной связи. Мы хотим выявлять как можно больше проблем как можно раньше. Мы хотим возвращать эти проблемы в систему, например, документируя, где были сделаны неправильные предположения, при этом сохраняя человеческое познание для этих высокоценных задач. Вот почему мы начали создавать агентов-пастухов. Эти агенты направляют изменения через наши конвейеры CI/CD. Они многократно запускают агентов проверки. А затем они также используют агентов оценки рисков, которые сканируют текущие изменения и помечают высокорисковые изменения для человеческой проверки. Конечно, я возвращаюсь к необходимости для инженеров-программистов делегировать задачи, а не суждения. Я думаю, мы разделяем это как любимую цитату. Наши инженеры-программисты играют здесь критически важную роль. Во-первых, они помогают определять ожидания по таким темам, как удобство использования и поддерживаемость. Что мы вообще подразумеваем под этими вещами? Как это отличается от команды к команде? Как это контекстно-специфично? Во-вторых, между этими конструкциями, как правило, существуют компромиссы. В какой ситуации мы отдаем приоритет производительности, или мы отдаем приоритет удобству использования? Применение этого требует человеческого суждения и вкуса. ИИ может помочь нам информировать. Он может помочь выявить риски в компромиссе, который мы рассматриваем. Но в конечном итоге суждение исходит от человека. Так как же нам повысить свою квалификацию, чтобы более эффективно работать с агентами? И, возможно, что более важно, как вы можете помочь своим организациям и своим системам быть готовыми к этим новым способам работы? Во-первых, мы настоятельно рекомендуем повышать квалификацию в области оценок. Поскольку проверка является таким большим узким местом, вы должны быть уверены в том, как вы оцениваете результаты ИИ. Вся Т-образная форма инженера важна здесь, потому что она действительно требует сочетания навыков ИИ, разработки программного обеспечения, пользовательских и бизнес-навыков, чтобы убедиться, что мы разрабатываем реалистичные, обоснованные и релевантные оценки. Наши оценки также являются критически важным артефактом для обеспечения общих командных знаний и являются большой частью того, как фиксируется намерение. Они помогают нам определить, что такое хорошо. Во-вторых, наши лучшие инженеры не просто занимаются личной саморефлексией, но и заставляют своих агентов постоянно рефлексировать и документировать. Мы думаем об этом немного как о дневнике агента. Удивительно, в конце дня видеть, как мой агент воспринимал свой день — где он застрял в системе, где он запутался в инструкциях, где он чувствовал себя продуктивным. Эти журналы рефлексии дают мне и всем нам представление о том, как мы можем улучшиться, не только о том, как мы работаем с ИИ, например, давая ему четкие инструкции о том, какой язык или фреймворк использовать. Но также мы можем улучшить всю экосистему вокруг агентов. Например, если у вашего агента постоянно возникают трудности с доступом к внутреннему инструменту, у вас может быть проблема с удобством использования инструмента, которую стоит решить. В-третьих — и я знаю, что мы уже несколько раз это говорили — мы хотим создавать команды агентов. Сейчас самое время действительно использовать возможность масштабироваться за пределы одного агента до сбалансированной команды со строгими правилами и протоколами. Мы делаем это прямо сейчас внутри Google, например, с некоторыми миграциями, которые мы проводили вокруг TensorFlow. Это чрезвычайно сложная, деликатная работа. Вместо использования одного чат-бота наша команда развернула строгую трех-агентную архитектуру — один, агент-планировщик, который генерирует проверяемые шаги миграции; два, агент-оркестратор, который группирует эти шаги; и затем, наконец, агент-кодер, который их выполняет. Наши лучшие команды масштабируются за пределы отдельных агентов, кодифицируя свои лучшие практики, например, вокруг стилистических правил и предпочтений в кодировании. В примере миграции TensorFlow различные руководства подаются агентам, чтобы обеспечить миграцию в одной области продукта, например, YouTube использует практики, специфичные для YouTube. Еще одна вещь, которую следует учитывать здесь, — это разрастание агентов. Например, некоторые утверждают, что следует придерживаться трех-пяти агентов, чтобы можно было осмысленно отслеживать работу. Я думаю, что мы в целом согласны с этим как с оптимальным вариантом. Но мы видим все больше и больше инструментов, поддерживающих управление многоагентными системами с растущим числом агентов. И мы думаем, что некоторые из техник, которые мы здесь обсуждали, могут помочь вам с этим дополнительным масштабом. Это приводит нас к нашему последнему пункту. Мы не можем полагаться на расплывчатые запросы и ожидать высококачественных результатов. Нам нужна точная инженерия. Здесь мы видим разработку, управляемую спецификациями, где продуктовое мышление и принятие архитектурных решений проявляются, и они документируются заранее, и они становятся все более важными. Цели, ограничения, обоснование — это критический контекст не только для агентов, выполняющих задачи, но и для более широкой команды. Спецификации, когда мы объединяем их с ролями и навыками агентов, являются источником истины о том, что и почему системы, которую вы строите. Здесь они документированы для управления агентами в масштабе, поддерживая понимание системы и поддерживаемость.
ЭНДРЮ МАКВИН: Хорошо. Итак, мы уже несколько раз неявно говорили о навыках, смежных с агентами, потому что, по сути, все эти возможности постоянно взаимодействуют друг с другом. Возьмем агента проверки в качестве явного примера объединения всех четырех. Но давайте теперь перейдем к смежному инженерному крылу. И именно здесь так важны такие области, как кибербезопасность, конфиденциальность и отраслевые нормативные акты, а также инфраструктура развертывания. Если ваша организация имеет высококачественные внутренние платформы, сильные API, четкие, хорошо документированные рабочие процессы, ИИ действительно действует как мощный сотрудник. Но если вы страдаете от фрагментированных инструментов, разрозненных данных и, возможно, хрупкой инфраструктуры, ИИ, возможно, не спасет вас. Он просто поможет вам быстрее генерировать технический долг. Есть замечательные исследования, проведенные нашей командой DORA, которые действительно говорят об этом. ИИ — это усилитель, и он — зеркало. Он усиливает существующие нити, одновременно отражая эти слабости. Смежное инженерное крыло — именно здесь ИИ, скорее всего, введет тихий, катастрофический долг, если его не контролировать. И поэтому давайте поговорим о трех принципах, которые помогут это смягчить. Прежде всего, наша история с менеджерами по продуктам поиска также очень актуальна здесь. Встраивание этих лучших практик непосредственно в высококачественную внутреннюю платформу — вот что позволило нам выпустить эти функции без ручной обработки каждой строки кода. Это требует множества смежных инженерных навыков, например, понимания сред развертывания, потребностей в безопасности, потребностей в надежности, а также тех глубоких основных инженерных навыков, которые мы уже обсуждали. Одна из статистик, которой мы больше всего гордимся, заключается в том, что, хотя мы наблюдаем увеличение объема кода, написанного ИИ, мы не увидели никакого измеримого увеличения сбоев или снижения надежности системы. Мы хотим 10-кратную скорость без 10-кратного риска. Один из способов достижения этого — создание многоуровневых сред риска. Мы признаем, что различные приложения имеют разные потребности в среде. Например, внутреннему приложению Google не нужно масштабироваться до миллиарда пользователей. Поэтому наша цель — перейти от прототипа к производству более инкрементальным и итеративным образом. Мы проходим через эти различные профили риска и в процессе действительно ограничиваем радиус поражения, при этом достигая все более быстрой обратной связи. Это также относится к другим смежным инженерным навыкам, таким как эффективное экспериментирование. Когда функции движутся через вашу систему все быстрее и быстрее, как вы на самом деле доставляете их пользователям таким образом, чтобы изолировать функции должным образом и позволить вам измеримо понять, как они работают? Обдумывание этих сред, критических архитектурных и развертывающих соображений становится все более важным для наших инженеров. Так как же на самом деле развивать эти мышцы? Вот четыре совета, которые принимают наши лучшие команды. Во-первых, мы настоятельно рекомендуем культуру постмортемов без обвинений. Чтобы построить действительно устойчивые системы, вам нужно сделать привычкой документировать, читать и, что важно, обсуждать сбои и инциденты. Это действительно развивает вашу интуицию для крайних случаев, ограничений масштаба и угроз надежности. Это также бесценный контекст, когда вы думаете о том, как направлять и управлять вашими агентами. Например, триангуляция этих документов постмортемов с саморефлексией агента, которую обсуждала Николь, и трассировками наблюдаемости позволяет вам увидеть, где могут проявляться крайние случаи или ваши системные инструкции могут быть неясными. Во-вторых, не просто используйте ИИ для создания. Используйте его для стресс-тестирования. Возвращаясь к нашим пунктам о сбалансированных правилах агентов, явная настройка агентов красной команды позволяет вам видеть вашу систему глазами злоумышленников. Заставляя ваших агентов объяснять, как они бы использовали систему, вы заставляете себя заниматься этими механизмами эксплуатации. Вместо того, чтобы просто пассивно принимать решения, вы начинаете обучать себя и своих агентов выявлять уязвимости, которые могут упустить ваши генеративные агенты. Теперь мы уже говорили об этом — это действительно интересный рост аналоговых подходов для картирования систем и, конечно же, карт данных. Доски для рисования действительно на вес золота, с реальным фокусом на обдумывании первоначальных архитектур. Вручную отслеживая конвейер, вы можете построить ментальные модели таких вещей, как соответствие корпоративным стандартам, прежде чем будет написана хоть одна строка кода. Кодификация этого намерения на доске для рисования — отличный способ проверить первоначальные предположения и убедиться, что ваши агенты имеют правильный контекст перед выполнением. Наконец, наблюдаемость действительно является критически важной частью головоломки. Если функции, как мы надеемся, движутся через вашу систему в 10 раз быстрее, вам нужно иметь возможность отслеживать их, чтобы понять, как все на самом деле ведет себя в реальном мире. Мы обнаружили, например, что некоторые из наших инженеров с более ранней карьерой блокировались непрозрачными метриками производительности, действительно тонкими регрессиями работоспособности системы. Они не знали, как диагностировать сложные распределенные системы, которые они развертывали. И поэтому мы инвестировали больше в инструменты наблюдаемости и унифицированные агенты данных. И агенты данных имели доступ к коду, журналам ошибок, данным о производительности, трассировкам стека. И мы обнаружили, что мы смогли дать этим инженерам возможность лучше интерпретировать и понимать сложные системы. Это, для меня, еще один хороший пример не только использования ИИ для создания, но и использования ИИ для понимания. Хорошо, это подводит нас к последней возможности в нашем Т, и это смежные неинженерные навыки. Все это связано с более глубоким согласованием с потребностями пользователей и бизнеса. Теперь, когда агенты могут выполнять гораздо больше рутинных задач, наши инженеры имеют мандат сосредоточиться больше на "что" и "почему". Но мы признаем, что для многих из нас это неудобный сдвиг. Наши исследования DORA показали, что многие разработчики сталкиваются с реальной угрозой идентичности. Поскольку мы исторически получали так много ценности от самого ремесла написания кода, нам нужно действительно сознательно изменить то, как мы думаем о своей ценности и измеряем ее. Мы должны опираться на более широкую ценность нашей работы. Это исходит из решения реальных человеческих и реальных бизнес-проблем. Наши инженеры все чаще выступают в роли переводчиков ценности. Они берут потребности пользователей, потребности бизнеса и превращают их в точные требования. Рассмотрите запрос на улучшение производительности. ИИ может найти и переработать неэффективный цикл. Но переводчик ценности сначала спрашивает: улучшенная производительность для кого и при каких условиях? Они могут изучить метрики и отзывы пользователей и найти этот конкретный сегмент пользователей, которому требуется изменение. Затем они направляют ИИ для оптимизации критических путей кода, которые фактически влияют на этот конкретный сценарий. Вот еще один пример того, где человеческий вкус и суждение действительно важны, чтобы направить ресурсы ИИ в правильном направлении. Мне очень нравится эта цитата Питера Сенге: "Самые эффективные люди — это те, кто может удерживать свое видение, оставаясь приверженными ясному видению текущей реальности". Это идеально отражает то, о чем мы говорим в отношении Т-образного инженера. Они обладают способностью формировать широкое видение благодаря этим смежным навыкам, но также глубоко понимать техническую реальность благодаря этой инженерной глубине. Они используют системы и практики, о которых мы говорили сегодня, чтобы фиксировать намерение, поддерживать понимание и гарантировать, что мы никогда не потеряем этот контекст текущей реальности по мере создания. Теперь, конечно, мы здесь сегодня, чтобы говорить о Т-образном инженере. Но разработка программного обеспечения — не единственная дисциплина, которая становится более Т-образной. Мы наблюдаем точно такую же эволюцию у наших менеджеров по продуктам, наших специалистов по данным и наших UX-специалистов. Ранее мы делились историей о наших менеджерах по продуктам поиска. Теперь, хотя именно инженеры-программисты создали безопасную, надежную платформу, конечно, менеджеры по продуктам также расширяют свои смежные навыки. Они не ждут, пока дизайнер передаст им статичный [? макет. ?]. Они переходят от идеи к работающей системе. Это позволяет нам создавать более гибкие и более динамичные команды. Теперь каждая дисциплина по-прежнему имеет свои сильные стороны и роль, но границы начинают размываться. Например, в одном из внутренних инструментов, над которым я работаю, менеджер по продуктам, UX-специалист и инженер — все они выпускают код. Теперь над большими проблемами они по-прежнему работают вместе, но что-то вроде мелкой проблемы с пользовательским интерфейсом, которая, возможно, больше бросается в глаза дизайнеру. Этот дизайнер просто исправляет и выпускает код самостоятельно. И это, для меня, истинная сила этой Т-образной эпохи. Хорошо, мы могли бы потратить целый час на эту тему, но вот два быстрых совета, которые принимают команды. Во-первых, избегайте соблазна заставлять ИИ синтезировать все ваши отзывы пользователей. Невероятно заманчиво просто загрузить сотни журналов отзывов пользователей в LLM и попросить резюме. Я думаю, если сделать это правильно, для этого может быть место. Но так же, как мы наблюдаем увеличение числа аналоговых сессий на досках для рисования, мы также наблюдаем увеличение числа традиционных сессий обратной связи с пользователями, и наши инженеры действительно наслаждаются глубоким участием. Слыша истинную радость или истинное разочарование в голосе пользователя, это создает глубокое сочувствие и действительно делает "почему" вещей более реальным. Во-вторых — и мы упоминали это несколько раз — это разработка, управляемая спецификациями. Действительно относитесь к своей спецификации как к конечному продукту. Наши лучшие команды яростно защищают эти спецификации. Большая часть их когнитивной энергии уходит на обсуждение целей, бизнес-логики и ограничений крайних случаев. Принудительная четкая артикуляция заранее и открыто действительно помогла командам согласовать "почему" и помогла агентам получить доступ к более тонким институциональным знаниям. Помните, когда каждый может прототипировать со скоростью света, несколько минут, потраченных на фиксацию намерения, действительно предотвращают превращение исследования в хаос. И поскольку мы относимся к этим спецификациям как к коду, такие инструменты, как агент проверки, который мы упоминали, могут действительно использоваться для стресс-тестирования требований или поиска логических столкновений до начала выполнения.
НИКОЛЬ ФОРСГРЕН: Хорошо, теперь мы соберем все вместе. Когда мы объединяем глубокую экспертизу, необходимую для выявления ошибок ИИ, навыки, необходимые для оркестрации флота, у нас есть смежная инженерия, чтобы мы могли понимать систему, и наша неинженерная часть, чтобы действительно дать нам более широкий контекст. Вот что, по нашему мнению, необходимо для процветания в эпоху, ориентированную на ИИ. Здесь мы говорим о владении навыками для фиксации и перевода знаний таким образом, чтобы сохранить соотношение сигнал/шум как для людей, так и для агентов, чтобы у нас могла быть эта добродетельная система улучшения. Надеемся, что структура, возможности и закономерности, которыми мы поделились, дадут вам полезный способ осмыслить свою роль или вдохновят на то, что вы можете попробовать. Мы также хотим уделить несколько минут, чтобы поговорить с менеджерами и лидерами инженеров в зале. Инженеры не работают вне организации, и мы не работаем в одиночку. Поэтому мы сосредоточились на этом до сих пор. Но суровая правда в том, что вы не можете предписать Т-образного разработчика в сломанной системе. Как показывают наши исследования DORA, и как упомянул Эндрю, ИИ может быть суровым зеркалом, отражающим все наши слабости, а также наши сильные стороны. Если у нас есть хорошо согласованные команды с сильными практиками, ИИ может ускорить доставку ценности. Но если у вас есть фрагментированные инструменты, разрозненные данные или, особенно, культура обвинений, ИИ вас не спасет. Он просто выявит все эти узкие места. Мне нравится эта цитата Деминга: "Плохая система всегда победит хорошего человека". Прямо сейчас мы просим инженеров сосредоточить свое внимание на некоторых из самых сложных архитектурных решениях. Мы просим их проверять машинные результаты, а затем постоянно переключать контекст между несколькими агентами. Это может быть очень когнитивно утомительно. 10-кратный выход не может сопровождаться 10-кратной когнитивной нагрузкой, иначе люди выгорят. Итак, как лидер, как мы можем создать среду, в которой наши инженеры могут безопасно развиваться, чтобы наши инженеры могли принять расширенную Т-образную роль? Мы рекомендуем три немедленных сдвига. Во-первых, переопределите, как вы измеряете производительность. Мы должны перестать измерять наши команды по пулл-реквестам, пропускной способности или принятым строкам кода. Мы должны вознаграждать результаты и удовлетворенные бизнес-потребности. Нам нужно сосредоточиться на правильных результатах с сбалансированным пониманием ценности. Например, если мы измеряем только скорость и никогда качество, наши разработчики не будут тратить время на тщательную проверку результатов ИИ. И тогда нестабильность системы резко возрастет. Мы рекомендуем сбалансированный портфель метрик. И есть много хороших ресурсов, с которых можно начать. Во-вторых, активно защищайте эту продуктивную борьбу. Мы должны выделять время в рабочее время, чтобы наши разработчики могли изучать эти инструменты и понимать системы, которые они строят. Поощряйте их вручную проводить архитектурные обзоры или экспериментировать с новым инструментом или подходом, чтобы они могли узнать, как инструменты по-разному решают разные проблемы. Если вы не дадите им пространство для построения этих важных ментальных моделей, ваша команда просто утонет в когнитивном долге. В-третьих, развивайте радикальную психологическую безопасность. Мы находимся в эпохе экспериментов. Ваши команды будут создавать агентные рабочие процессы, которые потерпят неудачу. Если ваша культура наказывает эти неудачи, разработчики будут полагаться на имеющиеся у них навыки и свои старые, безопасные способы работы. Нам нужно праздновать разумные неудачи, создавать постмортемы без обвинений, чтобы вся команда училась на ошибках, происходящих в системе. Теперь все это всегда было правдой, но мы всегда говорили, что ИИ — это действительно зеркало и усилитель. Мы хотим завершить, явно признав и вновь подчеркнув всего несколько вещей. Управление парком агентов при проектировании сложных систем может показаться утомительным, потому что это заставляет нас оставаться исключительно в этом высокоуровневом пространстве принятия решений. Положительная сторона заключается в том, что, хотя характер наших усилий меняется, у нас все еще есть радость творчества. Инвестируя в расширенный набор навыков Т-образного разработчика, вы можете увидеть, как ваши идеи воплощаются в жизнь с беспрецедентной скоростью, и они приближают вас к реальному программному обеспечению, которое вы хотите создать. Вы не оставляете ремесло разработки программного обеспечения. Вы просто поднимаетесь на его самый высокий и самый влиятельный уровень. И самое главное — я знаю, что мы это говорили, но это стоит повторить. Роль инженера-программиста не исчезает. Она просто развивается. И если что-то и происходит, то она становится более важной. Поэтому нам нужно смещаться влево. Нам нужно смещаться вверх. И нам нужно думать о проектировании систем, а не просто о фрагментах кода. Спасибо. [МУЗЫКА ИГРАЕТ]