SDV is not a future scenario; it is already a reality. Consolidating compute and reducing ECU count made the hardware simpler, but the software significantly more complex: one platform serving multiple vehicle lines, regions, and feature sets simultaneously. Validation challenges have increased dramatically as a result, making testing for software-defined vehicles one of the most critical engineering disciplines in modern automotive development.
Two more pressures compound this. The way consumers judge vehicle quality has shifted – less about horsepower and body style, more about UI experience, connectivity with mobile devices, and how the car interacts with you. And OTA updates have changed the release cycles: where programs once delivered annually, quarterly is now the baseline, with monthly and weekly releases on the horizon.
AI is a real part of the answer. But deploying AI in automotive testing context is not the same as deploying it elsewhere. Automotive software has audit obligations, functional safety requirements, and compliance frameworks that do not tolerate black-box outputs. What we needed was not just AI assistance; it was AI assistance that produces artifacts an engineer can review, sign off on, and hand to an auditor.
This article outlines our response to these challenges: a software development factory approach for AI in automotive software testing. We will walk through the workflow we built at Intellias, the decisions behind it, and the places where reality differed from the plan.
Three things that have to work together
Agentic AI testing tools alone do not solve the validation problem. Our approach rests on three pillars.
- The first is domain expertise: engineers who understand the automotive context deeply enough to evaluate what the model produces, catch errors, and own the outcome.
- The second is process: an A-SPICE-aligned validation flow that connects requirements to evidence at every stage and is audit-ready by default.
- The third is AI agents: agentic tooling that accelerates the work within that structure.
All three are necessary. A capable model running inside a broken process, or a well-structured process staffed by engineers who cannot evaluate AI output, does not deliver the result modern vehicle test and validation programs require.
The architecture: Agents mapped to the V-model
With that foundation in place, the V-model gave us our organizing principle for the agentic layer. The result is a set of solutions we call V-Tools. It is a multi-agent setup where each agent maps to a specific level of the V-model, including requirements, architecture, design, and coding. The setup also includes corresponding verification agents for unit testing, component integration, and qualification. Also, a compliance agent runs across the full cycle, tracking traceability and flagging gaps.
Each agent connects to two things: a shared model gateway that handles routing, deployment mode, and audit logging, and a RAG layer that grounds the agent in project-specific context: requirements history, defect records, previously validated test patterns.
One decision that mattered more than expected: agents pass targeted, stage-relevant context to each other, not the full history of everything that preceded them. This is not a minor implementation choice. As a language model’s context window grows, output quality degrades noticeably. The requirements agent needs context. The test generation agent needs test-relevant context. Keeping that separation disciplined is what maintains accuracy at scale.
The whole setup connects to existing tooling through MCP (Model Context Protocol) integrations across ALM, test management, and CI/CD pipelines. Teams do not need to abandon their current delivery processes. The agentic flow simply layers on top of them.
One architectural principle we maintained throughout was avoiding vendor lock-in at the model level. Different agents can run on different models: a cloud-based reasoning model for requirements analysis, a separate model for test generation, and a local on-premises model for runtime execution. As models improve or program requirements change, individual components can be swapped without rebuilding the entire system.
Requirements intelligence: Catching gaps before they become test failures
The requirements agent is where most teams see immediate and tangible return.
An engineer feeds customer requirements or system specifications into the agent. The agent evaluates them against several dimensions: Are they testable? Are any semantically duplicated? Are there gaps based on patterns the system has seen in similar projects before? It runs this analysis against the project’s existing history – requirements from earlier programs, defect logs, known edge cases.
The interaction is iterative, not one-pass. The engineer reviews the feedback, pushes back where the agent is wrong or irrelevant, refines the requirements, and runs again. The output is cleaner requirements with an attached traceability matrix connecting each requirement to proposed test scenarios before a single test has been written.
This is one of the most practical applications of agentic AI in automotive testing: not replacing the engineer, but helping engineering teams identify ambiguity, inconsistency, and missing test coverage earlier in the lifecycle.
Main lessons from this stage: input quality determines output quality, without exception. Weak, ambiguous, or incomplete requirements produce weak test cases regardless of how capable the model is. The agent accelerates work that has been done correctly; it does not correct work that was flawed from the start. This means the conversation about requirements quality has to happen before the AI tooling conversation, not after.
From scenario to code and where the handoff breaks
Once requirements are reviewed and traced, the test scenario moves into AI Test Studio, a workspace built specifically for HMI and IVI validation running on Android Automotive OS (AAOS).
An engineer describes a test scenario in a natural language. The system generates executable pytest code, starting from what already exists in the project repository, reusing proven patterns and successful test flows from earlier runs rather than generating from scratch. The generated test is visible, reviewable, and editable before it runs. A vision-language model (VLM) handles runtime verification by checking what is rendered on screen, not just what the application layer reports.
That visual layer matters. Navigation animations, rendering artifacts, and UI state changes are visible to the VLM. For HMI validation, where the customer experience is the product, this is the difference between catching a real defect and missing it entirely.
The model architecture is split deliberately: large reasoning models for test design and scenario generation, local on-premise VLMs for runtime verification near the bench. This split keeps latency manageable and allows sensitive data to stay on-premise during execution.
Main lessons from this stage: the handoff between large and small models is harder than it looks. The large model generates the intent and the test structure, it also generates the prompt that the small model uses during execution. That prompt does not always translate cleanly. Engineers need to review and tune these runtime prompts, and the effort is not trivial, particularly for complex HMI flows with many conditional states. Without an engineer who understands the specific HMI behavior being tested, this tuning process is guesswork. It is one of the clearest examples of why domain expertise cannot be substituted by better tooling.
CI/CD, reports, and the loop that makes the next cycle smarter
With tests reviewed and approved, they deploy into CI/CD for continuous execution. Every run produces artifacts: screenshots, VLM reasoning logs, timing data, requirement links, and reports. These are not just evidence for the current release cycle, they feed back into the agent’s context, making subsequent test generation better informed.
This feedback loop separates the approach from a faster version of manual testing. Requirements that were unclear surface as failures. Tests that were generated correctly but executed against unstable environments can be identified and quarantined. Coverage gaps become visible before they become late-release problems.
For SDV testing and validation, this loop is especially important because release cycles are becoming shorter while system complexity is increasing. Teams need validation evidence that is not only faster to produce, but also traceable, repeatable, and useful for the next development cycle.
Main lessons from this stage: Dynamic data is consistently the biggest source of flakiness. A navigation test that builds a route behaves differently depending on traffic conditions at execution time. Media state, localization, and popup timing introduce variability that naive assertions cannot handle. The fix is deterministic test setup – fixed profiles, stable datasets, explicit preconditions, controlled device state. This requires upfront effort, but without it, CI pipelines generate noise rather than signal. Non-determinism in code generation is a separate, smaller issue: the same prompt against the same model against the same UI produces slight variations in generated test steps. In practice, this does not affect outcomes, but variance needs to be tracked across runs rather than treated as an error on first occurrence.
Engineers stay in the loop by design, not as a fallback
Human approval gates at every stage: requirements review, test acceptance, evidence sign-off are not a safety net bolted onto the system. They are what makes the system’s output meaningful.
An agent that runs without human gates generates artifacts that look like evidence but are not: unreviewed, untraced, and unable to survive an A-SPICE assessment. The gates are also what allow the system to improve over time. Engineers who review agent outputs and push back on errors are, in effect, improving the model’s context for the next run. Accumulated human judgment is what the RAG layer is built from.
This is also why seniority matters more in AI-assisted workflows than it does in manual ones. A senior engineer reviewing agent output for can catch errors that a junior engineer might accept. The model amplifies whatever expertise is in the loop with it. If that SDV software safety expertise is shallow, the amplification does not help.
Where this lands
The workflow described here is not a research prototype. It runs on real software and hardware, against real requirements, producing evidence that goes into real audits.
What it delivers is measurable: requirements that previously took days to review can be analyzed in hours; test scripts that required full manual authoring can be generated, reviewed, and deployed significantly faster; traceability that used to be assembled after the fact is captured continuously during execution.
What it does not deliver is automation without accountability. That distinction matters as the tooling matures and the pressure to move faster increases.
Release cycles will keep accelerating. Validation scope will keep growing. The teams that keep pace are not the ones that replaced engineers with AI, but the ones that gave their engineers AI-assisted workflows that match the scale of what modern SDV programs actually demand. The engineer’s role shifts toward decisions that require judgment, domain knowledge, and accountability, which is precisely where engineering value belongs.
The practical starting point is integration: connect the tooling to your actual programs, run it against real requirements, and observe where the gaps and the benefits actually appear. The answers look different in every program context. Starting that process is the only way to find out what they are in yours.
