The Millionth Button Press: What AI
Should Actually Do for Automotive
Validation

In November 2024, General Motors described the scale of its software validation operation. In one Michigan facility alone, GM said more than 300 test benches were dedicated to dashboard infotainment. According to GM, AI was running software tests around the clock, automated testing simulated millions of button pushes and screen taps, and machine-learning-powered testing continued even while test vehicles were parked overnight.

In 2025, GM service bulletin PIT6362D described a broad range of infotainment symptoms across multiple vehicle lines: black screens, crashes, audio issues, camera problems, connectivity failures and display issues. GM said the concerns may be caused by software anomalies and that it was working on software improvements. Dealers were instructed not to replace a long list of hardware components and, where practical, to encourage customers to wait for updated software.

This is not a story about an automaker that doesn't test enough. And it doesn't prove GM's validation failed. Public information doesn't tell us what its testing was designed to catch, or the root causes behind the symptoms in the bulletin. Many infotainment issues can originate in integration, configuration, supplier software or changes in the wider phone and software ecosystem.

It raises a harder question: If validation can already operate at this scale, is generating even more tests really the most interesting problem for AI to solve?

My answer: no.

Test generation is useful. But it may be the least interesting thing AI can do for automotive validation.

I've seen why first-hand. In one automotive program, 251 customer-reported black-screen incidents were still open after two task-force teams had spent three months investigating them. What finally revealed the problem wasn't another functional test. More on that below.

AI is accelerating software development, but faster development does not automatically translate into more stable software. Google's 2025 DORA research, based on survey responses from nearly 5,000 technology professionals, found that AI adoption continued to have a negative relationship with software delivery stability. DORA's interpretation is particularly relevant here: AI accelerates software development, but that acceleration can expose weaknesses downstream.

The research itself describes AI primarily as an amplifier: it magnifies what is already working well — and the dysfunctions that are already there.

In automotive, Perforce's 2026 State of Automotive Software Development research, conducted with Automotive IQ and the Eclipse Foundation, found that verifying and validating software was again the most time-consuming development activity, cited by 44% of respondents.

At the same time, AI may change more than the speed at which software is produced. A 2025 IEEE ISSRE study comparing more than 500,000 human- and AI-generated code samples found clear differences in their defect profiles. A separate 2026 preprint, accepted for publication at IEEE ISSRE 2026, analyzed 86,726 erroneous LLM-generated code samples and found recurring weaknesses including omitted input validation and memory-safety checks, with potential consequences ranging from resource exhaustion to reliability and security problems.

These are not automotive embedded-software studies, and they do not prove that AI-generated code is inherently less reliable. But they raise a reasonable question: If the way we create software changes, why should we assume that the failure modes will remain the same?

So there are two pressures at once: software can be created faster, and the characteristics of that software may also change. Naturally, AI is now being applied to testing too.

A 2026 Mercedes-Benz research project, Req2Road, explored a generative-AI pipeline that transformed natural-language requirements into executable automotive test scenarios and ran them in both simulation and a real vehicle. Of 36 requirements, 32 (89%) were successfully transformed into executable scenarios. The researchers also concluded that human review remained necessary.

AI is moving beyond generating tests as well. A 2026 preprint on ARIA, developed by researchers from Critical TechWorks, BMW's software joint venture, and the University of Porto, explored LLM agents executing tests through the user interface of an Android-based automotive infotainment system. Across 30 scenarios, the system identified all five known defects — but also produced eight false positives. If AI can turn requirements into tests faster, execute them more intelligently and remove repetitive engineering work, we should use it. But there is a distinction worth making: more validation is not automatically better validation.

The automotive industry does not lack tests. Modern programs already use requirements-based functional testing, HIL and SIL environments, endurance and soak testing, stress and robustness testing, fault injection, telemetry, fuzzing and many other techniques. Yet, as I wrote when revisiting automotive infotainment quality one year after our 2025 study, many of the symptoms reaching customers remain remarkably familiar: black screens, frozen interfaces, connectivity failures, camera problems, audio issues, restarts and degraded responsiveness. Some are ordinary functional, configuration or integration defects. But at least some of the hardest failures have another characteristic: they depend on time, state, resources and interactions.

