Wird AI im Systems Engineering so erfolgreich sein wie in der Programmierung?

Vier von fünf Programmierern nutzen laut Stack Overflow ein KI-Werkzeug. Beim Analysehaus SemiAnalysis entfällt über die Hälfte des wiederkehrenden Umsatzes von Anthropic und OpenAI auf die Programmierung. Kein anderer Beruf kommt in die Nähe dieser Zahlen, Systems Engineering am wenigsten.

Liegt das daran, dass SE einfach nur hinterherhinkt und bald nachzieht? Oder ist Programmierung ein Sonderfall? Wer abschätzen will, was KI im SE leistet, muss prüfen, welche Bedingungen den Sonderfall erzeugen und wie viele davon im eigenen Umfeld vorliegen.

Vier Gründe für den Sonderfall

Der Economist hat diese Bedingungen auf vier Faktoren gebracht: (1) die Verfügbarkeit von Trainingsdaten, (2) die Prüfbarkeit der Ausgabe, (3) den geringen Anteil menschlicher Interaktion, und (4) die Programmierer selbst.

Öffentlicher Quellcode liegt in gewaltiger Menge im Netz und macht in manchen Modellen fast ein Fünftel der Trainingsdaten aus. Kein anderes Berufsfeld hat seine Arbeitsergebnisse über zwei Jahrzehnte freiwillig veröffentlicht.

Compiler, Unit-Test und CI-Pipeline geben in Sekunden Rückmeldung. Das fängt Fehler früh ab und liefert zugleich das Signal, an dem ein Modell trainiert wird. Ein Testergebnis ist eine Belohnungsfunktion.

Der Kontext einer Programmieraufgabe steckt im Code und ist über Schnittstellen ansprechbar. Und die Programmierer wechseln alle paar Jahre Werkzeuge, meist ohne Freigabe. Die Verbreitung lief meistens von unten nach oben: Entwickler haben einfach gemacht, was sie für richtig gehalten haben und sich die Werkzeuge geholt, die sie für die richtigen hielten.

Verbreitung ist aber nicht dasselbe wie Produktivität. In einer Studie von METR aus dem Jahr 2025 brauchten erfahrene Open-Source-Entwickler mit KI 19 Prozent länger, schätzten sich selbst aber 20 Prozent schneller ein. Allerdings hat METR inzwischen ein Update veröffentlicht, das beschreibt, wie sich das im Moment ändert.

Der Rest der Wissensarbeit

Jenseits des Codes wächst KI dort am schnellsten, wo die Arbeit formelhaft ist. Harvey, Clio und Legora haben ihren gemeinsamen Umsatz mit juristischen Werkzeugen binnen eines Jahres auf rund eine Milliarde Dollar verdoppelt, Sierra kam im Kundenservice auf 200 Millionen. Beeindruckende Kurven auf sehr kleinen Ausgangswerten.

Dem steht der NANDA-Bericht des MIT von 2025 gegenüber, nach dem rund 95 Prozent der untersuchten KI-Pilotprojekte keinen messbaren Ergebnisbeitrag lieferten. Das Muster dahinter wiederholt sich: kein öffentliches Korpus für Mandantenakten, kein automatisches Urteil über die Qualität, und das Wissen sitzt in Köpfen statt in Systemen.

Systems Engineering im Vergleich

Gegen dieses Raster geprüft steht SE bei drei Faktoren schlechter da als das Programmieren, beim vierten gespalten.

1. Trainingsdaten. Für Code gibt es gitHub. Das war vermutlich der Grund, warum Microsoft damals gitHub für $7,5 Milliarden gekauft hatte. Für Anforderungen gibt es PURE, eine Sammlung von 79 öffentlichen Lastenheften mit rund 34.000 Anforderungen. Der Rest liegt hinter NDA in DOORS-Modulen, Cameo-Projekten und Excel-Tabellen. Öffentliche SysML-Modelle industrieller Größe existieren praktisch nicht. Hier liegt SE näher am Callcenter als am Compiler.
2. Prüfbarkeit. Die Frage besteht aus zwei Teilen. Ob eine Anforderung sauber formuliert ist, prüft eine Maschine gut. Der INCOSE Guide for Writing Requirements liefert die Regeln, Werkzeuge wie Jama Connect Advisor oder Raiqon setzen sie seit Jahren um. Ob es die richtige Anforderung ist, zeigt sich beim Integrationstest oder im Feld, oft Jahre später. Die Ausnahme sind ausführbare Modelle. Wo eine Simulation oder ein Modell-Checker urteilen kann, existiert relativ schnelles Feedback, und dort ähnelt SE dem Programmieren am stärksten.
3. Menschliche Interaktion. Der Kern der Arbeit besteht aus Aushandlung zwischen Disziplinen, Zulieferern und Zulassungsstellen. Diese Information entsteht im Gespräch und wird selten vollständig aufgeschrieben. Wo sie digital vorliegt, ist sie über Werkzeuge verteilt, die einander nicht kennen. Yousef Hooshmand, Lead Architect bei NIO, benennt im Interview für SE-Trends genau das als eigentliche Bremse:

