ИИ‑кодинг, призванный облегчить разработку, оборачивается растущим давлением на инженерные команды. Авторство кода часто не определить, а код‑ревью превращается в главное «бутылочное горлышко»: фокус смещается со скорости написания на проверку, контроль и интерпретируемость. В июне 2026 года GitLab выпустил отчет об ответственности за ИИ‑код, а The New Stack разобрало его в статье Эдриана Бриджуотера — на основе большого интервью с директором по продукту и маркетингу GitLab Манавом Хураной. Мы перевели этот материал и дополнили его цифрами из самого отчета, чтобы за тезисами Хураны стояли данные.
Итак, сначала цифры, выглядящие как успех: 91% компаний держат в работе минимум два ИИ‑инструмента, 54% — три и более. 78% команд пишут и коммитят код быстрее, чем раньше, 60% говорят, что отдача от ИИ превзошла ожидания, 73% отмечают рост качества кода. По любым меркам внедрение состоялось.
А теперь «менее успешная цифра»: 80% признают, что подключили ИИ‑инструменты раньше, чем придумали, как ими управлять. Скорость обогнала контроль, и вся история начинается ровно на этом стыке.
В отчете (опрос 1528 разработчиков и ИТ‑заказчиков из шести стран) называют этот эффект «парадоксом ИИ»: продуктивность отдельного разработчика выросла — с этим согласны 79% — а скорость доставки ПО в целом за ней не поспевает. Отдельный человек кодит быстрее, конвейер — нет.
85% опрошенных согласны, что ИИ сместил не только фокус, но и боттлнек с написания кода на его проверку и валидацию. Если раньше дефицитом были разработчики, то теперь не хватает ресурса ревьювера. А проверять приходится то, авторство чего не всегда понятно: отличить сгенерированный код от написанного человеком не может почти половина опрошенных (43%).
По мнению Хураны, корень проблемы — разрыв в управлении (governance gap), который создает лавинообразный рост объемов кода. Планы по внедрению ИИ, как правило, не учитывают сложностей, которые оно приносит следом. Почему это обострилось именно сейчас, Хурана объясняет событиями последних месяцев: атаками на цепочки поставок, сбоями надежности и тем, что регуляторы ужесточили требования к прослеживаемости и происхождению кода. Его вывод: скорость без контроля — это не преимущество, а уязвимость.
Команды и руководители упускают из вида, что написание кода — лишь этап в цикле разработки ПО. Перед его созданием формулируются требования, после идут ревью, тестирование, проверки безопасности и деплой, а за ними — доработки, интеграции и сопровождение. 84% респондентов называют главной сложностью с ИИ‑кодом не его генерацию, а все, что происходит после.
Подписи «запустившего» агента разработчика и решаемой кодом задачи здесь недостаточно. При мониторинге мерджей разработчику все равно приходится обращаться к разрозненным системам, чтобы понять, какие проблемы безопасности были затронуты, какими политиками регулировался процесс и устранены ли возникшие риски.
Уверенность есть, прослеживаемости — нет
Отчет вскрывает неприятный зазор между самоощущением команд и реальностью. 87% уверены, что за сутки определят, причастен ли ИИ‑код к инциденту на проде. Звучит спокойно — пока не посмотришь на тех, у кого инцидент действительно случился: треть из них (34%) так и не смогла установить, виноват ли в нем ИИ‑код.
Три главных барьера, которые называет отчет, — не про людей, а про инструменты. Сгенерированный код не отличить от рукописного — так отвечают 43%. Инструменты разработки разрознены — 40%. Системы не отслеживают происхождение кода — 39%. Дело не в том, что разработчики ленятся разбираться, — у них нет для этого инструмента, с помощью которого можно посмотреть, откуда взялась конкретная строка кода и что с ней происходило дальше.
Разрыв в tool‑chain для ИИ‑агентов
Полная интеграция инструментов цикла разработки (SDLC) с общими данными и процессами — задача, с которой справились лишь 28% компаний. Чтобы управлять множеством сервисов, нужны сквозное логирование и обязательная привязка каждого действия к агенту или человеку, инициировавшему задачу.
Главная цель изменений в обновленном GitLab — сделать слой управления невидимым для разработчика. Ревью тогда сводится к ключевым решениям, которые действительно требуют человека: остальная часть процесса проходит автоматически, опирается на политики компании, а действия агентов логируются и привязываются к личности.
Как GitLab меняется под ИИ‑кодинг
GitLab пришлось переработать Git‑бэкенд и API под выполнение в машинном масштабе, без участия человека. По заявлению компании, платформа надежно держит миллионы агентских сессий и работает на высокой скорости.
Внутренние тесты обещают ускорение wall clock time (реального времени выполнения задачи) в 50 раз и сокращение сетевого трафика в 1000 раз по сравнению с текущим поколением Git. Заявлены также ускорение работы ИИ‑агентов в 11 раз, снижение расхода токенов в 4,5 раза и сокращение галлюцинаций в 45 раз. Оговоримся: это оценки самого вендора.
В июне был представлен Orbit — граф контекста для агентов. Он связывает код, пайплайны, рабочие задачи, находки безопасности и производственные сигналы так что агент получает весь контекст одним запросом к графу и отвечает на вопросы, которые раньше ставили ИИ в тупик.
Безопасный ИИ‑код: три главных вопроса
Отчет предлагает определение AI accountability — ответственности за действия ИИ и сводит его к трем простым вопросам к каждой строке кода:
-
Каков источник кода?
-
Какую функцию он должен выполнять?
-
Кто отвечает за код после его выхода в прод?
Большинство работающих с ИИ команд ответить на эти вопросы не могут. 73% респондентов беспокоятся о поддерживаемости ИИ‑кода, 82% считают, что он создает новый вид техдолга, к которому организация не готова, а 83% уже относят накопление ИИ‑кода к рискам, которыми надо управлять сейчас. 44% и вовсе называют это одним из главных технологических рисков. Хурана добавляет еще один симптом, денежный. Когда расходы на ИИ начинают неожиданно расти, это, по его словам, обычно и есть признак растущего разрыва в управлении: агенты жгут токены на инфраструктуре, которая под них не проектировалась, — не хватает слоев контекста и управления.
Причина повторяется из команды в команду: ИИ‑инструменты пытаются натянуть поверх существующей инфраструктуры с тяжелым legacy и накопленными костылями. Отдельная инфраструктура под ИИ‑агентов позволяет выполнять рутину автоматически, на машинной скорости и с сохранением контроля — и превращает ИИ‑помощников из «бутылочного горлышка» в локомотив развития всей инфраструктуры.
О чем стоит задуматься разработчикам?
Реалии меняют требования как к Senior‑менеджменту проектов, так и Junior‑разработчикам и DevOps. Важнейшим навыком становится способность рассуждать и выносить суждения. Понимания синтаксиса уже недостаточно: даже неопытные сотрудники должны разбираться в архитектуре, чтобы суметь проследить всю историю ИИ‑кода «в обратном направлении» — через пройденные им пайплайны и известные уязвимости и производственные сигналы.
Агенты генерируют код быстрее любого человека, но пока не могут оценить, уместен ли он в системе, отвечает ли требованиям и политикам, которым она должна соответствовать. Именно эту оценку придется делать людям — и делать осознанно. Зрелый подход к сгенерированному коду и переводит ИИ из категории инструментов для производительности отдельного сотрудника в фундаментальный, понятный и масштабируемый элемент инфраструктуры.
Подытожим. Внедрение ИИ в разработку должно начинаться не только с прогнозов о количестве кода, который можно создать с помощью ИИ. Оно должно начинаться с упомянутых выше трех вопросов, и только когда команда готова ответить на них не «за сутки в теории», а «прямо сейчас».
Автор: Basis_Habr
