Ein Kollege sagte mir neulich, er brauche Tools wie UMTSM nicht mehr, weil er KI für die Codegenerierung nutze. Ich habe das mehr als einmal gehört. Es ist eine faire Frage, und sie verdient eine ehrliche Antwort — keine defensive.
Also versuche ich, eine zu geben.
Was KI wirklich gut kann
Ich werde es nicht anders darstellen. Wenn du Claude oder GPT-4 bittest, eine einfache Zustandsmaschine in C++ zu implementieren, bekommst du innerhalb von Sekunden etwas Brauchbares. Keine Installation, keine Lernkurve, keine Lizenzkosten. Für einen 5-Zustands-Ampelregler oder einen schnellen Prototyp funktioniert das.
Der Entwickler beschreibt das Verhalten in natürlicher Sprache, das Modell erzeugt den Code, der Entwickler passt ihn an. Schnell, flexibel, reibungslos.
Für kleine, in sich geschlossene, nicht sicherheitskritische Systeme ist das wirklich ausreichend. Das zu leugnen wäre unehrlich.
Wo der Vergleich zusammenbricht
Sobald das System über einen Prototyp hinauswächst, ändert sich das Bild.
Korrektheit ist nicht garantiert
KI-generierter Zustandsmaschinencode sieht korrekt aus. Er ist es oft auch. Aber "oft" ist nicht dasselbe wie "immer" — und in eingebetteten Systemen, besonders in Verteidigung, Automotive und industrieller Steuerung, ist "meistens korrekt" keine akzeptable Spezifikation.
UMTSM generiert Code aus einem formalen Modell. Dieselbe .umt-Datei, durch denselben Generator gelaufen, erzeugt jedes Mal byte-identische Ausgabe. Das Verhalten ist durch die DSL-Semantik definiert, nicht durch das Vertrauen des Modells an einem bestimmten Tag. In einem deterministischen Codegenerator gibt es keine Halluzinationen.
Wartung — wo KI still versagt
Lass KI heute eine Zustandsmaschine generieren. Komm in sechs Monaten zurück, wenn sich eine Anforderung geändert hat, und bitte es, den Code zu aktualisieren.
Das Modell erinnert sich nicht an das vorherige Gespräch. Es weiß nicht, welche Entwurfsentscheidungen absichtlich und welche zufällig waren. Es wird etwas Neues generieren. Du musst zwei KI-Ausgaben vergleichen und entscheiden, was du behältst. Das ist keine Softwareentwicklung — das ist Archäologie.
Bei UMTSM lebt das Design in der .umt-Datei. Ändere das Modell, generiere den Code neu. Der Diff ist deterministisch und bedeutungsvoll. Was sich im Modell geändert hat, ist genau das, was sich in der Ausgabe geändert hat. Versionskontrolle, Code-Reviews und Rückverfolgbarkeit funktionieren wie vorgesehen.
KI-Workflow nach einer Anforderungsänderung:
Beschreibe die Änderung in natürlicher Sprache
→ KI generiert neuen Code
→ Vergleiche mit vorheriger KI-Ausgabe
→ Gleiche absichtliche vs. zufällige Unterschiede manuell ab
→ Teste alles erneut
→ Hoffe, dass nichts Subtiles kaputtging
UMTSM-Workflow nach einer Anforderungsänderung:
Bearbeite die .umt-Datei
→ Starte den Generator
→ Diff ist sauber und semantisch bedeutungsvoll
→ Teste die betroffenen Pfade erneut
Teams skalieren nicht mit KI-generiertem Code
Ein Entwickler, der KI nutzt, kann produktiv sein. Fünf Entwickler, die unabhängig voneinander KI verwenden, um verwandte Zustandsmaschinen zu generieren, werden fünf verschiedene Coding-Stile, fünf verschiedene Annahmen zur Nebenläufigkeit und fünf verschiedene Fehlerbehandlungsstrategien produzieren.
UMTSM erzwingt eine einheitliche Struktur über die gesamte Codebasis. Jede Zustandsmaschine hat dasselbe generierte Grundgerüst, dieselbe Lifecycle-API, dasselbe Thread-Modell. Ein Entwickler, der am ersten Tag zum Projekt stößt, kann jede Zustandsmaschine im System lesen und ihre Struktur sofort verstehen — weil die Struktur immer dieselbe ist.
Zertifizierung akzeptiert "KI hat es geschrieben" nicht
Für Systeme, die unter IEC 61508, ISO 26262, DO-178C oder gleichwertigen Sicherheitsstandards entwickelt werden, muss die Entwicklungswerkzeugkette qualifiziert sein. Jede Transformation von der Anforderung zum Code muss rückverfolgbar und auditierbar sein.
"Wir haben einen KI-Assistenten verwendet" ist kein qualifiziertes Werkzeug. Es kann keinen Tool-Qualification-Report erstellen. Es kann nicht nachweisen, dass eine bestimmte Eingabe immer eine bestimmte Ausgabe erzeugt. Es kann nicht als Beweis in einem Safety-Case eingereicht werden.
UMTSM ist von Anfang an mit Qualifizierung im Sinn entworfen. Der Generator ist deterministisch. Die DSL-Semantik ist formal definiert. Die Transformation vom Modell zum Code ist auditierbar. Das ist kein Feature, das KI replizieren kann — es ist eine grundlegend andere Kategorie von Werkzeug.
Der eigentliche Vergleich
| Kriterium | KI-Codegenerierung | UMTSM |
|---|---|---|
| Anfangsgeschwindigkeit | Sehr schnell | Schnell nach Lernkurve |
| Korrektheitsgarantie | Keine | Deterministisch per Konstruktion |
| Reproduzierbarkeit | Nicht garantiert | Byte-identisch |
| Wartung nach 6 Monaten | Schwierig | Modell bearbeiten, neu generieren |
| Teamkonsistenz | Keine erzwungen | Einheitlich per Design |
| Rückverfolgbarkeit | Keine | Modell → Code, vollständig |
| Zertifizierungseignung | Nicht anwendbar | Dafür entworfen |
| Parallele orthogonale Regionen | Schlecht unterstützt | Erstklassiges Sprachmerkmal |
| Historiezustände | Selten korrekt | Tief, flach, persistent |
| Test-Scaffolding | Manuell | Automatisch generiert |
| Offline / air-gapped | Ja | Ja |
| Kosten | Abonnement | Tool-Lizenz |
Sie konkurrieren eigentlich nicht
Das ist der Teil, der mich überraschte, als ich gründlich darüber nachdachte.
KI und UMTSM müssen keine Gegner sein. Der Entwickler muss trotzdem über das Verhalten des Systems nachdenken. Er muss entscheiden, welche Zustände existieren, welche Ereignisse Übergänge auslösen, welche Guard-Bedingungen gelten, welche Aktionen beim Eintreten ausgeführt werden.
KI kann bei diesem Denken helfen. Sie kann einem Entwickler helfen, ein .umt-Modell zu entwerfen, fehlende Übergänge vorzuschlagen, unerreichbare Zustände zu identifizieren oder zu erklären, warum ein bestimmtes Design ein bestimmtes Szenario nicht korrekt behandelt.
Ohne UMTSM:
Entwickler → KI → C++-Code (unstrukturiert, keine Garantien)
Mit UMTSM:
Entwickler → (KI hilft) → .umt-Modell → UMTSM → garantierter C++-Code
Die KI wird zum Assistenten für die Modellierungsaufgabe. UMTSM übernimmt die Transformation vom Modell zum Code. Das Ergebnis ist schneller als alleine und sicherer, als wenn KI den endgültigen Code direkt produziert.
Eine Anmerkung zu Junior-Entwicklern
Ein Einwand, den ich höre, ist dass UMTSM eine Lernkurve hat. Das stimmt. Aber bedenke die Alternative.
Ein Junior-Entwickler, der KI nutzt, um eine Zustandsmaschine für ein nebenläufiges eingebettetes System zu generieren, wird Code produzieren, der aussieht, als ob er funktioniert. Er wird grundlegende Tests bestehen. Er wird im Feld unter einer Race-Condition scheitern, die nur alle paar tausend Betriebsstunden auftritt.
Ein Junior-Entwickler, der UMTSM verwendet, schreibt eine .umt-Datei, die das Verhalten beschreibt, startet den Generator und erhält automatisch korrekte nebenläufige Infrastruktur. Die Lernkurve liegt im Verstehen von Zustandsmaschinenkonzepten — das ist die eigentliche Fähigkeit, die entwickelt werden muss — nicht im manuellen korrekten Umgang mit Mutex und Thread-Management.
UMTSM beseitigt nicht die Notwendigkeit zu denken. Es beseitigt die Notwendigkeit, denselben Boilerplate jedes Mal korrekt neu zu implementieren.
Fazit
KI-Codegenerierung ist ein genuines nützliches Werkzeug. Ich nutze es. Die meisten Ingenieure tun es. Aber "nützlich für Prototyping und Exploration" ist nicht dasselbe wie "geeignet für die Entwicklung von Produktions-Embedded-Software in großem Maßstab."
Der Kollege, der mir sagte, er brauche Tools wie UMTSM nicht mehr, hat für das, was er heute baut, wahrscheinlich recht. Wenn seine Systeme klein bleiben und nie Zertifizierung erfordern, könnte KI auf unbestimmte Zeit ausreichen.
Aber für Teams, die komplexe, nebenläufige, sicherheitsrelevante eingebettete Systeme bauen, die über Jahre gewartet und gegen internationale Standards zertifiziert werden müssen, ist der Vergleich nicht eng. Determinismus, Rückverfolgbarkeit, Teamkonsistenz und Qualifizierung sind keine optionalen Features. Sie sind der Job.
UMTSM wurde genau deshalb gebaut, weil diese Einschränkungen real sind und weil die bestehenden Tools, die sie ernst nehmen, entweder unverhältnismäßig teuer, schlecht designed oder beides sind.
*Fehmi Demiralp ist der Entwickler von UMTSM, einem Zustandsmaschinen-DSL und Code-Generierungsframework für eingebettete C++-Entwicklung.*
