Люди держатся за жизнь, пока ИИ ускоряет доставку программного обеспечения

На протяжении большей части истории разработки программного обеспечения контроль находился в руках людей. Разработчик вносит изменение, другой человек проверяет его, кто‑то одобряет, и в конце концов оно разворачивается.

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

Наш инстинкт — вернуть людей в процесс. Мы проверяем pull‑request, одобряем вызов инструмента, проверяем изменение и подтверждаем развертывание, потому что хотим убедиться, что ИИ не сделал того, чего не должен был. Мы держимся за жизнь.

Этот инстинкт имеет смысл. Человеческий обзор дал нам способ сохранять контроль по мере продвижения программного обеспечения к продакшну. Но ИИ начинает работать с такой скоростью и объёмом, что люди не могут оставаться единицей масштабирования для управления.

ИИ уже опережает человеческий контроль

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

Проблема не в том, что ИИ создает более плохие изменения. Он создает больше изменений, быстрее. Если контроль над всем этим новым объёмом возлагается на ещё одного человека, проверяющего каждое изменение, в конце концов расчёты перестают работать.

Мы уже видим признаки этого. Anthropic недавно сообщил, что пользователи Claude Code одобряют около 93 % запросов на разрешения. Компания обнаружила, что повторяющиеся запросы могут вызывать усталость от одобрения, когда люди уделяют всё меньше внимания по мере роста количества одобрений. Anthropic теперь использует автоматический классификатор для оценки действий и блокировки потенциально опасных, вместо того чтобы просить человека одобрять всё.

Подумайте, что это говорит о человеческом надзоре. Если кто‑то нажимает «одобрить» в 93 % случаев, добавление ещё одного одобрения не обязательно даёт вам больший контроль. В какой‑то момент человек становится ещё одним шагом в рабочем процессе.

Мы можем использовать ИИ для создания большего количества программного обеспечения. Мы не можем ответить, создав столь же большую операцию человеческого контроля позади него.

ИИ переходит от создания кода к выполнению действий

Помощники по кодированию предоставили ИИ роль в разработке. Агенты дают ИИ возможность участвовать во многих этапах жизненного цикла разработки (SDLC). Агент может получить цель, решить, как её достичь, использовать инструменты, наблюдать за результатами и корректировать свои дальнейшие действия.

В программной инженерии это может означать изменение файлов, выполнение команд, взаимодействие с репозиториями, вызов API, тестирование кода или работу с инфраструктурой. Люди также всё более комфортно позволяют агентам работать самостоятельно. В исследовании миллионов взаимодействий человек‑агент Anthropic обнаружил, что опытные пользователи Claude Code использовали полное автоодобрение более чем в 40 % сессий, примерно вдвое чаще, чем новые пользователи.

Это не значит, что автономные агенты уже управляют продакшн‑окружениями везде. Их нет. Но разработка программного обеспечения даёт нам ранний взгляд на то, куда это движется.

Сегодня ИИ создаёт больше изменений, и человеческий контроль начинает напрягаться. Далее ИИ будет участвовать в большем числе этапов SDLC. В конечном итоге агенты будут создавать, проверять, развёртывать, наблюдать и исправлять изменения с гораздо меньшим участием человека.

На каждом этапе мы убираем ещё одну точку, где человек раньше обеспечивал контроль. Вопрос меняется с того, может ли ИИ выполнять работу, на то, что ИИ должен быть разрешён делать самостоятельно.

Разрешение не является полномочием

Агентам нужен доступ для выполнения полезной работы. Агент, помогающий развёртывать программное обеспечение, может нуждаться в доступе к репозиторию, системе CI/CD, облачному окружению или базе данных. Убрав этот доступ, вы также лишаете агента большей части его полезности.

Но доступ и полномочия — не одно и то же. Предоставление агенту разрешения на доступ к системе не означает, что он имеет полномочия выполнять каждое действие, доступное в этой системе.

Традиционный контроль доступа может показать, имеет ли агент разрешение на доступ к чему‑то. Нам также нужен способ определить, должно ли происходить конкретное действие, которое он хочет выполнить. Это становится более важным, когда система, принимающая решение, может интерпретировать задачу иначе, чем человек, её задавший, столкнуться с препятствием и выбрать иной путь, или использовать легитимный инструмент способом, которого никто не предвидел.

OWASP описывает одну из версий этой проблемы как Избыточное агентство. Она указывает на избыточный функционал, разрешения и автономию как причины вредных действий и рекомендует независимое одобрение для действий с высоким воздействием.

