The 15% Reality of Software Engineering
Software engineers at General Motors' autonomous driving division spend only 15% of their working hours writing code. That single data point, shared by Rashed Haq—GM’s Vice President of Autonomous Vehicles—at the VB Transform 2026 conference, cuts right through the hype surrounding AI coding assistants.
If developers spend 85% of their week on tasks outside the code editor, speeding up syntax typing inside an IDE barely moves the needle for enterprise productivity. At GM's autonomous vehicle unit, engineers spent the vast majority of their time analyzing vehicle telemetry, triaging edge cases, running software-in-the-loop simulations, and validating safety fixes.
That distribution of effort isn't unique to autonomous vehicles. A 2019 Microsoft research study examining 5,971 professional developers revealed that engineers spent an average of 96 minutes (roughly 20%) writing code on good workdays, and just 66 minutes (14%) on bad ones. Similarly, a 2018 Stripe developer report found that software developers spent over 17 hours every week managing technical debt, debugging legacy code, and handling routine maintenance. Across historical industry studies, active coding time spans anywhere from 9% to 61% depending on how researchers define the work. But the underlying reality remains consistent: writing new lines of code is only a fraction of software engineering.
By recognizing this operational reality, GM stopped treating AI as just an inline coding assistant and instead redesigned its end-to-end engineering workflows around autonomous AI agents (see our analysis on retooling software workflows for AI agents). The payoff was immediate: GM roughly tripled its volume of merged pull requests, accelerated feature deployment, and reduced defect escapes reaching later development stages.
Why Coding Chatbots Leave Enterprise Bottlenecks Untouched
Handing a software team an AI autocomplete extension or a standalone coding chatbot feels like an easy win, but it leaves fundamental organizational bottlenecks untouched. Chatbots excel at localized code generation—writing boilerplate, refactoring isolated functions, or answering syntax questions. Yet they remain reactive tools bound to an individual developer's active editor session.
"If you give somebody just a chatbot which can do coding, there’s still a lot of inefficiency built into that process," Haq explained during a fireside chat with VentureBeat's Carl Franzen at Hotel Nia in Menlo Park.
When an autonomous vehicle fails a road test or triggers an anomaly in simulation, writing the code fix is often the shortest step. The real delay stems from searching petabytes of sensor data, reproducing the hardware-in-the-loop state, cross-referencing historical incident patterns, and coordinating multi-system regression runs. A chatbot sitting in an IDE window can't autonomously trigger external diagnostic pipelines, parse raw telemetry logs, or execute parallel experiment matrices across cloud compute clusters.
Accelerating code editing while leaving manual triage and testing pipelines untouched simply pushes work faster into downstream bottlenecks. Real velocity gains require operational systems that address the entire software lifecycle. That demands shifting from passive assistants to active agentic workflows that interface directly with enterprise infrastructure.
Mapping the Loops: How GM Isolated Operational Bottlenecks
To systematically tackle non-coding overhead, GM divided its autonomous vehicle engineering operations into three core operational loops:
- The Simulation Loop: Software-in-the-loop and hardware-in-the-loop virtual testing environments where vehicle algorithms face simulated edge cases.
- The Road-Testing Loop: Physical fleet operations on public roads gathering real-world sensor streams and performance telemetry.
- The Post-Deployment Monitoring Loop: Fleet telemetry tracking, error logging, and post-release diagnostic analysis.
Rather than trying to automate everything at once, GM targeted the single longest bottleneck within each operational loop. As Haq noted, "doing it by loop became really important." Once the team automated the primary constraint in a loop using AI agents, they measured the throughput shift, identified the new bottleneck, and repeated the cycle.
For instance, machine learning model optimization frequently stalled while engineers manually configured and monitored training runs. GM deployed background AI agents to run ML experiments in parallel. An engineer defines the overarching hypothesis and parameters; the agents then execute the matrix of test runs, gather performance metrics, summarize failure modes, and format experimental results automatically.
By converting sequential human testing into parallel agentic execution, GM transformed slow multi-day feedback loops into rapid automated cycles.
Connecting Agents to Enterprise Systems via Custom MCP Servers
Granting agents real operational autonomy requires robust system integration. GM connected its AI agents to internal tools, proprietary databases, and petabytes of vehicle telemetry using customized Model Context Protocol (MCP) servers.
MCP provides a standardized protocol allowing LLM-based agents to discover internal tools, query telemetry stores, and invoke system commands securely, acting as critical connective tissue alongside enterprise agentic data platforms. Alongside MCP integration, GM created version-controlled "skills"—structured instruction manifests that specify exactly how agents should execute complex, multi-step tasks.
Consider how GM processes fleet telemetry collected from public road testing:
- Telemetry Ingestion & Triage: When test vehicles encounter unexpected maneuvers or system exceptions, raw sensor logs stream into GM's backend stores. Specialized agents monitor these streams, perform initial failure triage, and draft structured issue reports for engineers to review.
- Direct API Execution: Rather than navigating graphical user interfaces like WebViz—GM’s internal telemetry visualization platform—agents call backend WebViz APIs directly via MCP connections. They extract raw telemetry coordinates, slice relevant video frames, and cross-reference sensor logs without human UI overhead.
- Human-Readable Syntheses: Agents don't dump raw diagnostic payloads on engineers. As Haq emphasized, "the output has to be human readable." An agent triaging an anomaly pinpoints the suspected faulty software component, searches historical databases for matching error patterns, and compiles a clear diagnostic package with supporting evidence.
This architecture eliminates hours of manual investigation before a developer ever opens a code editor.
Security Boundaries, Human Accountability, and Rollout Strategy
Deploying autonomous agents across safety-critical autonomous vehicle codebases introduces real risk if permissions and governance aren't tightly controlled. GM managed these risks—addressing central challenges in governing agent identities—by establishing clear authorization models, strict human accountability, and a hands-on internal rollout strategy.
Identity Mirroring and Least Privilege
GM enforced a strict security rule: an agent's access rights must mirror the exact permissions of the engineer using it. "If an engineer was going to do this task and they need access to these things, then their agent needs access to those things," Haq explained. An agent cannot access sensitive telemetry datasets, run elevated system commands, or touch restricted repositories unless its human user holds explicit authorization.
Furthermore, accountability remains squarely on the human operator. The engineer operating an agent owns every line of code, configuration update, and issue summary the agent produces.
Dedicated Platform Champions
Rather than tossing new agentic tools over the wall to engineering teams, GM treated its internal agent platform as a dedicated product. The company assigned four deployed platform engineers directly to work alongside autonomous vehicle units. These champions helped teams identify workflow friction, build custom MCP skills, share effective patterns across departments, and drive tool adoption.
Rigorous Safety Gates
Speed means nothing if safety breaks. GM established comprehensive structured and unstructured test suites alongside performance baselines long before scaling agentic automation. Engineers review these baselines at defined control points, verifying that test suites accurately validate safety objectives before code advances toward production deployment.
What GM's 3x PR Surge Teaches Autonomous Engineering Teams
GM’s transition to agentic workflows yielded results that surpassed internal expectations. "I think our only surprise was how much we could do," Haq admitted. Tripling merged pull requests while simultaneously reducing downstream bug escapes demonstrates that AI productivity gains aren't limited to synthetic coding benchmarks.
For engineering leaders and platform architects building agentic infrastructure, GM’s experience offers several clear takeaways:
- Look Beyond Code Generation: Stop measuring developer productivity solely by lines of code written. The biggest enterprise gains lie in automating triage, simulation, telemetry analysis, and environment setup.
- Standardize Integrations via MCP: Connect agents to internal systems through explicit API protocols and version-controlled skills. Direct backend access beats visual interface scraping every time.
- Target Bottlenecks Iteratively: Map operational loops end-to-end, eliminate the single slowest manual step, measure the result, and repeat.
- Embed Dedicated Platform Engineers: Software tooling alone doesn't change habits. Deployed platform engineers ensure development teams adapt their workflows to leverage agentic capabilities effectively.
By shifting focus from isolated code completion to full-loop workflow orchestration, enterprise engineering teams can unlock massive velocity improvements without compromising system quality or safety.
