Парадокс ИИ-кодинга: 97% внедрения, 90% узких мест и кризис управления

• Ручное код-ревью (52%) — ревьюерам теперь приходится обрабатывать больший объем сгенерированного ИИ кода, чем написанного человеком, и этот объем продолжает расти
• Тестирование безопасности (51%) — код, сгенерированный ИИ, порождает новые классы уязвимостей, которых не было в коде, написанном вручную: особенно это касается внедрения зависимостей (dependency injection), жестко зашитых секретов (hardcoded secrets) и рекомендаций по использованию устаревших библиотек
• Доработка сгенерированного кода (48%) — почти половина команд сообщает, что тратит значительное время на исправление, рефакторинг или переписывание результатов работы ИИ перед тем, как код может попасть в релиз

У этого явления уже появилось название: сдвиг рутины (toil shift). Вместо того чтобы устранять работу, ИИ перемещает ее с этапа создания на этапы проверки, тестирования и исправления . Формулировка Black Duck предельно откровенна: «Большинство организаций генерируют код с помощью ИИ быстрее, чем могут его проверить, защитить или управлять им» .

Управление: истинный мультипликатор окупаемости инвестиций

Если и есть в отчете один вывод, к которому стоит прислушаться техническим руководителям, так это следующий: управление (governance) — это мультипликатор возврата инвестиций . Разница между командами, которые управляют использованием ИИ, и теми, кто этого не делает, — не маржинальная. Это разница между реальным приростом эффективности и ее утечкой сквозь пальцы.

Black Duck обнаружила, что организации с полноценными системами управления сообщили о 90% случаев существенного прироста эффективности от ИИ-инструментов. В командах без структурированного надзора этот показатель падает до 44% .

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

Проблема теневого ИИ

Ситуацию с управлением осложняет распространение теневого ИИ (Shadow AI) — случаев, когда разработчики используют ИИ-инструменты в обход или вопреки корпоративной политике. Black Duck выяснила, что 18% организаций называют теневой ИИ значительным неуправляемым риском . Когда такие инструменты, как Cursor, Windsurf или Claude Code, внедряются отдельными разработчиками, минуя закупки и проверку службой безопасности, организация теряет видимость своей поверхности атаки .

Риски цепочки поставок: что наследует ИИ-сгенерированный код

Последствия для цепочки поставок программного обеспечения — это та область, где пробелы в управлении превращаются в конкретные уязвимости. Работа Black Duck, включая смежный отчет 2026 OSSRA, выявляет три взаимосвязанных риска, характерных именно для ИИ-помощников:

«Отмывание» лицензий. ИИ-ассистенты, обученные на открытых репозиториях, могут генерировать фрагменты кода из источников с копилефт-лицензиями (например, GPL), не сохраняя исходную информацию о лицензии . Отчет 2026 OSSRA показал, что две трети проверенных кодовых баз содержат лицензионные конфликты — это самый высокий показатель за всю историю наблюдений . Организации могут выпускать код, на использование которого у них нет прав, даже не подозревая об этом.

Взрывной рост зависимостей. Количество open-source компонентов на одну кодовую базу выросло на 30% в годовом исчислении, а среднее число уязвимостей на кодовую базу резко увеличилось на 107% . ИИ-помощники кодинга ускоряют этот тренд, генерируя решения быстрее и из более широкого пула обучающих данных — каждая функция, предложенная ИИ, может «подтянуть» за собой зависимости, которые разработчик явно не выбирал.

Разрыв в комплаенсе. Только 24% организаций проводят комплексную оценку ИИ-сгенерированного кода на предмет интеллектуальной собственности, лицензий, безопасности и качества . Это означает, что три четверти компаний не могут достоверно ответить на вопрос: «Какие юридические и связанные с безопасностью обязательства мы только что на себя взяли?»

Доверие разработчиков: использование растет, уверенность падает

Данные Black Duck существуют не в вакууме. Результаты нескольких независимых опросов, опубликованных примерно в то же время, подтверждают и дополняют картину доверия, добавляя конкретики:

• Опрос Sonar «State of Code Developer Survey» за 2026 год (более 1100 разработчиков) показал, что 96% разработчиков не полностью доверяют функциональной точности кода, сгенерированного ИИ . При этом только 48% всегда проверяют его перед коммитом — то есть код, которому сами разработчики не доверяют, регулярно попадает в продакшн .
• Опрос Stack Overflow за 2025 год (49 009 респондентов) показал, что доверие к точности ИИ упало с 40% до 29% за один год. Активное недоверие выросло до 46%, а положительное отношение снизилось с 72% до 60% .
• Отчет Harness «State of AI-Driven Software Releases 2026» (500 технических руководителей) показал, что 57% все еще требуют контроля человеком (human-in-the-loop) для каждой строки ИИ-кода, а 29% тратят на код-ревью больше времени, чем до внедрения ИИ-ассистентов .

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

Диана Келли, директор по информационной безопасности в Noma Security, точно сформулировала главное противоречие: «Более быстрый код — не то же самое, что более безопасный код» .

Как на самом деле выглядит управление

Рецепт от Black Duck не абстрактен. В отчете перечислены конкретные меры, которые отличают 30% компаний с полноценным управлением от остальных:

1. Структурированные системы управления ИИ — не неформальные рекомендации, а задокументированные, соблюдаемые политики, охватывающие одобрение инструментов, проверку результатов и распределение ответственности
2. Встроенные в конвейер проверочные барьеры — отказ от передачи кода на ручное тестирование безопасности в пользу автоматизированных проверок качества и безопасности при каждом коммите с ИИ-ассистентом (что все еще практикуют 46% компаний)
3. Непрерывный мониторинг после развертывания — Black Duck отмечает, что «стратегии сдвига влево уже недостаточно», потому что риск появляется, обнаруживается и должен управляться на протяжении всего жизненного цикла разработки ПО
4. Рационализация ландшафта инструментов безопасности — более 71% респондентов назвали «зоопарк» разрозненных средств безопасности (tool sprawl) основным источником трений, и консолидация на меньшем количестве хорошо интегрированных инструментов является обязательным условием безопасного масштабирования ИИ

Сухой остаток

Отчет Black Duck не призывает отказаться от использования ИИ-помощников. Он утверждает, что использование их без соразмерного управления — это путь в никуда. Когда 97% команд генерируют код с беспрецедентной скоростью, и лишь 30% имеют инфраструктуру надзора, способную с этим справиться, — индустрия коллективно выписывает чеки, которые не может обналичить.

Корреляция между управлением и приростом эффективности — 90% против 44% — делает бизнес-кейс однозначным. Компании, которые сначала выстроят защитные перила, получат ту производительность, которую обещает ИИ. Остальные же будут раз за разом обнаруживать, что время, сэкономленное за клавиатурой, тратится в очереди на код-ревью.