AI пишет код быстрее, чем компания принимает за него ответственность

AI-инструменты уже не просто предлагают следующую строку кода.

Они могут изучить репозиторий, изменить несколько компонентов, подключить библиотеку, обновить конфигурацию сборки, написать тесты, выполнить команды и подготовить pull request.

С точки зрения скорости разработки это выглядит как серьёзный прогресс.

Но возникает управленческий вопрос, который компании пока обсуждают значительно реже:

какой объём изменений разработчик способен действительно понять до того, как нажмёт Approve?

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

С появлением coding agents ситуация изменилась. Теперь человек может сформулировать задачу из нескольких предложений и получить сотни или тысячи строк изменений, затрагивающих бизнес-логику, зависимости, тесты, инфраструктуру и CI/CD.

Технически у такого изменения есть reviewer.

Но есть ли у него реальный владелец?

Ценность code review состоит не в самом факте просмотра diff.

Reviewer должен понять:

Когда AI создаёт изменение быстрее, чем человек способен его осмыслить, review начинает деградировать.

Разработчик видит зелёные проверки, аккуратное описание pull request и убедительный набор тестов. После беглого просмотра изменение выглядит приемлемым.

Но тесты могли быть созданы тем же агентом, который написал код. Он мог ослабить assertion, замокировать критичную зависимость или зафиксировать в тесте не ожидаемое поведение, а собственную ошибочную реализацию.

OWASP отдельно предупреждает, что прохождение AI-generated tests само по себе не является независимым подтверждением безопасности. Для критичных механизмов — аутентификации, авторизации, обработки входных данных и криптографии — необходима отдельная проверка и независимые негативные сценарии. (cheatsheetseries.owasp.org)

Проблема здесь не в том, что AI обязательно пишет плохой код.

Проблема в том, что убедительно выглядящий результат легко спутать с понятым и проверенным результатом.

Распространённый ответ на эту проблему — усилить автоматические проверки.

Добавить SAST, SCA, secret scanning, dependency scanning, policy checks и AI code review.

Это необходимо, но недостаточно.

Сканер может найти известный небезопасный вызов. Он может обнаружить секрет в репозитории или уязвимую версию библиотеки.

Но он не всегда поймёт, что:

Безопасность программного продукта определяется не только отсутствием известных уязвимостей. Она зависит от того, понимает ли команда, какие доверительные границы, данные, полномочия и бизнес-инварианты она реализует.

Security checks могут подтвердить выполнение части правил. Они не могут принять инженерное решение во владение.

Ещё одна ошибка — воспринимать coding agent как более удобный поисковик или генератор текста.

Современный агент может читать репозиторий, выполнять shell-команды, устанавливать пакеты, изменять workflow, обращаться к внешним ресурсам и использовать учётные данные среды разработки.

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

OWASP рекомендует запускать таких агентов в изолированных средах, ограничивать доступные команды, сеть и файловую систему, использовать краткоживущие credentials и не предоставлять доступ к production-секретам. (cheatsheetseries.owasp.org)

GitHub также рассматривает coding agent как самостоятельный источник риска: agent-generated pull requests требуют человеческого review, агент не может самостоятельно одобрить или выполнить merge, а запуск привилегированных workflows по умолчанию требует отдельного человеческого действия. (GitHub Docs)

Это важный принцип:

автономность AI должна ограничиваться не удобством инструмента, а возможным радиусом ущерба.

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

Особенно опасно, когда developer автоматически разрешает агенту выполнять команды установки.

В таком режиме фраза «добавь библиотеку для решения задачи» фактически превращается в делегирование решения о включении нового элемента в software supply chain.

OWASP рекомендует проверять существование предложенного пакета, историю его сопровождения, дату создания, известные уязвимости и соответствие внутреннему allowlist. Отдельно отмечается риск устаревших зависимостей и вымышленных названий пакетов. (cheatsheetseries.owasp.org)

Следовательно, AI-generated dependency должна проходить тот же процесс, что и выбранная человеком:

AI может ускорить поиск варианта. Но он не должен самостоятельно принимать supply-chain risk.

В зрелом процессе у каждого изменения должен быть человек, способный ответить на три вопроса:

