Software engineers in General Motors’ autonomous vehicle division now spend roughly 15% of their time writing code, Rashed Haq, GM’s VP of autonomous vehicles, said during a main-stage interview at VB Transform 2026. GM uses AI agents to accelerate much of the remaining 85% of engineering work, including vehicle-data analysis, problem triage, running experiments and testing fixes.
Outcomes: more merges, faster releases, fewer escaped defects
According to Haq, introducing agents and redesigning workflows around them led to about three times as many merged pull requests across GM’s autonomous vehicle engineering organization. He said releases are faster and produce fewer test escapes and bug escapes.
Not just a coding assistant: workflow redesign
GM did not begin by handing developers code generators. Instead, the company mapped the full path from problem discovery to verified fix across three development loops — simulation, road testing and post-deployment monitoring — then identified the longest bottleneck in each loop, automated it and iterated. Haq argued that merely giving engineers a chatbot that can write code leaves many inefficiencies in the broader process.
Agents connected to internal tools and large datasets
GM connected agents to internal tools and petabytes of company data via customized Model Context Protocol (MCP) servers. The company also created version-controlled "skills," instruction documents that tell agents how to perform specific tasks.
A high-value use case is telemetry from vehicles on public roads: agents can analyze that telemetry, perform an initial triage and create issues for engineers. Through MCP connections, agents can call the underlying tools used by WebViz (GM’s telemetry visualization system) rather than relying on the graphical interface a person would use.
Human-readability, permissions and accountability
Haq emphasized that agent outputs must be human readable: an agent might identify a potential problem, locate the affected component, search historical data for similar incidents and provide examples to support its conclusion. Agents’ permissions are aligned with the permissions of the engineer using them — if an engineer needs access to certain tools to perform a task, their agent needs those accesses as well. The engineer remains accountable for the agent’s output.
Parallel experiments and productized platform support
GM also uses background agents to run machine-learning experiments in parallel: an engineer defines an experiment and its parameters, and agents execute tests and collect results. The internal agent platform was treated as a product, with four deployed engineers assigned to work directly with engineering teams to identify useful workflows, spread successful practices and assist adoption.
Measurements, controls and surprises
GM established structured and unstructured tests and performance measurements before accelerating broader workflows. Engineers review those metrics and decide whether each test still captures its intended goal before work progresses toward production. Haq said GM initially expected more modest productivity gains and that the company was surprised by how much it could accomplish.
Why speeding only coding is insufficient
The company’s 15% figure aligns with prior research indicating coding comprises a small portion of developers’ work. A 2019 Microsoft study of 5,971 professional developers found average coding time of 96 minutes on good workdays and 66 minutes on bad ones (about 20% and 14% of an eight-hour day, respectively). A 2018 Stripe survey reported the average developer spent over 17 hours per week on maintenance tasks such as debugging and refactoring. These findings support Haq’s point that accelerating code-writing alone leaves much of the software development process untouched.
Summary
GM’s approach was to map end-to-end workflows in each development loop and give agents controlled access to the tools and data needed to shorten the longest bottlenecks. That targeted automation — not simply providing code-generation assistants — produced approximately three times more merged pull requests, faster feature releases and fewer defects escaping into later stages of development.
