АНАЛИТИКА

GitLab: AI ускорил код, но не ускорил поставку софта

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

✍️ Редакция iTech News | 30.06.2026 | ⏱ 5 мин | Источник: InfoQ
🔍

AI в разработке уже дал командам заметный прирост скорости на уровне редактора кода: 78% опрошенных GitLab разработчиков говорят, что писать стало быстрее. Но на уровне бизнеса праздник пока не случился: 79% респондентов признают, что общий цикл поставки ПО не ускорился, потому что узкие места просто переехали дальше по конвейеру.

Об этом сообщает InfoQ со ссылкой на GitLab 2026 AI Accountability Report. Сценарий для многих знакомый: код генерируется бодрее, качество, по ощущениям команд, тоже растет, но релизы по-прежнему вязнут в проверках, согласованиях и попытках понять, кто вообще отвечает за конкретный кусок AI-сгенерированного кода, когда он уже оказался в проде.

Цифры у GitLab получились довольно показательные. Помимо 78% разработчиков, которые видят ускорение кодинга, 73% респондентов заявили, что качество кода в целом улучшилось. На бумаге это выглядит как почти готовый кейс для победного слайда в квартальной презентации. На практике 85% участников исследования согласились с другой формулировкой: AI не убрал бутылочное горлышко, а просто переместил его из написания кода в его ревью и валидацию. Иными словами, команды стали быстрее производить материал для следующей очереди.

GitLab называет это AI-парадоксом. Компания формулирует проблему через термин AI accountability — способность организации и ее инструментов ответить на три неприятных, но очень полезных вопроса про любую строку AI-сгенерированного кода: откуда она взялась, что должна была делать и кто несет за нее ответственность после выката в продакшн. Судя по выводам отчета, у большинства компаний с этим пока не очень. AI в разработке стал частью повседневной инженерной практики быстрее, чем корпоративные процессы успели обрасти контролями, политиками и нормальной трассировкой изменений.

Скорость выросла, управляемость — не факт

Самый болезненный вывод исследования не в том, что AI не помогает. Помогает, и довольно ощутимо. Проблема в том, что ускорение на одном этапе не превращается в ускорение всего процесса. Пока разработчик и ассистент по коду бодро собирают новый функционал, дальше включаются тестирование, код-ревью, комплаенс, безопасность, аудит, архитектурные согласования и прочие радости зрелой разработки. Если эти этапы не автоматизированы и не связаны между собой, команда получает не более быстрый delivery, а более плотную пробку.

Manav Khurana, Chief Product and Marketing Officer в GitLab, прямо связывает это с рисками для компаний. В материале InfoQ он напоминает, что на фоне атак на цепочки поставок, проблем с надежностью и растущих ожиданий регуляторов вопрос трассируемости перестал быть бюрократической прихотью. Это уже не история про «нам бы лучше задокументировать процесс», а про способность быстро восстановить происхождение изменений и понять, не принес ли AI в прод скрытый дефект, уязвимость или просто кусок логики, который никто толком не валидировал.

Отдельно GitLab разбирает, почему traceability деградирует именно с приходом генеративных инструментов. На первом месте — трудность отличить AI-сгенерированный код от написанного человеком, так ответили 43% респондентов. Еще 40% указали на фрагментированные toolchain'ы: когда IDE, CI/CD, security-сканеры, таск-трекер и внутренние ассистенты живут каждый своей жизнью, склеить сквозную картину происхождения изменений почти невозможно. Еще 39% говорят, что их системы вообще не отслеживают источник кода как отдельную сущность. В такой схеме строка в репозитории существует, а ее родословная — уже нет.

На этом фоне особенно любопытно выглядит разрыв между уверенностью и реальностью. 87% участников опроса уверены, что их команда смогла бы в течение 24 часов определить, участвовал ли AI-сгенерированный код в продакшн-инциденте. Но среди организаций, которые реально пережили инцидент за последний год, 34% не смогли это установить на практике. То есть теоретически все готовы к экзамену, но когда приходит настоящий сбой, шпаргалка внезапно оказывается пустой. Для IT-директоров и руководителей платформенных команд это, пожалуй, главный сигнал из всего отчета: самоощущение зрелости здесь легко расходится с операционной реальностью.

Что это значит для команд и бизнеса

Для разработчиков эта история звучит почти как подтверждение того, что многие и так чувствовали последние месяцы. AI в разработке реально экономит время на написании шаблонного, рутинного или хорошо формализуемого кода. Но большая часть работы инженера по-прежнему лежит вне зоны «напечатаем быстрее». Нужно проверить гипотезу, согласовать поведение фичи, дождаться ревью, пройти тесты, убедиться, что ничего не сломалось в зависимостях, а потом еще объяснить, почему это изменение вообще было нужно. Именно поэтому в статье InfoQ упоминаются и обсуждения на Reddit: разработчики описывают рост скорости на уровне текстового редактора, который почти не влияет на story points и фактический throughput команды.

Для бизнеса вывод еще приземленнее. Если компания активно внедряет генерацию кода, но не перестраивает процессы контроля, она не покупает ускорение поставки как таковое. Она покупает рост объема изменений, который затем нужно проверять, объяснять и обслуживать. По данным GitLab, 85% респондентов считают, что ответ лежит в более сильном governance: нужны четкие политики, которые фиксируют происхождение AI-сгенерированного кода и распределяют ответственность за него. Без этого 83% организаций уже воспринимают накопление такого кода как риск, а 44% относят его к числу своих главных технологических проблем.

Для русскоязычного IT-рынка здесь нет экзотики. У местных продуктовых команд, интеграторов и крупных внутренних разработок картина очень похожая: AI-инструменты охотно встраиваются в IDE и pull request-процессы, но дальше начинаются старые знакомые вопросы про аудит, безопасность, соответствие внутренним политикам и воспроизводимость решений. Особенно это чувствительно в финтехе, телекоме, госсекторе и enterprise-разработке, где «примерно понятно, откуда взялся этот код» не считается рабочим ответом. Чем активнее компании будут раскатывать AI-помощников на всю инженерную организацию, тем выше станет спрос не на еще один автодополнитель, а на системы учета происхождения изменений, связку с CI/CD и нормальные правила эскалации ответственности.

Главный вывод из отчета GitLab звучит не как приговор AI, а как неприятное уточнение к завышенным ожиданиям. Индустрия уже научилась ускорять набор текста в редакторе и генерацию кусков логики. Следующий раунд конкуренции пойдет не за то, кто производит больше строк, а за то, кто умеет доказуемо провести их через ревью, тесты, безопасность и продакшн без потери контроля. И если этот слой управления не догонит скорость генерации, AI в разработке рискует остаться отличным ускорителем локальной продуктивности, но не рычагом для реального ускорения бизнеса. Подробности исследования приводит InfoQ.

Поделиться: Telegram X LinkedIn