By Arun Adiththan, Senior Researcher on GM’s R&D team and Daniel Struck, Software Architect on GM’s VMEC embedded software team
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 life cycle. 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.
The V-model is a useful way to view that work because the opportunity spans the full software life cycle, from early development decisions through verification and long-term maintenance. Across that life cycle, GM’s work kept returning to the same question: where can AI remove friction while keeping engineering judgment firmly in control?
Challenges and opportunities
Automotive software is a promising domain for AI because the work is complex, contains recurring engineering tasks, and is growing in scale. Teams manage large codebases, specialized toolchains, demanding quality expectations, and software that evolves as vehicle capabilities expand.
Research has found that automotive software complexity has grown faster than productivity [1]. That imbalance creates real pressure to move faster without compromising rigor. 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 MISRA (Motor Industry Software Reliability Association) coding standards [5], 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.
High-level description of the solutions
GM research followed the friction – the points in the lifec ycle 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 large language model (LLM)-based methods to produce bounded first drafts that engineers could evaluate and refine, rather than author from nothing.
Figure 2: AI-assisted test automation carries requirements and behavioral intent into test-case generation, script drafting, execution, and feedback, with engineers reviewing each generative stage.
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.
Figure 3: The refactoring prompt methodology is organized around five elements: framework, regulation, templates, sequence, and iteration.
That same insistence on bounded, reviewable progress also shaped code improvement work, where structured prompt sequencing kept each pass narrow enough for engineers to inspect before moving forward [3].
Details of solutions
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 (IVA) [2].
The same principle shaped the other workflows. In refactoring, separating structural cleanup from readability improvements through prompt chaining made each pass easier to review and reduced the chance that later edits would quietly undo earlier decisions [3]. In script automation, structured prompting made translation from legacy Perl utilities to Python more reviewable than a one-shot rewrite [3]. In validation, explicit guidance on format, coverage, and level of abstraction during test-case generation helped preserve traceability from requirement to executed test and prevented weak structure from carrying into downstream automation. The technique varied by use case, but the principle of keeping each step narrow enough to verify did not.
Context quality mattered just as much as scope. Standards paired with compliant and non-compliant examples produced better checking patterns than prose alone [2]. Few-shot examples guided output format more reliably than instructions by themselves [3]. For embedded software refactoring, pre-computed summaries of inter-function dependencies helped preserve consistency when the full codebase could not fit into the model context [3]. Better framing consistently produced better candidates.
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 [4]. Fine-tuning also helped, but compliant code must be selected carefully [3,4]. Context-window constraints were also a factor, as quality degraded with input size, making segmentation and review essential [3].
Impact on GM
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 life cycle. 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 life cycle.
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 [6]) by about 30 percent [3], validation work pointed toward a more scalable requirement-to-script workflow, and expert guidance systems such as IVA [2] 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.
Conclusions
The most useful way to understand AI in automotive software development is not as a substitute for engineering judgment, but as a way to amplify and extend it. Across this research, AI delivered the most value when it handled bounded, context-rich tasks such as refactoring embedded code, surfacing compliance issues, translating legacy scripts, and generating test artifacts that made progress visible while leaving verification, refinement, and approval in human hands.
The power of AI, then, is not simply that it can generate more output in less time. It is that, when used inside a disciplined engineering workflow, it can help teams catch issues earlier, reduce the cost of starting complex tasks, and preserve a clearer line between requirements, implementation, validation, and review.
Looking ahead, that model of use suggests a path toward software organizations that scale expertise more effectively, embed quality checks earlier in development, and make high-friction work more repeatable without lowering standards. If that happens, AI will matter less as a code generator and more as engineering infrastructure. It can serve as a practical layer of assistance that helps experienced teams move faster while keeping human judgment, technical evidence, and final responsibility firmly in place.
In automotive development, that is the combination that makes AI not just interesting, but durable and worth adopting.
References [1] McKinsey & Company, “When Code is King: Mastering Automotive Software Excellence,” accessed Oct. 2025. [2] Warmsley, D., Robert Genslak, and Paolo Giusto, “Intelligent Virtual Advisor for Software Development,” ICICT, 2025. [3] Robert Genslak, James Nicholson, Daniel Struck, Arun Adiththan, Paolo Giusto, Steven Miller, Fabian Benitez-Quiroz, and Octavi Obiols-Sales, “Large language model-based solutions for automotive software quality improvements: challenges and opportunities,” FISITA, 2025. [4] Struck, D. and Kumaraswamy, S., “Open Source LLM Performance in Automating Embedded C Software Quality Improvements for Automotive,” SAE Technical Paper 2026-01-01. [5] The MISRA Consortium, Limited, “MISRA,” [Online]. Available: https://misra.org.uk/. [6] “A Complexity Measure,” IEEE Transactions on Software Engineering, vol. SE-2, no. 4, pp. 308–320, Dec. 1976
SD Times Q&A
How is GM using AI in automotive software development?
GM is applying large language model (LLM)-based methods across the software development life cycle to reduce engineering friction. Specific use cases include real-time MISRA compliance guidance via an Intelligent Virtual Advisor (IVA), refactoring embedded C code, translating legacy Perl scripts to Python, and generating test artifacts from requirements. In each case, AI produces bounded first drafts that engineers review and approve.
Can AI-generated code meet MISRA coding standards for automotive software?
AI-generated code cannot be assumed to meet MISRA standards without engineer review. GM’s research found that even cleaned-up embedded C functions can violate MISRA rules, break logic, or fail to compile in context. Their approach uses structured prompting and explicit compliance checking patterns to flag potential violations, but human engineers retain final approval authority.
What is a software-defined vehicle (SDV) and why does it complicate software quality?
A software-defined vehicle (SDV) is one in which core vehicle features and behaviors are controlled and updated through software rather than fixed hardware. This increases software scale and complexity significantly, with research indicating automotive software complexity has grown faster than developer productivity. Teams must manage large, evolving codebases under strict safety and quality standards such as MISRA.
What impact did AI-assisted refactoring have on code complexity at GM?
GM’s research found that narrow-scope, AI-assisted refactoring reduced cyclomatic complexity — a standard measure of function complexity — by approximately 30 percent. The approach used structured prompt chaining to separate structural cleanup from readability improvements, keeping each pass small enough for engineers to inspect individually.
What are the limits of using LLMs for embedded automotive software?
GM’s research identified several key limitations: larger models generally performed better but training data quality also affected outcomes significantly; logical errors in generated code still required human review; fine-tuning required careful selection of compliant code examples; and context-window size degraded output quality, making input segmentation and staged review essential for large codebases.