When we were given access to the test bench, the incidents had been open for months. Within 24 hours, we had identified five root causes: memory leaks in five system applications. Over time, those leaks created increasing memory pressure until the operating system's out-of-memory mechanism killed the home launcher. What the customer saw was a black screen. The useful engineering signals had started appearing much earlier.

The difference wasn't smarter engineers. It was a different way of looking at the system. Instead of treating each visible failure as an isolated event, we were looking at how the complete running system behaved over time. This was not an untested prototype. The systems reaching the field had already gone through extensive automotive validation. The screen could work, the application could work and the test could pass while the conditions for a future black screen were gradually developing underneath.

In that case, careful observation was enough — once someone was looking at the right signals. The harder question is how to find signals like these systematically: earlier, before the field does, and across far more interactions and system states than any engineer can watch. This is where AI can become more valuable than simply generating another predefined test case.

Consider a long-running validation system operating on real target hardware. It executes realistic user and vehicle actions for hours or days while continuously observing the product — not only whether a test passed, but what happened to memory and responsiveness, which processes restarted, which sequences preceded unusual behaviour and whether today's system behaves differently from yesterday's.

Now imagine that the validation system does not simply record an anomaly. It reacts to it. A resource trend begins to look suspicious, so the system exercises the related functionality more aggressively. The signal strengthens. It changes the sequence, and the behaviour disappears. It restores the earlier conditions, and the behaviour returns. The validation process is no longer only executing a predefined script. It is investigating. The loop becomes: observe → form a hypothesis → change execution → observe again.

In the black-screen case above, the valuable observation was not merely that the screen eventually failed. The system was already telling a story before that happened: memory was being consumed, pressure was building and the eventual visible failure had precursors. A validation system capable of recognizing those signals and adapting its execution could begin investigating the problem before the final symptom appears.

Fuzzing has long used feedback such as code coverage and crashes to guide the generation of new inputs. Search-based testing follows the same broad principle: use information from previous execution to decide what to try next.

AI-driven test execution itself is no longer hypothetical either. The ARIA research above shows agents already interacting with an automotive infotainment system and evaluating the results. Its eight false positives are also a useful reminder that autonomous execution is only part of the problem: finding more suspicious behaviour is not particularly helpful if engineers simply inherit a larger triage queue.

GM's own public description likewise makes clear that machine learning is already part of its validation operation. What it does not tell us is whether observations of the running product dynamically influence which actions the system chooses to execute next.

I'm not proposing feedback-driven testing as a new invention. I'm arguing for a direction: using the behaviour of the complete running product itself as feedback for what validation should investigate next. Instead of primarily asking “What code haven't we exercised?”, the validation loop can also
ask: “What is changing in the behaviour of the complete product?” That can mean following gradual changes in resources, timing, responsiveness and subsystem behaviour over hours or days on real target hardware — and using those observations to decide what to investigate next.

Not every part of that loop requires AI. Rules and heuristics can identify many trends perfectly well. AI earns its place when the system needs to model normal multidimensional behaviour, connect weak signals, form hypotheses about what may be related, prioritise what matters and decide what action would be most useful next. That creates difficult engineering problems of its own. What is normal behaviour, and how do we avoid chasing harmless variation? How do we make unusual behaviour reproducible enough for an engineer to debug? How do we observe enough of the system — often across supplier boundaries — without changing its behaviour? And how do we turn more findings into fewer, better-prioritised problems rather than a longer triage queue?

None of this replaces functional testing, requirements validation, HIL, SIL, compatibility testing, fuzzing, endurance testing or human engineering judgement. It adds another layer to them.

Traditional validation asks a question we absolutely need answered: Did the product do what we expected?

Adaptive behavioural validation adds another: What is the product doing that we never thought to ask about?

Which brings us back to GM's millions of automated button pushes and screen taps. The next frontier may not be pressing the button another million times. It may be noticing that something changed on press 783,421 — and deciding what to press next.

That leaves automotive validation teams with a different set of questions. Does a long-running test change its behaviour based on what it observes? Are we looking at how the system evolves over time, or mainly whether individual tests pass? And when something unusual emerges after hours or days, can the validation environment actively pursue it until the behaviour becomes reproducible?

Because if we simply accelerate the validation process we already have, we also accelerate its blind spots.