General Motors Innovation & Technology Culture

It’s an exciting time to be working in automotive, as transportation goes through a transformative period across electrification, autonomy and software. With GM, there’s a huge opportunity to get the chance to scale work across brands — which includes a broad portfolio of EVs — and develop new technologies. 

How has a focus on innovation increased the quality of your team’s work? 

To me, innovation means a willingness to take big risks, move forward without having every answer and course-correct effectively along the way. Without these innovation-driven processes, it would be easy to miss opportunities or spend months spinning without action.

One great example is how we’re integrating Cruise and GM technologies. In a very short time, the team leaned into knowledge-sharing sessions, explored multiple paths through proof-of-concepts and relied heavily on the RFC process to document ideas, gather feedback and iterate quickly. These practices kept us out of silos, helped us avoid over-planning and allowed us to move quickly without losing alignment.

This approach led to immediate wins, like connecting GM’s highway data to new infrastructure, and opened up potential like using an onboard mining strategy to capture rare events by leveraging GM’s large vehicle fleet. Both instances fill important gaps where we historically lacked coverage. These initiatives are still ongoing, and I’m excited about the momentum and possibilities they’re bringing.
 

GM employees describe software work as fast-moving, with teams expected to adapt, learn and iterate quickly.

“The pace of change is fast in the tech world. The cost of standing still is high. Whether it’s adopting new tools, iterating faster, or learning a new skill, we need to be nimble. As software takes center stage in modern vehicles, moving fast isn’t just a goal: it’s how we stay ahead.”

Engineers at GM describe working across legacy systems and newer technologies as software-defined vehicle development continues to evolve.

“You have to know the rulebook inside and out: what to keep, what to rewrite, and what to toss entirely,” he explains. “That balance between innovation and accountability is what makes the work exciting.”
 

Employees working on advanced technologies describe a culture that embraces change, digital tools, and new ways of working to stay competitive in a rapidly evolving automotive landscape.

“Innovation isn’t just about new features in a car. It’s about how fast we’re willing to change. At GM, we’ve built a culture where digital tools, bold pivots, and a readiness to chase opportunity keep us moving ahead of the curve.” 

From a product standpoint, the technology we’re developing keeps evolving. With every new vehicle program, there’s something new to learn and new challenges to solve. That keeps things fresh and exciting.

How is AI changing how your teams build products, solve problems or get work done?

Artificial intelligence is rapidly reshaping software development, but vehicle programs demand more than fast output. In a software-defined vehicle, speed only matters when the resulting software remains readable, testable, maintainable and reviewable inside a tightly controlled engineering process.

GM teams used that lens in a broader research effort across the software development lifecycle. The question was not whether AI could generate code, but where it could reduce friction without weakening the discipline production software requires. Across very different kinds of engineering work, the same pattern emerged: AI is most useful when it works inside a structured engineering loop and produces bounded first drafts that engineers can verify.

Across that lifecycle, GM’s work kept returning to the same question: Where can AI remove friction while keeping engineering judgment firmly in control?

How does your team use AI while maintaining quality, reliability and human judgment?

The difficulty is that automotive software cannot tolerate casual use of AI. A test artifact can miss the intent of a requirement. A cleaned-up embedded C function can still break logic, violate Motor Industry Software Reliability Association coding standards or fail to compile when returned to its module. The central question is not simply whether a model can produce output, but whether that output can withstand engineering scrutiny.

One of the clearest findings from the research was that outcomes depended less on the AI model itself than on how tightly the task was defined around it. When the model was given a narrow, well-scoped task, its output could be checked against a known expectation. When the scope was left open, quality became less reliable. That led to a basic rule for the work — every AI interaction had to be bounded tightly enough that the reviewing engineer could tell whether the result was correct. For real-time compliance guidance, that meant turning experienced-developer knowledge into explicit checking patterns so that each recommendation could be reviewed on its own merits rather than accepted on the model’s judgment alone — the idea behind the Intelligent Virtual Advisor.

The research also exposed clear limits. Larger models often performed better overall, but training also affected outcomes even among models sharing the same architecture. Logical issues in generated code still required human review. Fine-tuning also helped, but compliant code must be selected carefully. Context-window constraints were also a factor, as quality degraded with input size, making segmentation and review essential.

How does your team identify what could move faster or be built better?

GM research followed the friction — the points in the lifecycle where engineers consistently lose time. That friction commonly appears during active development when general-purpose tools lack the domain knowledge to surface violations as they are introduced, leaving issues to accumulate until formal review catches them. It also appears in maintenance, where legacy code carries years of implicit assumptions that make modernization slow and make large, embedded functions expensive to refactor manually. In these areas, the research applied LLM-based methods to produce bounded first drafts that engineers could evaluate and refine, rather than author from nothing.

The need for bounded, reviewable progress becomes clearer in the workflows themselves. Requirements and behavioral intent are carried forward into test cases, then scripts, then executed checks, with engineers reviewing each handoff, so traceability is preserved.

How has AI impacted the workflows on your team?

AI delivers its most practical value in automotive software when it helps engineers catch issues earlier, start difficult work faster and keep reviewable progress moving through the development lifecycle. It shortens the time between introducing a problem and catching it, surfacing quality violations during coding instead of at formal review. Even high-friction work becomes easier to start when AI provides a first draft. Together, these gains reduce friction where engineers lose time across the lifecycle.

That pattern also appears in the measured and observed results. When the work was kept narrow enough to review, smaller-scope refactoring reduced cyclomatic complexity (a standard measure of function complexity) by about 30 percent, validation work pointed toward a more scalable requirement-to-script workflow and expert guidance systems such as Intelligent Virtual Assistants were able to improve the quality of support without moving approval out of engineers’ hands. None of that removes accountability from engineers. AI accelerates the path to a candidate; engineers decide what clears the bar.