Andi Gutmans, один из участников создания PHP 3 и руководитель направления Agentic Data Cloud в Google, не представляет разработку программного обеспечения с использованием агентов как полный разрыв с прошлым. В разговоре с Eira May и Peter O'Connor в рамках программы Leaders of Code, которую ведёт Stack Overflow, он сравнил нынешний переход с влиянием PHP, когда создание веб-сайтов стало возможным для большего числа людей, включая тех, кто не специализировался на компьютерных науках.
Однако новая доступность не означает исчезновения инженерной экспертизы. Согласно подходу Gutmans, отдельный разработчик постепенно превращается в нечто вроде «руководителя команды агентов»: он определяет требуемый результат, распределяет работу, проверяет результаты и принимает решения, которые нельзя без ограничений делегировать.
Ценность переходит от написания кода к инженерному суждению
Gutmans считает, что некоторые основные вопросы не изменились с появлением агентов. Команда по-прежнему должна убедиться, что решение отвечает правильной проблеме, архитектура масштабируема, а система безопасна, надлежащим образом управляется, удобна в использовании и приемлема по стоимости. Новым является то, что агент способен самостоятельно выполнять больший объём работы, поэтому необходимо проектировать способ надзора за ним, а не ограничиваться проверкой сгенерированного кода.
Gutmans привёл пример: он использовал одного агента для создания около тысячи тестов, а затем привлёк другого агента для критики этих тестов. Проверка показала, что результат был недостаточно хорош, и ему пришлось доработать его самостоятельно. В этом случае потребность в человеческом суждении не исчезла; изменилось лишь его место — от детального исполнения к проектированию, координации и оценке.
Это изменение распространяется и на понимание незнакомой кодовой базы. Агенты способны перемещаться по более широкому диапазону проекта и могут обнаруживать категории ошибок, которые человеку-рецензенту трудно заметить при проверке ограниченной части системы. Тем не менее Gutmans сказал, что Google использует одновременно человеческую и агентскую проверку, особенно когда решения или изменения являются чувствительными.
Проверка — это не вопрос абсолютного доверия, а управление рисками
В разговоре предлагается рассматривать надзор в рамках трёх режимов: человек в контуре, агент в контуре и агент над контуром. Это не означает, что существует один подход, подходящий для всех случаев, а предполагает определение соответствующего уровня проверки с учётом вероятности ошибки и её последствий.
В изменениях, связанных с чувствительными компонентами безопасности, такими как токены безопасности, участие эксперта-человека имеет большее значение. Для изменений CSS и HTML или некоторых скриптов Python при привлечении агента к проверке безопасности может быть практично полагаться на иной уровень автоматизации. Основная идея заключается не в том, что агенты не ошибаются, и не в том, что люди одинаково эффективно проверяют всё, а в том, что решение о проверке должно отражать масштаб риска и последствий.
Gutmans использовал опыт Waymo как наглядный пример разрыва между ощущениями и данными. Он сказал, что вероятность попасть в аварию с травмами для человека на 80% ниже с Waymo, чем при поездке с водителем Uber, хотя многие по-прежнему чувствуют себя спокойнее, когда за рулём находится человек. Аналогичным образом команда может отвергать автономность агента из-за впечатления, даже когда показатели указывают, что его использование в конкретной задаче способно снизить риски по сравнению с человеческой альтернативой.
Найм и обучение ориентируются на проверку способности направлять
Gutmans считает, что обучение компьютерным наукам не прекратится, однако студенты смогут реализовывать более сложные и масштабные проекты с помощью агентов. Поэтому знание того, как создавать, запускать и масштабировать системы, по-прежнему будет необходимым, а способность формулировать проблему, оценивать решения и направлять интеллектуальные инструменты также станет важной.
Он сказал, что Google меняет часть процесса инженерных собеседований. Вместо того чтобы сосредотачиваться на просьбе к кандидату вручную написать алгоритм вроде quick sort, ему позволят использовать Gemini и агента для решения задачи, после чего будет оцениваться его образ мышления, последовательность действий при работе над проблемой и способ управления агентом. Это не отменяет технических навыков, но меняет то, что собеседование пытается измерить: с быстроты создания абстрактного решения на качество рассуждений, проектирования и координации.
Главное препятствие может быть связано с данными, а не с моделями
По словам Gutmans, такие модели, как Gemini и Opus, уже способны автоматизировать значительную долю задач предприятий, поэтому главным узким местом больше не является только проблема моделей. Более важная задача — сделать корпоративные данные понятными и пригодными для использования агентами, сохранив семантические связи, разрешения и управление.
Речь идёт о структурированных и операционных данных, а также об изображениях, PDF-файлах, контрактах и других неструктурированных данных, хранящихся в облачном хранилище или в других местах. Google считает, что агенты могут помогать обнаруживать местонахождение данных, понимать связи между ними и создавать семантические представления, для формирования которых раньше требовалось большое число распорядителей данных. Gutmans описывает это направление в рамках концепции «borderless lakehouse», призванной активировать данные независимо от того, находятся ли они в GCP, AWS, Azure или локальных средах.
Он также отметил важность открытых форматов данных, таких как Iceberg, и то, что межоблачные интеграции могут помочь получать доступ к данным без полной зависимости от платы за передачу данных за каждый гигабайт. Кроме того, он говорил о «knowledge catalog» и о переносе создания онтологии от процесса, полностью управляемого людьми, к процессу, которым руководят агенты, при сохранении за человеком роли координации и редактирования вместо выполнения тяжёлой ручной работы.
Что меняется на практике? Для технических команд недостаточно предоставить программного агента и просто оставить его работать. Эффективное использование требует определить задачи, достойные автоматизации, установить уровни проверки, соответствующие их рискам, и убедиться в качестве данных и разрешений, к которым получает доступ агент. Что касается разработчика, его роль не исчезает; напротив, он становится скорее инженером, направляющим набор инструментов, способных выполнять работу, и несущим ответственность за окончательную оценку того, что они производят.