GM перестроила инженерные процессы вокруг AI-агентов и утроила количество принятых pull request'ов

01Введение

Программные инженеры подразделения автономного вождения General Motors (GM) тратят лишь 15% своего времени на написание кода. Об этом заявил Рашед Хак (Rashed Haq), вице-президент GM по автономным автомобилям, в интервью на конференции VB Transform 2026. Остальные 85% времени уходят на анализ данных с автомобилей, триаж проблем, проведение экспериментов и тестирование потенциальных исправлений. GM использует AI-агентов, чтобы ускорить эту «невидимую» часть работы.

Результат, по словам Хака, — примерно трехкратное увеличение числа принятых (merged) pull request'ов в инженерной организации автономных автомобилей GM, более быстрые релизы и меньшее количество дефектов, попадающих на поздние стадии разработки.

02Инженеры тратят большую часть времени вне редактора кода

Цифра в 15% может показаться невероятно низкой, но исследования, проведенные до эры генеративного и агентного AI, приходили к схожим выводам. Исследование Microsoft 2019 года, основанное на ответах 5 971 профессионального разработчика, показало, что в хорошие рабочие дни они тратят на написание кода в среднем 96 минут, а в плохие — 66 минут. Это составляет примерно 20% и 14% восьмичасового рабочего дня соответственно. Опрос Stripe 2018 года выявил, что средний разработчик тратит более 17 часов в неделю на задачи по сопровождению кода, такие как отладка и рефакторинг.

Хак подчеркивает: задолго до появления агентов написание кода было лишь одной из составляющих разработки ПО. Ускорение только этого этапа оставляет нетронутой значительную часть процесса.

03Перепроектирование процессов вокруг агентов

GM добилась описанных результатов не просто добавлением AI-ассистента для написания кода, а полным перепроектированием инженерных процессов вокруг агентов. «Если вы дадите кому-то просто чат-бота, который умеет писать код, в этом процессе все равно останется много неэффективности», — отметил Хак.

Компания разделила работу над автономными автомобилями на несколько циклов (loops): разработка и тестирование ПО в симуляции, тестирование автомобилей на дорогах общего пользования и мониторинг автомобилей после передачи клиентам. Затем в каждом цикле находилось самое узкое место (bottleneck), которое автоматизировалось, и процесс повторялся.

«Выполнение работы по циклам стало очень важным», — пояснил Хак.

04Доступ к внутренним инструментам и данным

GM предоставила агентам доступ к внутренним инструментам и петабайтам корпоративных данных через кастомизированные серверы Model Context Protocol (MCP). Также были созданы версионированные «навыки» (skills) — инструкции, которые объясняют агентам, как выполнять конкретные задачи.

Одно из наиболее ценных применений — телеметрия, собираемая с автомобилей на дорогах. Агенты могут анализировать эти данные, проводить первичный триаж и создавать задачи для инженеров. Через MCP-соединения они также могут вызывать инструменты, лежащие в основе WebViz — системы GM для визуализации телеметрии, не используя тот же графический интерфейс, что и человек.

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

Права доступа агента соответствуют правам использующего его инженера. «Если инженер собирался выполнить эту задачу и ему нужен доступ к определенным вещам, то и его агенту нужен доступ к этим вещам, — сказал Хак. — Инженер по-прежнему несет ответственность за результат работы агента».

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

05Трехкратный рост pull request'ов и меньше дефектов

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

Хак отметил, что увеличение числа принятых pull request'ов означает не просто рост объема кода. «Увеличилась скорость, с которой мы выпускаем новые функции», — сказал он, добавив, что релизы стали давать «меньше утечек тестов, утечек багов» и других проблем.

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

Хак признался, что изначально в GM ожидали более скромного прироста производительности. «Нашим единственным сюрпризом было то, как много мы смогли сделать», — заключил он.

Подход GM не начинался с того, чтобы выдать каждому разработчику генератор кода. Он начался с картирования полного пути от обнаружения проблемы до верифицированного исправления в каждом цикле — симуляция, дорожные испытания, мониторинг после развертывания, — а затем предоставления агентам контролируемого доступа к инструментам и данным, необходимым для сокращения самого длинного узкого места на каждом этапе.