Фраза «AI сгенерировал» не отвечает ни на один из них.

OWASP формулирует этот принцип предельно ясно: у каждого AI-generated change должен быть человеческий владелец, отвечающий за корректность, безопасность и сопровождение. Также рекомендуется сохранять сведения о разработчике, одобрившем изменение, использованном AI-инструменте и версии модели. (cheatsheetseries.owasp.org)

Это не означает, что каждую строку AI-кода необходимо маркировать навсегда.

Но для существенных изменений компании нужно обеспечивать provenance:

Без этого расследование дефекта или инцидента быстро превращается в поиск человека, который «вроде бы нажал кнопку».

Одинаковая политика для всех репозиториев не работает.

Исправление опечатки в документации и изменение механизма авторизации не должны проходить одинаковый путь, даже если оба изменения созданы AI.

Компаниям нужна policy matrix, связывающая автономность coding agent с риском компонента.

УровеньДопустимая автономностьТип измененийОбязательные ограничения0Только рекомендацииКритичные системы, security-sensitive logicAI не изменяет файлы и не выполняет команды1Изменение локальной веткиДокументация, boilerplate, низкорисковые unit testsHuman review, стандартный CI2Изменение нескольких файлов и запуск тестовОбычная продуктовая логикаОграниченная sandbox-среда, SAST, SCA, CODEOWNERS3Создание pull request и изменение dependenciesНекритичные сервисыНезависимый reviewer, provenance, dependency approval4Автоматический mergeТолько заранее определённые низкорисковые измененияЖёсткий allowlist, полный audit trail, автоматический rollbackЗапрещеноАвтономный deployАвторизация, платежи, персональные данные, production-инфраструктураЯвное человеческое решение и разделение полномочий

Конкретные уровни могут отличаться.

Но принцип должен сохраняться:

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

Запретить AI-инструменты — слабая стратегия. Она почти неизбежно создаст shadow AI и перенесёт использование в неконтролируемые среды.

Более зрелый подход состоит из восьми действий.

Зафиксировать approved AI coding tools, модели, режимы хранения данных и категории репозиториев, где они могут использоваться.

Выделить security-critical, safety-critical, regulated и business-critical компоненты. Для них должны действовать более строгие правила автономности.

Использовать sandbox, минимальные права, tool allowlists, сетевые ограничения и краткоживущие credentials.

Большой AI-generated pull request следует разбивать на небольшие логические изменения. Reviewer должен иметь возможность построить корректную ментальную модель решения.

Approve должно означать не «diff выглядит нормально», а «я понимаю изменение и принимаю ответственность за его эксплуатацию».

Для существенных изменений сохранять инструмент, модель, инициатора, reviewer, выполненные проверки и доступные агенту полномочия.

Не позволять одному агенту одновременно писать security-critical код, создавать единственные тесты и выполнять итоговый review.

Количество AI-generated lines — плохая бизнес-метрика.

Нужно смотреть на lead time, escaped defects, rollback rate, security findings, размер pull request, время review и стоимость сопровождения.

NIST продолжает развивать SSDF и практические DevSecOps-рекомендации именно как интегрированный процесс, в котором безопасность должна быть встроена в жизненный цикл разработки, а не добавлена после генерации кода. (NIST Computer Security Resource Center)

Я не считаю AI-generated code отдельной категорией кода, за которую можно установить пониженную ответственность.

Наоборот: чем легче было создать изменение, тем внимательнее компании нужно проверить, не стало ли так же легко создать будущую проблему.

AI может быть автором текста кода, но не владельцем решения.

Владельцем остаётся человек, который разрешил изменение, и организация, которая построила процесс его принятия.

Главный риск AI coding состоит не в том, что модель иногда ошибается.

Разработчики тоже ошибаются.

Главный риск — в промышленном масштабировании изменений, которые никто не успел полностью понять, но которые уже получили формальное одобрение и попали в production.

AI действительно способен ускорить delivery.

Но скорость становится преимуществом только тогда, когда компания успевает принимать созданные изменения во владение.

Иначе AI не сокращает технический долг.

Он помогает создавать его быстрее.

Подписывайтесь на мой ТГ канал: @ib_decisions