„Geschwindigkeit und Qualität der Produktentwicklung hängen wesentlich davon ab, ob die benötigten Daten vollständig, konsistent, verständlich und über Systemgrenzen hinweg verfügbar sind.“

Yousef Hooshmand, Lead Architect bei NIO

4. Die Ingenieure selbst. Der schwerste Faktor. Ein Werkzeug, dessen Fehler in das Produkt gelangen kann, braucht im regulierten Umfeld ein Vertrauensargument, etwa die Werkzeugqualifizierung nach ISO 26262 Teil 8 oder nach DO-330. Für ein nichtdeterministisches Modell ist dieses Argument ungelöst. Dazu kommt der IP-Schutz, denn ein Lastenheft geht nicht in eine öffentliche Cloud. Und Systems Engineers führen Werkzeuge nicht heimlich ein, sie ändern den Prozess. Das dauert länger. Was auf diesem Weg eingeführt wird, bleibt dafür.

Was sich gerade verändert

Die Datenlücke füllen Anbieter mit synthetischen Daten und mit bezahlten Fachleuten, die ihr Wissen in Modelle überführen. Für Anforderungstexte funktioniert das ordentlich, für gewachsene Architekturmodelle kaum. Bei der Interaktion hilft heute schon Transkription und macht Besprechungen maschinenlesbar. Damit kommt Wissen mit wenig Aufwand in die Systeme, das vorher dort nie ankam.

Durch das Interesse an der Prüfbarkeit bekommen formale Methoden ein Comeback. Die Kombination aus einem generierenden Modell und einem formalen Prüfer gibt der Formalisierung von Anforderungen ein zweites Leben. Das Modell erstellt einen Forschlag, der Modellchecker beurteilt es in deterministisch.

Beim vierten Faktor bewegt sich am wenigsten. An Zulassungspfaden für generative Werkzeuge in sicherheitsrelevanten Toolchains wird zwar gearbeitet, aber diese sind noch Weit von einer Zulassung entfernt. Yuchao Luo beschreibt im Interview für SE-Trends, dass chinesische Teams eine Trefferquote von 70 bis 80 Prozent bei KI-erzeugten Anforderungen annehmen und den Rest per Review korrigieren, während europäische Teams zuerst den Korrektheitsnachweis verlangen.

Die eigene Lage einschätzen

Statt zu fragen, ob KI grundsätzlich im Systems Engineering funktioniert, lässt sich prüfen, wie viele der vier Faktoren im eigenen Unternehmen erfüllt sind.

1. Datenlage. Wie viel der Anforderungen, Modelle und Verifikationsergebnisse der letzten fünf Jahre liegt maschinenlesbar und verknüpft vor? Lautet die Antwort im Wesentlichen PDF, ist die Datenfrage dran und nicht die KI-Frage.
2. Orakel. Für welche Artefakte existiert heute eine automatische Prüfung, sei es eine Simulation, ein Regelsatz oder ein Konsistenzcheck? Genau dort beginnt der sinnvolle Einsatz.
3. Anteil an menschlichem Input. Wie viel Arbeitszeit fließt in Recherche, Formulierung und Abgleich, wie viel in Aushandlung mit Menschen? Nur der erste Teil ist adressierbar, und er ist größer als vermutet.
4. Erlaubnis. Darf jemand ein Werkzeug ausprobieren, ohne vorher eine Freigabe einzuholen? Lautet die Antwort nein, wird es keine Verbreitung von unten geben. Dann braucht die Einführung einen Verantwortlichen mit Budget und eine Messung des Ausgangszustands. Ohne sie entscheidet später das Gefühl.

Fazit

Systems Engineering wird den Erfolg von AI in der Programmierung nicht wiederholen. Weder die Datenlage noch die regulatorische Vorsicht der Branche ändern sich schnell. Ein Produktivitätssprung über die ganze Disziplin bleibt damit unwahrscheinlich.

Produktivitätsgewinne entsteht in Nischen, in denen eine automatisierte Bewertung möglich ist. Dazu gehören Anforderungsqualität, Konsistenzprüfung über Modellgrenzen, Testfallableitung aus formalisierten Anforderungen, Nachbereitung von Abstimmungen und ähnliche Aktivitäten. Hier besteht die Gefahr, dass lokale Produktivitätsgewinne global verpuffen.

Der Engpass ist nicht die AI selbst, sondern die Verfügbarkeit der eigenen Daten und die Frage, wer ein Werkzeug einführen darf. Wer diese beiden Punkte in Ordnung bringt, profitiert auch dann, wenn die nächste Generation von AI-Modellen hinter den Erwartungen zurückbleiben sollte.