Mit zunehmender Komplexität softwaredefinierter Fahrzeuge verlagert sich der Druck auf
Entwicklungsorganisationen von der reinen Codegenerierung hin zu
Prozessqualität, Spezifikationstiefe und Rückverfolgbarkeit. Gleichzeitig entwickelt sich KI vom Experiment zu einem
ernstzunehmenden Entwicklungswerkzeug – und wirft neue Fragen zu
Validierung, Safety und Skalierung auf.
Georg Doll, CTO Automotive & Mobility bei Microsoft und zuvor bei Cariad tätig, greift diese Themen
in seiner Keynote auf der Automotive Software
Strategies Conference 2026 (19. und 20. Mai in München) auf. In seinem Vortrag zeigt der
Diplom-Ingenieur, warum unstrukturiertes KI-gestütztes Coding für
sicherheitskritische Systeme nicht skalieren wird, wie Spec-Driven Development
das Software Engineering verbessern kann und was reale Automotive-Projekte
bereits über den Einsatz von KI-Agenten in
Entwicklungs-Workflows erkennen lassen.
Im Vorfeld der Veranstaltung in München haben wir mit ihm
über die strukturellen Veränderungen gesprochen, die das Automotive Software
Engineering derzeit grundlegend prägen.
Herr Doll, was wird in den nächsten drei bis fünf Jahren
die größte Herausforderung bei der Skalierung des Software Engineering für SDVs
sein?
Ehrlich gesagt würde ich lieber nicht fünf Jahre in die
Zukunft schauen – die Veränderungen finden bereits jetzt statt. Die relevantere
Frage ist, was sich in den nächsten ein bis zwei Jahren verschieben wird.
Gerne.
Die größte Herausforderung ist nicht die Codegenerierung,
sondern die präzise Spezifikation von Absichten, damit KI zuverlässig darauf
reagieren kann. Der Engpass verschiebt sich bereits – weg von der Frage, wie
schnell man Code schreiben kann, hin zu der Frage, wie präzise man
spezifizieren kann und, ganz entscheidend, wie gut dokumentiert und
strukturiert die eigenen Entwicklungsprozesse sind. Die Softwarekomplexität in
Fahrzeugen wächst viermal so schnell, wie Engineering-Teams skaliert werden
können. Zwischen Multi-Zonen-Architekturen, Safety-Grenzen, OTA-Update-Ketten
und funktionaler Integration haben organisatorische Prozesse und formale
Engineering-Disziplinen mit der KI-Welle schlicht noch nicht Schritt gehalten.
Unternehmen, die jetzt in Spezifikationsqualität und Prozessdisziplin
investieren, werden einen sich verstärkenden Vorteil erzielen. Unternehmen, die
das nicht tun, werden feststellen, dass KI ihr Chaos verstärkt, statt es zu
reduzieren.
Spec-Driven
Development als neuer Engineering-Ansatz
Welcher Paradigmenwechsel in der Entwicklung wird das
Automotive Software Engineering am stärksten beeinflussen?
Spec-Driven Development, kurz SDD. Die untere Ebene des
V-Modells – die Codegenerierung – ist im Grunde gelöst. Das neue Schlachtfeld
ist die linke Seite: formale Spezifikation und Validierung. KI-Agenten können
Code generieren, aber sie können nur dann den richtigen Code generieren, wenn
sie präzise, strukturierte, maschinenlesbare Spezifikationen erhalten, die in
formalen Sprachen wie SysML V2 ausgedrückt sind. Entscheidend ist: Es geht
nicht nur darum, Spezifikationen von Hand zu schreiben – KI unterstützt auch
deren Erstellung. Die Entwicklung verschiebt sich also weg vom Schreiben von
Code hin zu KI-gestützter Spezifikationserstellung und KI-getriebener
Codegenerierung. Genauso wichtig ist jedoch, dass parallel dazu eine robuste
Test- und Validierungsfähigkeit auf der rechten Seite des V aufgebaut wird,
ebenfalls KI-gestützt. Andernfalls wird die Validierung schlicht zum nächsten
Engpass.
Warum
klassische Coding-Ansätze im Auto an Grenzen stoßen
Warum werden traditionelle Coding-Ansätze bei
sicherheitskritischen Automotive-Systemen Probleme haben zu skalieren?
Man sollte sich Folgendes vor Augen führen: Entwickler
verbringen nur 14 Prozent ihrer Zeit tatsächlich mit dem Schreiben von Code.
Die eigentliche Challenge ist nicht die Codegenerierung, sondern die
funktionale Rückverfolgbarkeit – also die Fähigkeit, jede Anforderung über den
gesamten Entwicklungsprozess hinweg bis hinunter zu jedem einzelnen
Validierungstest nachzuverfolgen. „Vibe Coding“ – KI-gestützt, aber
unstrukturiert – erzeugt Code, der auf einem Rechner funktioniert, sich aber
nicht rückverfolgen, verifizieren oder im großen Maßstab sicher beherrschen
lässt. Technische Schuld, die durch fehlende Spezifikationen und unterbrochene
Rückverfolgbarkeit entsteht, ist kein Softwareproblem. Es ist ein
Prozessproblem, das sich allein durch Codegenerierung nicht lösen lässt.
Wie verändert Spec-Driven Development die Beziehung
zwischen Anforderungen, Code und Verifikation?
SDD beseitigt die konventionelle Lücke zwischen diesen drei
Phasen, indem es sie als kontinuierliche, maschinenlesbare Artefakte statt als
getrennte Dokumente behandelt. Ein zentraler Enabler ist X-as-code:
Anforderungen, Architektur, Testfälle und Deployment-Konfigurationen werden
allesamt als codeähnliche Artefakte ausgedrückt, die versioniert, verglichen
und sowohl von Menschen als auch von KI interpretiert werden können. Wenn
Spezifikationen in formalen Sprachen wie SysML V2 ausgedrückt sind, fließen sie
direkt in die Codegenerierung durch KI-Agenten und in die Verifikation durch
algorithmische Validatoren ein. Code wird damit zu einer Ableitung der
Spezifikation und nicht zu einer Interpretation eines PDF-Dokuments, das
bereits vierzehn Versionen veraltet ist. Ändert sich eine Anforderung, dann
propagiert die Auswirkung durch das gesamte System: Die Agenten wissen
Bescheid, die Testfälle wissen Bescheid, und das Deployment weiß ebenfalls
Bescheid.
KI-Agenten
zwischen Codegenerierung, Verifikation und Sicherheit
Welche Rolle können KI-Agenten dabei spielen,
Spezifikationen in verifizierte Softwarekomponenten zu überführen?
KI-Agenten sind dafür besonders gut geeignet, weil formale
Sprachen wie SysML V2 ihnen etwas geben, das sie nur selten bekommen:
vollständige, strukturierte, maschinenlesbare Intention. Statt die Absicht
eines Entwicklers aus einem Kommentar erraten zu müssen, kann ein Agent über
formal spezifizierte Verhaltensweisen, Schnittstellen und Randbedingungen
schlussfolgern. Das Ergebnis lässt sich auf zwei Ebenen validieren:
deterministisch hinsichtlich der Korrektheit – entspricht das Ergebnis der
Spezifikation? – und semantisch hinsichtlich der Qualität – ergibt es aus
Engineering-Sicht Sinn? Wir haben das End-to-End mit Rust-Bare-Metal-Firmware
für Automotive-Zonencontroller demonstriert. Die zentrale architektonische
Erkenntnis lautet: Dort, wo Korrektheit entscheidend ist, braucht man einen
Algorithmus; dort, wo Qualität entscheidend ist, kann man einen Agenten
einsetzen. Diese beiden Ebenen ergänzen sich. Sie stehen nicht in Konkurrenz
zueinander.
Wie können Unternehmen KI-getriebene Entwicklungsansätze
integrieren und dabei die Safety-Compliance aufrechterhalten?
Die Architektur, die funktioniert, besteht aus formalen
Spezifikationen als Ground Truth, deterministischen Validierungsskripten als
Compliance-Schicht und KI-Agenten als Beschleunigern für die Generierung. Man
überträgt die Safety-Compliance nicht einem KI-Agenten – man überträgt sie der
Validierungsinfrastruktur, die den Output der KI bestehen muss. Dadurch wird
die Nichtdeterministik von KI sauber von der Deterministik getrennt, die durch
ISO 26262, ASPICE und AUTOSAR gefordert wird. Das Risiko entsteht dann, wenn
Organisationen diese Unterscheidung ignorieren und der KI sowohl die
Generierung als auch die Selbstvalidierung überlassen. „Agent testet Agent“ ist
Nichtdeterministik im Quadrat, und das ist kein Safety-Argument, das ein
Functional-Safety-Audit überstehen würde.
Zum Abschluss würde uns interessieren, was Sie sich
persönlich von der Automotive Software Strategies
Conference in München erhoffen?
Ich bin wirklich neugierig zu sehen, wie weit sich die
Branche von „Wir erkunden KI“ hin zu „Wir setzen KI in sicherheitsrelevanten
Workflows ein“ bewegt hat. Ich erwarte eine bimodale Verteilung: einige
vorausschauende Teams, die die strukturellen Investitionen in formales
Engineering bereits getätigt haben, und eine größere Gruppe, die noch versucht,
KI auf traditionelle Prozesse aufzusetzen. Was ich mitnehmen möchte, sind
konkrete Belege dafür, wer es richtig macht, welche organisatorischen
Veränderungen das ermöglicht haben und welche Muster die Branche insgesamt
realistisch nachbilden kann. Meiner Erfahrung nach beantworten die Flur-Gespräche
auf Konferenzen wie der ASSC diese Fragen
ehrlicher als jeder Vortrag auf der Hauptbühne.
