Most software engineers spend the vast majority of their day doing everything except writing code. The modern development cycle is often a grueling marathon of digging through logs, triaging bugs, analyzing telemetry, and waiting for simulation results to return. While the industry has obsessed over AI coding assistants that autocomplete functions, the actual friction of engineering remains buried in the operational overhead that surrounds the IDE. This gap between writing a line of code and actually shipping a verified fix is where the real productivity battle is fought.
The Architecture of Autonomous Engineering
At GM's autonomous driving division, this friction was quantified into a stark reality. Rashed Haq, Vice President of the division, revealed that engineers spend only 15% of their total working time actually writing code. The remaining 85% is consumed by the surrounding ecosystem: analyzing massive volumes of vehicle data, triaging complex issues, running experiments, and testing subsequent fixes. To tackle this imbalance, GM did not simply add a chatbot to the developer's toolkit; they fundamentally redesigned the engineering workflow to be agent-centric.
This redesign targets three primary operational loops that define autonomous vehicle development. The first is the software development and testing loop within simulations. The second is the real-world testing loop involving vehicles on public roads. The third is the post-delivery monitoring loop that tracks vehicle performance after they reach the customer. By identifying the most severe bottlenecks in each of these loops and applying targeted automation, GM transformed its delivery pipeline. The result was a dramatic increase in velocity, with the number of merged pull requests across the autonomous engineering organization increasing approximately threefold.
To ensure this wasn't just a fragmented experiment, GM treated its internal agent platform as a standalone product. They deployed a dedicated team of four engineers whose sole mission was to collaborate with active development teams. This team worked to identify high-impact workflows, propagate success stories across the organization, and provide the necessary support for tool adoption. This structured approach allowed GM to accelerate release cycles while simultaneously reducing the number of defects that leaked into the later stages of the development pipeline.
Beyond the Chatbot: The MCP Integration
The fundamental difference between a coding assistant and an AI agent workflow lies in the scope of the problem being solved. While a chatbot accelerates the act of typing code, an agent-based workflow shortens the entire path from problem discovery to verified resolution. The technical backbone of this system is the Model Context Protocol (MCP). GM built custom MCP servers that allow AI agents to directly interface with internal tools and access petabytes of proprietary corporate data.
Rather than relying on static prompts, the agents operate based on version-controlled instruction documents known as skills. These skills define exactly how an agent should execute specific tasks, ensuring consistency and reliability across the organization. For example, when processing telemetry data collected from public roads, an agent does not simply summarize a text file. It analyzes the data, performs an initial triage, and generates a specific issue for an engineer to investigate. To do this, the agent bypasses the traditional graphical user interface and directly calls the underlying tools of WebViz, GM's vehicle telemetry visualization system, via the MCP connection.
This capability extends into the machine learning pipeline through background agents that execute experiments in parallel. An engineer defines the objective and the parameters of an experiment, and the agent handles the execution and result collection. To maintain security and governance, GM implemented a strict permission mirroring system. An agent's access rights are identical to those of the engineer operating it. If an engineer lacks permission to access a specific dataset or tool, the agent is similarly restricted. This ensures that while the agent handles the labor, the human engineer retains full accountability for every output.
To prevent this increase in speed from compromising safety or quality, GM established a rigorous framework of structured and unstructured tests alongside precise performance metrics. Every agent-generated output must be human-readable, providing not just a conclusion but the evidence to support it. When an agent identifies a potential problem, it is required to locate the affected components and search for similar historical cases to provide a reasoned justification for its findings. Engineers then review these findings to ensure the tests are still capturing the intended goals before deciding whether a task can move into production.
For organizations looking to implement similar systems, the lesson from GM is that the performance of the LLM is secondary to the mapping of the workflow. The goal is not to generate more code, but to optimize the entire trajectory from the moment a bug is detected to the moment a fix is verified. This requires a data-driven identification of bottlenecks across simulation, road testing, and monitoring, coupled with a standardized protocol like MCP to provide controlled access to the necessary tools.
