GM прискорила розробку AI-агентами

Чому 15% на код — не аномалія

Заява Рашеда Хака звучить різко лише на перший погляд. У джерелі її порівнюють із дослідженнями, які ще до хвилі генеративного ШІ показували: написання коду займає не всю роботу розробника, а лише її частину.

У дослідженні Microsoft 2019 року на основі відповідей 5 971 професійного розробника йшлося, що в хороші робочі дні вони в середньому писали код 96 хвилин, а в погані — 66 хвилин. Для восьмигодинного дня це приблизно 20% і 14%. Опитування Stripe 2018 року показувало понад 17 годин на тиждень на підтримку: debugging, refactoring та інші роботи поза новими фічами.

Водночас універсального бенчмарку немає: у попередніх дослідженнях частка кодування коливалася від 9% до 61% часу залежно від методики. Саме тому аргумент GM не в тому, що код став неважливим, а в тому, що автоматизація лише редактора коду не прибирає більшість затримок у процесі.

Що саме GM автоматизувала

GM описує підхід як перебудову робочих циклів навколо агентів. Компанія поділила роботу з автономним водінням на кілька контурів: розробка й тестування в симуляції, випробування авто на публічних дорогах, а також моніторинг після того, як машини доходять до клієнтів.

У кожному циклі команда шукала найдовше вузьке місце, автоматизувала його і повторювала процес. За словами Хака, це важливіше, ніж просто видати розробникам чатбот для написання коду: у такому випадку значна частина неефективності лишається поза увагою.

• Агенти аналізують телеметрію з авто на публічних дорогах.
• Вони роблять первинний тріаж і створюють issues для інженерів.
• Через MCP-з’єднання можуть викликати базові інструменти WebViz, системи GM для візуалізації телеметрії.
• Фонові агенти запускають ML-експерименти паралельно: інженер задає параметри, агенти виконують тести й збирають результати.

Дані, доступи й контроль

Агентів підключили до внутрішніх інструментів і петабайтів корпоративних даних через кастомізовані MCP-сервери. Окремо GM створила version-controlled “skills” — інструкційні документи, які описують, як агентам виконувати конкретні задачі.

Важлива умова — результат має бути зрозумілим людині. Агент може визначити потенційну проблему, локалізувати компонент, знайти схожі випадки в історичних даних і надати приклади, які підтримують його висновок. Але відповідальність лишається на інженері.

Права агента залежать від прав інженера, який ним користується. Хак сформулював це так: якщо інженеру для задачі потрібен доступ до певних речей, то і його агенту потрібен доступ до цих речей. Це не описано як самостійна система без людського контролю.

Практичне значення і що поки невідомо

Для бізнес-аудиторії головний висновок не в тому, що будь-якій компанії треба купити “AI-агентів для розробників”. У джерелі GM говорить про внутрішню платформу, підключену до власних даних, інструментів і процесів автономного водіння. Застосувати саме це рішення сьогодні поза GM джерело не пропонує.

GM також ставилася до внутрішньої агентної платформи як до продукту: чотири deployed engineers працювали безпосередньо з інженерними командами, допомагали знаходити корисні сценарії, поширювати практики й впроваджувати інструменти. За словами Хака, зростання merged pull requests означало не лише більший обсяг коду, а й швидший випуск нових функцій із меншою кількістю test escapes і bug escapes.

Невідомими лишаються зовнішня вартість, якщо така взагалі можлива, конкретні дати запуску всередині GM, точні метрики дефектів і релізів, а також те, як саме компанія вимірювала трикратне зростання pull requests. Джерело лише уточнює, що перед масштабуванням GM мала структуровані й неструктуровані тести та performance measurements, а інженери перевіряли, чи кожен тест досі вимірює те, для чого був створений.