Interview with Georg Doll, Microsoft
“The real challenge is functional traceability”
Georg Doll studied electrical engineering at KIT and brings experience from both Microsoft and Cariad to questions of AI-supported, safety-critical automotive software development.
© Georg Doll
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?
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?
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.
