Woran ich arbeite

hactl ist ein Kommandozeilen-Tool, um das größte Hausautomatisierungs-Framework der Welt, Home Assistant, für KIs direkt zugänglich zu machen. Das Problem ist, dass es KI-Schnittstellen für Home Assistant gibt, diese aber sehr viele Tokens verbrauchen. Das liegt daran, dass die Schnittstellen nur teilweise zur Verfügung stehen und nicht einheitlich funktionieren. Teilweise gibt es gar keine Schnittstelle, dann müssen sich die KI-Agenten über ein Terminal einwählen und direkt die Dateien oder die Datenbank editieren. Das ist prinzipiell gefährlich. Andere Lösungen versuchen das mit MCP, dem Model Context Protocol. Das ist eine große JSON-Schlacht, die sehr viele Tokens verbraucht.

hactl löst das Problem mit einem Kommandozeilen-Tool: eindeutige, einheitliche Befehle für alle Eigenschaften von Home Assistant, mit denen alles modifiziert werden kann. Vor jeder Änderung wird automatisch ein Backup erstellt, und die Prüfung der Konsistenz führt Home Assistant selbst durch. So kann man schnell und sicher mit Home Assistant interagieren.

Das hat sehr klassisch mit Vibe Coding gestartet, aber sehr test-driven. Es wurde ein gutes Testkonzept entwickelt, in dem ein reales Home Assistant in einem Docker-Container erstellt und darin getestet wurde. Das schien dem echten Home Assistant schon sehr, sehr nahe zu kommen.

Allerdings waren Implementierung und Tester in einer Session. Sehr viele Tests haben deshalb nur bewiesen, dass das, was man sich im Code vorgenommen hat, auch rauskommt. Ob es in der Praxis tatsächlich funktioniert, wurde leider nicht getestet. Außerdem wurden für die verschiedenen Eigenschaften in Home Assistant eigene Agenten gestartet. Die Befehle waren dadurch alles andere als einheitlich. Das größte Problem war, dass sich eine reale Home-Assistant-Instanz ganz anders verhält als ein neu erstellter Docker-Container mit generierten Beispieldateien. Das hat zu vielen Iterationen und Verbesserungen im Testkonzept geführt. Das ist auch auf GitHub nachlesbar.

Am Ende stand doch eine Spezifikation. Das Vorgehen wurde von oben spezifiziert, dann implementiert und zuletzt getestet. Das war unfassbar teuer, weil es nachträglich gemacht wurde. Es hat aber sehr schnell zu einem guten Ergebnis geführt, wo vorher sämtliche Test- und Verbesserungsrunden immer wieder in Inkonsistenzen und Fehlern geendet haben.

Tests gehören in eine eigene Session, unabhängig vom Code (Regel t.1Regel t.1Lass Code und Tests nie vom selben Agenten schreiben.). Ein Testsystem ist nur so gut wie seine Nähe zum echten System. Eine Spec von Anfang an spart die teure Nacharbeit.

Das Projekt entstand, weil ich einen digitalen Bilderrahmen suchte, der sich ändert, wenn sich das Ursprungsalbum ändert. Ohne extra Cloud, ohne monatliche Gebühren. Was es gab, war entweder teuer oder schlecht. Deswegen war es schon lange mein Wunsch, diese App zu haben.

Diese App wurde von Anfang an spezifikationsbasiert entwickelt. Das hat wirklich gut funktioniert, auch wenn durch In-App-Käufe unfassbare Komplexität hinzugekommen ist. Ein einfaches Onboarding mit Kamera und die Sicherheitsfunktionen der App waren schwer umzusetzen. Aber am Ende ist mit der Spezifikation ein Testkonzept entstanden, das auf Simulatoren und echter Hardware fast vollständig testet. Meine eigenen Tests von Hand dauerten insgesamt höchstens vier Stunden, der Rest war automatisiert. Das war wirklich sehr elegant.