NVIDIA решает ту же проблему на уровне архитектуры. Ее Open Agent Safety Platform размещает принудительное выполнение политик за пределами агента и делает простой вывод: от агента нельзя ожидать полного самоуправления своим поведением.

Это должно определять, как мы строим AI SDLC. Агент может потребовать разрешения на доступ к базе данных, инфраструктурной среде или системе развертывания. Это не означает, что агент должен самостоятельно решать, что каждое изменение, которое он хочет внести, безопасно.

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

Человек в цепочке не может быть единственным решением

Очевидный ответ — держать человека перед последствиями действий ИИ. Для некоторых решений именно так и следует поступать. Ошибка заключается в том, что «человек в цепочке» превращается в ответ для каждого решения.

Если каждое действие агента требует, чтобы кто‑то проверил его и нажал «одобрить», мы воссоздаём узкое место, которое ИИ должен был устранить. Хуже того, достаточное количество одобрений может превратить надзор в привычку. Человек, который целый день нажимает «одобрить», не обязательно проявляет суждение.

Нужно более осознанно подходить к тому, где принимаются решения. ИИ может принимать решения в рамках поставленных ему задач. Политика может обрабатывать решения, где правила уже известны. Люди могут заниматься исключениями и решениями, которые действительно требуют суждения.

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

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

Размещайте контроль там, где происходит действие

Предприятия не будут стандартизировать один AI‑модель или одного агента. Разработчики будут использовать разные копилоты. Команды будут экспериментировать с различными моделями. ИИ появится внутри инструментов разработчика, продуктов безопасности, платформ данных и внутренних приложений.

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

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

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

Это также позволяет технологии развиваться без необходимости компаниям каждый раз перестраивать систему управления. Модели будут меняться. Агентам будет предоставлена большая функциональность. Контроль над критическими системами может оставаться неизменным.

NIST применяет аналогичный основанный на риске подход в своей AI Risk Management Framework, который рассматривает управление как нечто, что должно функционировать на протяжении всего жизненного цикла ИИ, а не как единственное одобрение в конце. Для поставки программного обеспечения это означает внедрение контролей в путь, который уже выбирает ИИ, вместо того чтобы прикреплять к нему еще один ручной процесс.

Когда человек уходит, доказательства не могут уйти вместе с ним

Существует ещё одна проблема, скрытая в модели человеческой проверки. Когда вы исключаете человека из процесса, вы теряете не только проверку. Вы также можете потерять того, кто помог подтвердить, что проверка имела место.

Это становится серьёзной проблемой для компаний с требованиями к безопасности, соответствию и аудиту. Им всё равно необходимо знать, что изменилось, кто или что инициировало изменение, какая политика применялась, прошло ли оно, кто одобрил исключение, где было выполнено изменение и что случилось впоследствии.

Нельзя автоматизировать изменение и оставить доказательства в ручном виде. В процессе, управляемом человеком, команды могут позже воссоздать доказательства из тикетов, одобрений, журналов конвейера, скриншотов и разговоров. Этот подход становится сложнее по мере роста объёма изменений и нереалистичным, когда машины постоянно создают и выполняют изменения.

Доказательства должны стать частью процесса поставки. Решения политики, одобрения, исключения, развертывания и результаты должны создавать записи в момент выполнения работы. Аудиторские доказательства становятся побочным продуктом поставки программного обеспечения, а не тем, что команды собирают после завершения.

Это оставляет две разные задачи для управления в AI‑ориентированном SDLC. До действия необходимо определить, должно ли оно произойти. После действия — доказать, что произошло.

Люди не исчезнут. Наша роль меняется.

Есть понятный инстинкт измерять контроль тем, сколько раз в процесс вовлечён человек. Больше проверок кажется безопаснее. Больше одобрений кажется безопаснее. Держать человека в каждой цепочке кажется безопаснее.

ИИ проверит это предположение. Если ИИ продолжит увеличивать объём создаваемого программного обеспечения, люди не смогут проверять каждое изменение, одобрять каждое действие, наблюдать за каждым развертыванием и впоследствии восстанавливать каждое решение. Попытка сделать это либо замедлит развитие ИИ, либо превратит человеческий надзор в формальность.

Жизненный цикл разработки ИИ (AI SDLC) требует иной модели распределения труда. ИИ может выполнять большую часть работы, в то время как политика регулирует повторяемые решения, а люди вмешиваются, когда действительно требуется суждение. Доказательства должны создаваться автоматически в процессе.

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

Людям не нужно держаться ещё крепче. Цель не в уменьшении контроля. Это модель контроля, которая не зависит от того, что мы удерживаем каждое решение в своих руках. Нам нужно построить механизмы, позволяющие ослабить хватку, не теряя контроля.