Software Defined Vehicles
Interview with Georg Doll, Microsoft
“The real challenge is functional traceability”
As AI enters automotive software engineering, scalable development is becoming a process challenge. Georg Doll, CTO Automotive & Mobility at Microsoft, explains how spec-driven development and AI agents can turn formal intent into verified code.
As software-defined vehicles grow more complex, the pressure on engineering organizations is shifting from code generation to process quality, specification depth and traceability. At the same time, AI is evolving from an experiment into a serious development tool, raising new questions about validation, safety and scale.
Georg Doll, CTO Automotive & Mobility at Microsoft and formerly at Cariad, will address these issues in his keynote at the Automotive Software Strategies Conference 2026. In his talk, he examines why unstructured AI-assisted coding will not scale for safety-critical systems, how spec-driven development can improve software engineering, and what real-world automotive projects already reveal about AI agents in development workflows.
Ahead of the event in Munich, we spoke with him about the structural changes now reshaping automotive software engineering.
ADT: Looking ahead three to five years, what will be the biggest challenge in scaling software engineering for SDVs?
Advertisement
Doll: Honestly, I would rather not look five years ahead – the changes are happening right now. The more relevant question is what will shift over the next one to two years. And the answer is clear: the biggest challenge is not generating code, but specifying intent precisely enough for AI to act on it reliably. The bottleneck is already shifting – from how fast you can code to how precisely you can specify and, critically, how well documented and structured your development processes are. Software complexity in vehicles is growing at four times the rate at which engineering teams can scale. Between multi-zone architectures, safety boundaries, OTA update chains and functional integration, organizational processes and formal engineering disciplines simply have not caught up with the AI wave. Companies that invest in specification quality and process discipline now will gain a compounding advantage. Those that do not will find that AI amplifies their chaos instead of reducing it.
Which development paradigm shift will most strongly influence automotive software engineering?
Spec-Driven Development, or SDD. The bottom of the V-model – code generation – is effectively solved. The new battleground is the left side: formal specification and validation. AI agents can generate code, but they can only generate the right code when they are given precise, structured, machine-readable specifications expressed in formal languages such as SysML V2. Crucially, this is not just about writing specifications by hand – AI also assists in creating them. The shift is moving away from writing code toward AI-assisted specification creation and AI-driven code generation. Equally important, however, is a robust test and validation capability on the right side of the V, also supported by AI, which must grow in parallel. Otherwise, validation simply becomes the next bottleneck.
Why will traditional coding approaches struggle to scale for safety-critical automotive systems?
Consider this: developers spend only 14% of their time actually writing code. The real challenge is not code generation, but functional traceability – the ability to trace every requirement throughout the entire development process down to each individual validation test. “Vibe coding” – AI-assisted but unstructured – produces code that works on one machine but cannot be traced, verified or safely managed at scale. Technical debt caused by missing specifications and broken traceability is not a software problem. It is a process problem that code generation alone cannot fix.
How does spec-driven development change the relationship between requirements, code and verification?
SDD collapses the conventional gap between these three phases by treating them as continuous, machine-readable artifacts rather than separate documents. A key enabler is X-as-code: requirements, architecture, test cases and deployment configurations are all expressed as code-like artifacts that can be versioned, diffed and reasoned over by both humans and AI. When specifications are expressed in formal languages such as SysML V2, they directly inform code generation via AI agents and verification via algorithmic validators. Code becomes a derivation of the specification, not an interpretation of a PDF document that is already fourteen versions out of date. Change a requirement and the impact propagates: the agents know, the test cases know and the deployment knows.
What role can AI agents play in translating specifications into verified software components?
Advertisement
AI agents are uniquely suited to this because formal languages such as SysML V2 give them something they rarely get: complete, structured, machine-readable intent. Instead of guessing developer intent from a comment, an agent can reason over formally specified behaviors, interfaces and constraints. The result can be validated at two levels: deterministically for correctness – does the output conform to the specification? – and semantically for quality – does it make engineering sense? We have demonstrated this end to end with Rust bare-metal firmware for automotive zone controllers. The key architectural insight is this: where correctness matters, you need an algorithm; where quality matters, you can use an agent. These two layers complement each other. They do not compete.
How can companies integrate AI-driven development approaches while maintaining safety compliance?
The architecture that works is formal specifications as the ground truth, deterministic validation scripts as the compliance layer, and AI agents as generation accelerators. You do not hand safety compliance to an AI agent – you hand it to your validation infrastructure, which the AI output must pass. This cleanly separates the non-determinism of AI from the determinism required by ISO 26262, ASPICE and AUTOSAR. The risk arises when organizations ignore this distinction and allow AI both to generate and to self-validate. “Agent tests agent” is non-determinism squared, and that is not a safety argument that will survive a functional safety audit.
Finally, what do you personally hope to take away from the Automotive Software Strategies Conference in Munich?
I am genuinely curious to see how far the industry has moved from “we are exploring AI” to “we are deploying it in safety-relevant workflows.” My expectation is a bimodal distribution: a few forward-looking teams that have made the structural investments in formal engineering, and a larger group still trying to layer AI onto traditional processes. What I hope to take away is concrete evidence of who is doing it right, which organizational changes enabled them, and which patterns the broader industry can realistically replicate. In my experience, the hallway conversations at conferences like ASSC answer those questions more honestly than any talk on the main stage.