Spezifizieren von Beginn an ist ultra effizient. Regressionen oder nutzloser Code kamen quasi nicht vor. Und: Die Technik ist schnell, Kunden und Marketing sind der Wert.

ESPCars ist ein GitHub-Repository, um mit ESPHome, einer fantastischen Basis für Mikrocontroller-Projekte, Automobil-Controller zu entwickeln, die Daten in Echtzeit verarbeiten und loggen können.

Hier kommt eine zusätzliche Ebene dazu: der Mikrocontroller. In der Regel programmieren die Agenten gerne Datenbanken oder Webseiten, wo sie das Ergebnis sofort sehen können. Hier ist eine weitere Stufe eingebaut, eine Hürde: Nach dem Unit Test muss auf dem Prozessor getestet werden, also hochgeladen, geflasht, ausprobiert und die Logs wieder runtergeladen. Und das möglichst effizient. Wenn ein Agent verstehen soll, wie man einen Prozessor flasht, das Logging startet und auswertet, und gleichzeitig den Programmcode beherrschen soll, geht das am Ende im Kontextbrei unter.

Die Frage hier ist also: Wie kann man effizient mit Mikrocontrollern agentisch programmieren? Das ist in dem Projekt auch hinterlegt. Der Haupttrick ist, verschiedene Agenten gleichzeitig zu benutzen: einen Lead, der die Arbeit verteilt, einen Spec-Owner, einen Engineer, Programmierer und Tester, Analysten für die Recherche und einen Agenten für den Prüfstand.

So entstanden sehr schnell sehr leistungsfähige Treiber, die zum Beispiel auf einem Single-Core-RISC-V mit 160 MHz gleichzeitig ein Web-Frontend, ein CAN-Gateway mit zwei CAN-Bussen und Datenmanipulation, UDS-Diagnose, einen Datenlogger auf SD-Karte und LIN liefern: rund 3.500 Frames pro Sekunde je Bus bei 62 bis 75 Prozent CPU-Last. Das ist schon einigermaßen effizient für ein solches Steuergerät.

Dieses Buch selbst besteht aus zwei Repositories, die allerdings nicht öffentlich sind. Eines ist das Buch selbst, die Daten. Fester Vorsatz: Code und Daten immer trennen. Im anderen steht die Auslieferungswebseite, die die Daten bereitstellt, ausliefert und aktualisiert, und das Ganze DSGVO-konform. Auch hier hat es extrem geholfen, erst eine Spezifikation zu schreiben, diese gemeinsam anzupassen und zu verfeinern und dann erst auszurollen. Denn DSGVO-konforme Datenverarbeitung hebt die Hürde für einen Auslieferungsdienst für Mails und Webseiten erheblich an.

Die Idee ist, Softwareentwicklung, wie sie bisher mit Frontier-Modellen möglich ist, auch lokal durchzuführen. Dazu arbeitet zurzeit ein M3 Ultra mit 96 GB RAM und Qwen 3.8 mit 27 Milliarden Parametern in Q8-Quantisierung, mit Pi und OpenCode. Für einzelne Software-Aktualisierungen funktioniert das sehr gut. Für komplexe Embedded-Projekte war es ein spannendes Experiment, nachzulesen auf LinkedIn. Stand September 2026: nicht zielführend. Dagegen eignet sich das lokale Sprachmodell hervorragend für agentische Aufgaben, DSGVO-konform.

Der nächste Schritt in der agentischen Entwicklung geht weg von Software-only hin zur Hardware. Das Projekt PCB Hero erlaubt, Leiterplatten spezifikationsgetrieben Ende-zu-Ende zu entwickeln. Das Ziel ist, auch bei komplexeren Projekten den Weg von Spezifikation, Simulation, Schaltplan, Routing, Fertigung und Test der Leiterplatte in vier Wochen zu schaffen. Das wäre schon etwas schneller als üblich.