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-кратной когнитивной нагрузкой, иначе люди выгорят. Итак, как лидер, мы можем создать среду, в которой наши инженеры могут безопасно развиваться, чтобы наши инженеры могли принять расширенную Т-образную роль? Мы рекомендуем три немедленных сдвига. Во-первых, переопределите, как вы измеряете производительность. Мы должны перестать измерять наши команды по количеству пул-реквестов, пропускной способности или принятых строк кода. Мы должны вознаграждать результаты и удовлетворенные бизнес-потребности. Нам нужно сосредоточиться на правильных результатах с сбалансированным пониманием ценности. Например, если мы измеряем только скорость и никогда качество, наши разработчики не будут тратить время на тщательную проверку результатов ИИ. И тогда нестабильность системы резко возрастет. Мы рекомендуем сбалансированный портфель метрик. И есть много хороших ресурсов, чтобы начать. Во-вторых, активно защищайте эту продуктивную борьбу. Мы должны выделять время в рабочее время, чтобы наши разработчики могли изучать эти инструменты и понимать системы, которые они строят. Поощряйте их вручную проводить архитектурные обзоры или экспериментировать с новым инструментом или подходом, чтобы они могли узнать, как инструменты по-разному решают разные проблемы. Если вы не дадите им пространство для построения этих важных ментальных моделей, ваша команда просто утонет в когнитивном долге. В-третьих, развивайте радикальную психологическую безопасность. Мы находимся в эпохе экспериментов. Ваши команды будут создавать агентские рабочие процессы, которые потерпят неудачу. Если ваша культура наказывает эти неудачи, разработчики будут полагаться на имеющиеся у них навыки и свои старые, безопасные способы работы. Мы должны праздновать разумные неудачи, создавать постмортемы без обвинений, чтобы вся команда училась на ошибках, происходящих в системе. Теперь все это всегда было правдой, но мы всегда говорили, что ИИ — это зеркало и усилитель. Мы хотим завершить, явно признав и вновь подчеркнув всего несколько вещей. Управление парком агентов при проектировании сложных систем может показаться утомительным, потому что это заставляет нас оставаться исключительно в этом высокоуровневом пространстве принятия решений. Серебряная подкладка заключается в том, что, хотя характер наших усилий меняется, мы по-прежнему испытываем радость от создания. Инвестируя в расширенный набор навыков Т-образного разработчика, вы можете увидеть, как ваши идеи воплощаются в жизнь с беспрецедентной скоростью, и они приближают вас к фактическому программному обеспечению, которое вы хотите создать. Вы не отказываетесь от ремесла разработки программного обеспечения. Вы просто поднимаетесь на его самый высокий и самый влиятельный уровень. И самое главное — я знаю, что мы это говорили, но это стоит повторить. Роль инженера-программиста не исчезает. Она просто эволюционирует. И если что-то и происходит, то она становится более важной. Поэтому нам нужно сместить акцент влево. Нам нужно сместить акцент вверх. И нам нужно думать о проектировании систем, а не просто о фрагментах кода. Так что спасибо. [МУЗЫКА ИГРАЕТ]