Несколько лет назад самые мощные ИИ-инструменты в рабочем процессе разработчика помогали писать код. Сегодня они способны на гораздо большее. Все чаще ИИ-агенту поручают такую задачу, как:
Агент читает файлы, анализирует зависимости, выполняет команды, изменяет код и взаимодействует с внешними системами. Во многих случаях он может выполнять значительные объемы инженерной работы при минимальном контроле. Этот сдвиг кажется постепенным ростом, пока вы не осознаете важную вещь: мы больше не делегируем предложения. Мы делегируем действия.
Интересно то, что главной проблемой все реже становится вопрос о том, способны ли агенты выполнять эти задачи. Во многом они уже на это способны. Гораздо более сложный вопрос заключается в том, доверяют ли им разработчики настолько, чтобы поручать значимую работу. Узкое место смещается от возможностей к уверенности.
Когда я читал недавнее объявление Шрини Секарана о представлении Docker AI Governance, одно утверждение привлекло мое внимание:
Чем больше я думал об этом, тем больше мне казалось, что это не просто маркетинговый слоган, а полезный способ понять, что именно меняется в разработке ПО.
От ассистентов к агентам
Эволюцию инструментов разработчика за последние несколько лет можно рассматривать как прогресс. Сначала инструменты на базе ИИ помогали разработчикам, генерируя фрагменты кода и отвечая на вопросы. Затем появились копѝлоты, помогающие разработчикам выполнять более крупные задачи в рамках существующих рабочих процессов. Теперь мы вступаем в эру агентов. В отличие от ранних инструментов, агенты не просто рекомендуют действия. Они все чаще их выполняют. Как только программное обеспечение начинает совершать действия вместо того, чтобы предлагать подсказки, разговор об управлении меняется кардинально.
Небольшое наблюдение из опыта создания решений с использованием агентов
Однажды, работая над проектами в сфере ИИ и экспериментируя с рабочими процессами на базе агентов, я заметил, как быстро смещаются границы доверия.
Когда я только начал использовать инструменты ИИ, я в основном относился к ним как ко второму набору глаз. Я задавал вопросы по кодовой базе, проверял правильность подхода, генерировал небольшой фрагмент кода или помогал разобраться в документации. Инструменты были полезны, но они ничего не делали самостоятельно. Каждое действие по-прежнему зависело от моего решения о том, что делать дальше. Все изменилось по мере того, как агенты для кодирования становились все более функциональными.
Задачи, которые раньше требовали копирования кода между окнами, все чаще превращались в рабочие процессы, где агент мог изучать репозиторий, изменять файлы, запускать тесты и исправлять ошибки в ходе итераций при минимальном контроле. Прирост производительности был неоспорим, но точно так же очевидно было и то, что теперь агент имел доступ к той же среде, учетным данным и инструментам, что и я.
Как Docker Captain, я нахожу текущие обсуждения вокруг управления ИИ столь интересными именно по этой причине. Проблема не просто в том, что модели становятся более способными. Дело в том, что они все чаще взаимодействуют с реальными системами, а не генерируют текст изолированно.
Как только агент получает возможность выполнять действия от вашего имени, проблема сводится не только к его возможностям. Разработчикам нужна уверенность в том, что агент будет действовать в рамках понятных границ. Управление становится важным не только потому, что оно защищает системы, но и потому, что оно помогает людям доверять системам, которые они используют.
Почему разработчики все еще сомневаются
Большинство разработчиков беспокоятся не о том, сможет ли агент сгенерировать код. Их волнует, будет ли агент действовать предсказуемо, как только он начнет взаимодействовать с реальными системами. Эти сомнения часто проистекают из того факта, что наши существующие модели доверия были разработаны с расчетом на операторов-людей, а не на автономное программное обеспечение.
Большинство средств корпоративной безопасности формировалось вокруг относительно простого предположения: люди совершают действия, а системы обеспечивают контроль над этими действиями. Исходный код проходит через репозитории. Изменения проходят через конвейеры CI/CD. Производственные рабочие нагрузки выполняются в управляемых средах. Системы идентификации определяют, кто и к чему имеет доступ. Сетевые элементы управления ограничивают места обмена данными для рабочих нагрузок. Стек безопасности работает, потому что работа обычно перемещается через предсказуемые контрольные точки. Организации знают, где наблюдать за активностью, применять политики и собирать журналы аудита.
Агенты не следуют этим контрольным точкам
ИИ-агенты привносят иную операционную модель. Агент, работающий на машине разработчика, может изучать репозитории, выполнять команды, устанавливать пакеты, получать доступ к локальным файлам, отправлять запросы к API и взаимодействовать с внешними инструментами — и все это в рамках одной сессии. Что еще более важно, зачастую он делает это с теми же правами доступа, что и управляющий им человек. С точки зрения организации, значительный объем работы перемещается за пределы систем, которые изначально были созданы для контроля этой работы. Ноутбук — это больше не просто место, где пишется код. Все чаще это место, где выполняются решения.
Рисунок 1. Традиционная безопасность контролирует контрольные точки рабочего процесса. Управление агентами должно учитывать выполнение в среде выполнения.
Агенту-программисту не нужно ждать запроса на слияние (pull request) перед взаимодействием с кодовой базой. Он может анализировать и изменять файлы задолго до того, как изменения попадут в репозиторий. Он может получить доступ к учетным данным, доступным в локальной среде. Он может подключаться к внешним службам, используя те же разрешения, которые доступны его оператору.
Рассмотрим распространенный сценарий: агента просят выяснить, почему падает интеграционный тест. Чтобы отладить проблему, он может изучить файлы конфигурации, сгенерировать временные скрипты, установить дополнительные зависимости, выполнить диагностические команды и многократно перезапускать набор тестов еще до того, как результат просмотрит человек. Ни одно из этих действий не является необычным, но они иллюстрируют, как много активности теперь может происходить непосредственно в среде разработчика. Это не делает агентов опасными по своей сути. Это означает, что многие существующие предположения о безопасности заслуживают пересмотра.
Почему защитных барьеров на основе подсказок (промтов) недостаточно
Один из распространенных ответов — полагаться на инструкции. Укажите агенту не обращаться к конфиденциальным файлам. Укажите агенту не вызывать внешние службы. Укажите агенту не совершать рискованные действия. Эти инструкции полезны, но они принципиально отличаются от принудительного исполнения. Подсказка может повлиять на поведение. Среда выполнения может ограничить поведение. Это различие становится все более важным по мере того, как агенты приобретают все большую автономность. Безопасность традиционно была наиболее надежной там, где средства контроля существовали ниже уровня приложения. Права доступа к файловой системе не предполагают ограничений; они их обеспечивают. Сетевые политики не спрашивают, следует ли блокировать трафик; они его блокируют. Этот же принцип применим и к ИИ-агентам. Если организация хочет быть уверенной в том, что агент может и чего не может делать, эти гарантии в конечном итоге должны существовать на том уровне, где фактически выполняются действия.
Два способа взаимодействия агентов с миром
Если упростить проблему, большая часть активности агентов делится на две категории. Первая — это выполнение. Агенты читают файлы, изменяют код, устанавливают ПО, выполняют команды и открывают сетевые соединения. Вторая — это использование инструментов. Агенты взаимодействуют с внешними системами через API, интеграции и инструменты MCP. Сюда могут относиться GitHub, Jira, облачные платформы, внутренние сервисы, инструменты коммуникации или клиентские системы. Оба направления создают огромную ценность. Оба направления также несут в себе риски. Контроль только одного из них создает «слепую зону». Организация может тщательно контролировать доступ к внешним инструментам, упуская из виду то, что агент может выполнить локально. Или же она может обезопасить локальное выполнение, предоставив при этом широкий доступ к внешним системам. Эффективное управление требует прозрачности и контроля на обеих поверхностях.
Проблема управления
Вопрос для многих организаций заключается уже не в том, будут ли внедряться ИИ-агенты, а в том, как внедрять их ответственно. Это решение уже принимается инженерными командами по всему миру, поскольку прирост производительности реален. Более важный вопрос заключается в том, как организации могут принять автономию агентов, не жертвуя прозрачностью, подотчетностью и контролем. Не менее важно и то, что разработчикам нужна уверенность в том, что они понимают эти границы. Чем проще понять, к чему агент имеет доступ, что он может выполнять и изменять, тем проще внедрять агентов в повседневные рабочие процессы. Традиционные модели безопасности строились вокруг инфраструктурных границ. Управление агентами все больше требует границ времени выполнения.
- Где работает агент?
- К чему он имеет доступ?
- Что он может выполнять?
- Какие инструменты он может вызывать?
- Какие учетные данные он может использовать?
- И можно ли последовательно применять эти средства контроля независимо от того, работает ли агент на ноутбуке, в CI или в продакшене?
Эти вопросы быстро становятся вопросами инфраструктуры, а не просто вопросами ИИ. Поскольку если ИИ-агенты становятся активными участниками разработки программного обеспечения, то среды, в которых они функционируют, заслуживают такого же внимания, которое мы исторически уделяли производственным системам.
Ноутбук — это больше не просто место, где пишется код. Все чаще это место, где ПО совершает действия. И именно поэтому фраза «ваш ноутбук — это новый прод» воспринимается не столько как предсказание, сколько как описание того, куда уже движется современная разработка. Настоящая задача заключается не просто в том, чтобы дать агентам больше автономии. Она заключается в создании сред, в которых разработчики чувствуют себя комфортно, используя эту автономию. Ведь будущее разработки на основе агентов может зависеть не столько от того, на что способны агенты, сколько от того, что разработчики готовы им доверить.
Во второй части мы рассмотрим, как выглядит управление на уровне среды выполнения и почему изоляция, применение политик и контролируемый доступ к инструментам становятся фундаментальными строительными блоками для агентных систем.
