[Samsung Electronics] Szenario möglich: MCU-Firmware für Haushaltsgeräte zu 100 % von KI entwickelt?

Titel: Szenario möglich: MCU-Firmware für Haushaltsgeräte zu 100 % von KI entwickelt?

Original: Samsung Tech Blog - https://techblog.samsung.com/blog/article/90

• Samsung Electronics hat „Harness Engineering“ auf die MCU-Firmware-Entwicklung für ein Haushaltsgerät (Dunstabzugshaube) angewendet, um zu prüfen, ob ein KI-Agent ohne menschliche Coding-Eingriffe durch autonomes Wiederholen von Planung, Implementierung und Verifikation Firmware zu 100 % erstellen kann.

• Mit „Harness“ ist hier nicht gemeint, das Modell intelligenter zu machen, sondern die Arbeitsumgebung so zu gestalten, dass die KI die beabsichtigten Ergebnisse erzielt: benötigte Informationen, Verbote, Selbstverifikations-Loop, Ordnerstruktur, Spezifikationen, Coding-Standards sowie Build/Linter. Die Rolle der Entwickler verschiebt sich vom „Code-Schreiber“ zum „Designer von Spezifikationen und Harness“.

• Das Kernprinzip lautet: „Eine Spezifikation, die die KI nicht überprüfen kann, ist eine nicht existente Spezifikation.“ Nicht dokumentierte Anforderungen können weder Implementierungs- noch Verifikationskriterium sein und entsprechen damit „nicht existierenden Anforderungen“ (z. B. wenn nicht angegeben wird, ob der Luftstrom als Low-Mid-High oder als On-Off umgesetzt werden soll, entscheidet die KI eigenständig). Ausgangspunkt ist „Specification Design“: Legacy-Spezifikationen und das „implizite Wissen“ der Entwickler werden in eine Form systematisiert, die KI nutzen kann.

• Verstreute Spezifikationen wurden rund um den Ordner docs/ neu organisiert. Produktverhalten liegt in behavior/, Designbegründungen in design/, Hardwareaufbau und Initialisierungsinformationen in hardware/; Kommunikationsspezifikationen, Zustandsmaschinen und Kommunikationsprotokolle wurden ebenfalls in eigene Ordner einsortiert. Ergänzt durch AGENTS.md mit Regeln für KI-Arbeiten sowie ARCHITECTURE.md mit Layer-Struktur und Abhängigkeitsregeln wurde die Harness-Basis vervollständigt. Dadurch fungiert die Dokumentation als „Single Source of Truth“.

• Zusätzlich zu drei Arten von Harness für Spezifikation, Implementierung und Verifikation wurden als „Skills“ eine Samsung-spezifische MCU-Spezifikation, die Nutzung des MCU-Debuggers sowie ein USB Switch bereitgestellt, der die 220-V-Stromversorgung physisch aus- und einschaltet. SDD/TDD/BDD kontrollieren den Implementierungsumfang; erst nach Bestehen der Qualitäts-Gates Build/Test/Lint geht es in die nächste Phase.

• Der AUTOPILOT-Loop startet bei Zero-Base-Code und wiederholt Planung, Implementierung und Verifikation autonom. Dabei werden der „generierende Agent“ und der „bewertende/verifizierende Agent“ getrennt, um zu verhindern, dass die KI ihre eigenen Ergebnisse zu wohlwollend bewertet.

• Die schwierigste Aufgabe war der Aufbau einer Umgebung, in der die KI ihre Ergebnisse direkt auf einer „realen MCU“ prüfen kann. Die Verifikationsumgebung besteht aus Codex AI auf dem PC, einem JTAG-basierten MCU-Debugger und einem USB Switch zur Stromsteuerung; Codex AI steuert Debugger und Switch. Der Debugger liest und schreibt den MCU-Zustand direkt, und der USB Switch schaltet die 220-V-Stromversorgung ein und aus, sodass die KI das Set selbst in nicht wiederherstellbaren Zuständen initialisieren kann.

• Der KI werden Produktspezifikationen, Protokoll- und Paketinformationen, MCU-Datenblatt, Debugger-Nutzung, Quellcode- und Variablenstruktur sowie die Methode zum Ein-/Ausschalten der Stromversorgung bereitgestellt. Die KI analysiert die Spezifikation, leitet aus „autonomem Willen“ Testszenarien ab, injiziert per Debugger Tasteneingaben in das reale Set (Memory Write), liest anschließend Zustandswerte als Variablen aus (Memory Read) und bewertet für jedes Szenario selbstständig Pass/Fail. Autonome automatische Verifikation entsteht also, wenn die drei Elemente „Verhaltensszenario + Memory Write + Memory Read“ zusammenwirken.

• Ergebnis: In allen 5 Durchläufen wurde die Firmware ohne menschliche Eingriffe autonom fertiggestellt (jeweils ca. 4,5–5,5 Stunden), mit einer Vollständigkeit der Grundfunktionen von etwa 95 %. Die fehlenden rund 5 % traten vor allem im HAL-Bereich auf (UART, Timer, WatchDog, Clock usw., also tatsächliche HW-Verifikationsbereiche) und konnten durch 1–4 Stunden Debugging mit Menschen ergänzt werden.

• Es wurde bestätigt, dass die Entwicklungszeit im Durchschnitt um 50–70 % verkürzt werden könnte. Allerdings handelt es sich um eine KI-Schätzung auf Basis der reinen Entwicklungszeit ohne Freigabe, Review und Release; Herausforderungen für die breite Einführung sind die anfänglichen Investitionen und die Etablierung „perfekter Verifikationskriterien auf einem Niveau, bei dem Menschen den Code nicht mehr reviewen müssen“.