Generative KI verändert einen Teil der Embedded-Entwicklung — aber nicht den entscheidenden. Was sich verlagert hat, was sich verschärft hat, und was Sie als Auftraggeber bekommen.
Generative KI kann inzwischen Standard-Treiber, einfache Zustandsautomaten und Boilerplate-Code in SystemVerilog, VHDL, C oder Python erzeugen. Das ist real, das ist nützlich, und es hat den Aufwand für bestimmte Routine-Aufgaben gesenkt.
Daraus ergibt sich eine berechtigte Frage: Was leistet ein erfahrener Embedded- und FPGA-Entwickler in diesem Umfeld noch?
Die Antwort ist konkret.
Eine KI ist ein schneller Ausführender. Sie produziert das, was man ihr aufträgt — nicht das, was nötig ist. Wer einer KI sagt „schreib mir einen UART-Treiber“, bekommt einen UART-Treiber. Aber nicht den, der mit dieser Taktdomäne, dieser Pin-Belegung, diesem Zeitverhalten und dieser Fehlerbehandlung in der Zielumgebung tatsächlich funktioniert.
Die eigentliche Ingenieursleistung ist nicht das Erzeugen von Code. Sie ist das Schreiben einer präzisen Spezifikation: Was genau soll passieren, unter welchen Bedingungen, mit welchen Toleranzen, mit welchem Verhalten im Fehlerfall, in welchem Temperaturbereich, über welche Lebensdauer.
Bessere KI ändert daran nichts. Im Gegenteil: Je leistungsfähiger die Werkzeuge werden, desto entscheidender wird, sie richtig zu instruieren.
Eine KI ergänzt keine Anforderungen, an die der Auftraggeber nicht gedacht hat. Sie erfindet keine Spezialfälle. Sie liefert genau das, was in der Spezifikation steht — und nichts darüber hinaus. Was nicht spezifiziert wurde, fehlt im Ergebnis.
Damit verschiebt sich das Risiko vollständig auf die Spezifikation selbst. Eine unerfahrene Spezifikation beschreibt korrekt, was der Kunde gefordert hat, und übersieht alles, was der Spezifizierende nie erlebt hat: den seltenen Sensorausfall bei bestimmten Temperaturgradienten, das Verhalten bei gleichzeitigem Brown-Out und I²C-Buslock, den Watchdog-Reset während einer Flash-Schreibsequenz, die elektromagnetische Einkopplung bei langen Sensorleitungen, das Verhalten beim Wiederanlauf nach Reset während eines kritischen Schreibvorgangs.
Solche Punkte sind keine Kundenanforderungen. Sie sind Anforderungen, die ein erfahrener Entwickler hinzufügt, weil er weiß, dass sie sonst nirgendwo stehen. Eine Spezifikation ist deshalb immer auch ein Risikokatalog — und die Tiefe dieses Katalogs ist proportional zur Erfahrung des Spezifizierenden.
Bei einer Sicherheitsuntersuchung an einem Infusionsgerät, zu der ich von einem Medizintechnikhersteller hinzugezogen wurde, zeigte sich ein sicherheitsrelevantes Versagen, das aus dem gleichzeitigen Auftreten zweier Einzelfehler entstand: dem Hardwareversagen eines Speicherbausteins und einer fehlerhaften Prüfroutine für genau diesen Baustein. Jeder Fehler für sich war beherrschbar. Erst die Kombination erzeugte den nicht erkannten Fehlzustand.
Genau diese Kombinationsbetrachtung ist es, die in einer Spezifikation aktiv ergänzt werden muss. Aus der Anforderung „Speicher prüfen“ generiert ein Werkzeug eine Prüfroutine. Aus der Erfahrung folgt die zusätzliche Anforderung, dass auch das Versagen der Prüfroutine selbst nicht zu einem stillen Fehlzustand führen darf. Diese zweite Anforderung formuliert kein Werkzeug von sich aus.
Hinzu kommen die hardwarenahen Fallstricke, die nicht in Datenblättern stehen, sondern in den Köpfen von Entwicklern, die ihnen schon einmal hinterhergejagt sind:
Für die meisten Aufgaben gibt es mehrere Lösungen, die grundsätzlich funktionieren. Aber nur wenige davon erfüllen die Anforderungen an Sicherheit, Zuverlässigkeit und Lebensdauer, die das konkrete Produkt braucht.
Ein KI-System wählt, was im Trainingsmaterial häufig vorkam. Ein erfahrener Entwickler wählt, was im sicherheitsrelevanten System nicht zur Katastrophe führt. Diese Auswahlentscheidung ist kein Implementierungsdetail. Sie ist das eigentliche Engineering.
Im Schadensfall verlangt der Gesetzgeber den Nachweis, dass das Produkt bei Inverkehrbringen dem Stand der Technik entsprach. Das ist die zentrale Voraussetzung dafür, dass ein Hersteller sich aus der Produkthaftung herausargumentieren kann. Mit der neuen EU-Produkthaftungsrichtlinie und dem darauf folgenden deutschen Umsetzungsgesetz wird diese Beweispflicht für Software und softwareintegrierte Produkte ausdrücklich verschärft.
Der Stand der Technik ist kein statischer Zustand. Er ist das, was unter Fachleuten als üblich gilt — und er verändert sich derzeit beschleunigt, weil neue Werkzeuge und Methoden in kurzen Zyklen den Marktstandard heben.
Daraus folgt: Wer heute ein Embedded-System entwickelt, muss die aktuell leistungsfähigeren Methoden kennen und einsetzen. Wer das nicht tut, erzeugt für seinen Auftraggeber ein konkretes Haftungsrisiko. Genau das setzt einen Entwickler voraus, der sowohl die etablierten als auch die neuen Werkzeuge beherrscht und die richtige Auswahl treffen kann.
Ich nutze KI-Werkzeuge dort, wo sie messbar Zeit sparen, ohne Risiken zu erzeugen: Erstentwurf von Boilerplate, Generierung von Testbenches, Dokumentation, Lesbarkeitsprüfung.
Ich nutze sie nicht als Ersatz für:
Das Ergebnis: weniger Aufwand für Routinearbeit, gleichbleibend hohe Qualität bei den Aufgaben, die das Projekt tatsächlich tragen, und ein dokumentierter Entwicklungsprozess, der dem aktuellen Stand der Technik entspricht.
Sie beauftragen einen Entwickler mit über 35 Jahren Erfahrung in FPGA und Embedded, der die aktuellen Werkzeuge kennt und ihre Grenzen einschätzen kann. Sie bekommen kein „KI-generiertes Projekt“ und kein „KI-freies Projekt“. Sie bekommen ein funktionierendes System, für das eine konkrete Person die Verantwortung übernimmt — und das im Schadensfall als nach Stand der Technik entwickelt nachweisbar ist.
Wenn Sie ein Embedded-Projekt haben, bei dem genau diese Tiefe gefragt ist, sprechen wir am besten direkt darüber. Erstgespräch und grobe Einschätzung sind kostenlos und unverbindlich.