GM tripled pull requests by redesigning engineering loops around AI agents
At VB Transform 2026, General Motors' autonomous driving division described a structured approach to AI agent adoption that led to roughly three times as many merged pull requests, faster releases, and fewer defects escaping into later stages of development. The claim comes from Rashed Haq, GM's VP of autonomous vehicles, speaking at a fireside chat. The number is self-reported and attributed to a single executive at one company, which limits what it tells the broader industry about agent-based engineering transformation.
The underlying productivity premise is not new. Haq cited a 2019 Microsoft study based on 5,971 professional developers that found roughly 14% to 20% of an eight-hour day spent writing code, alongside a 2018 Stripe survey reporting more than 17 hours per week on maintenance tasks. Those figures suggest that code writing was never the dominant activity in software engineering, a point the Microsoft researchers noted with a wide baseline range from 9% to 61% depending on how the work was defined. The GM case extends this pattern to an autonomous vehicle engineering context and adds an agent layer on top of it.
GM's approach started with mapping the development process into separate loops rather than applying agents uniformly. The loops cover simulation-based software testing, on-road vehicle testing, and post-deployment monitoring. For each loop, the team identified the longest bottleneck, automated it, and repeated the process. This loop-based redesign is where the GM case differs from simpler deployments of AI coding assistants. Haq framed it explicitly: giving engineers a chatbot that can write code still leaves inefficiency embedded in the surrounding process.
The technical implementation connects agents to internal infrastructure through customized Model Context Protocol servers. This gives agents access to petabytes of telemetry data collected from vehicles on public roads, the ability to conduct initial triage on that data, and the capacity to create issues for engineers to investigate. Agents can call the underlying tools behind GM's WebViz visualization system directly, bypassing the graphical interface a human would use. The output requirement is human readability: agents identify potential problems, locate affected components, search historical data for similar incidents, and provide supporting examples.
The permission model ties agent access to the engineer's own permissions. If an engineer would need access to certain systems or data to perform a task manually, the agent working on their behalf receives the same access. Haq described this as an accountability structure: the engineer remains responsible for the agent's output. Beyond triage and analysis, GM uses background agents to run machine-learning experiments in parallel, with engineers defining parameters and agents executing tests and collecting results.
The internal agent platform was treated as a product, with four deployed engineers assigned to work directly alongside engineering teams. Their role was to identify useful workflows, document what worked, and support adoption. Haq said the initial expectation was for more modest gains. The surprise, he said, was how much the organization could accomplish.
The 3x pull request figure describes a productivity metric in a specific engineering organization. The source does not independently verify this number, does not disclose the baseline period or measurement methodology, and does not provide comparable data from comparable organizations running different approaches. The defects-escape reduction is similarly self-reported. Both metrics address code throughput and early-stage quality control. Neither metric speaks to architectural outcomes, long-term code maintainability, or whether the agent-assisted workflow introduced new failure modes that would not show up in those measurements.