Wer regelmäßig Vorträge hält, kennt das Problem.
Natürlich kann man einen Countdown auf dem Smartphone starten. Man kann die Sprecheransicht von PowerPoint nutzen. Oder einen separaten Timer auf dem Notebook öffnen.
In der Praxis funktionieren diese Lösungen oft nur bedingt. Das Smartphone verschwindet in der Tasche, die Sprecheransicht ist nicht immer verfügbar und ein zusätzliches Fenster auf dem Bildschirm hilft wenig, wenn man sich gerade auf Publikum und Inhalte konzentriert.
Die Idee hinter PixelStatus war ursprünglich erstaunlich unspektakulär:
Ich wollte einen kleinen, akkubetriebenen Vortrags-Timer bauen. Eine LED-Matrix, ein Akku, ein Gehäuse und ein Countdown. Fertig.
Der eigentliche Grund für das Projekt war jedoch ein anderer. Ich wollte herausfinden, wie weit man bei einem echten Hardware- und Softwareprojekt mit KI-Unterstützung kommt.
Das eigentliche Experiment war Claude Code
Parallel beschäftigte mich eine andere Frage:
Kann man heute ein komplettes Hardware- und Softwareprojekt zusammen mit einer KI entwickeln?
Nicht als reines Programmierbeispiel und nicht als Demo-Anwendung, sondern als echtes Produkt mit Firmware, Desktop-App, Weboberfläche, Gehäuse, Dokumentation und Automatisierungsschnittstellen.
Pixel Status wurde deshalb schnell zu einer Art Selbstexperiment.
Die erste Anforderung war, unter den vorhandenen Bauteilen, die passenden für das Projekt zu finden. Die Firmware für den ESP8266 wurde gemeinsam mit Claude entwickelt. Das Webinterface, die Companion-App für Windows und macOS, die MQTT-Anbindung, Home-Assistant-Discovery, das OpenSCAD-Gehäuse und große Teile der Dokumentation wurden über viele Iterationen gemeinsam erarbeitet.
Dabei ging es nie darum, Code einfach blind erzeugen zu lassen. Der interessante Teil bestand vielmehr darin, Architekturentscheidungen zu treffen und die KI als Entwicklungspartner einzusetzen. Welche Komponenten brauchen eigene Verantwortlichkeiten? Wie werden Weboberfläche, MQTT und USB-Steuerung vereinheitlicht? Wie lässt sich dieselbe Logik über verschiedene Schnittstellen ansprechen?
Genau deshalb laufen heute alle Steuerwege über einen gemeinsamen Befehls-Dispatcher innerhalb der Firmware. Ob ein Kommando über WLAN, MQTT, USB oder die Companion-App kommt, spielt intern keine Rolle mehr.
Technisch betrachtet entstand dadurch früh eine klare Schichtenarchitektur:
- Anzeigeebene (LED Matrix)
- Steuerungsebene (Command Dispatcher)
- Kommunikationsschnittstellen (Web, MQTT, USB)
- Clients (Web UI, Companion App, Home Assistant)
Neue Steuerwege können dadurch ergänzt werden, ohne die eigentliche Anwendungslogik anzupassen.
Der erste Weg der Bedienung ist die Weboberfläche, die Steuerung funktioniert natürlich von einem Mobile Device und von Desktop gleichermaßen.
Hier ging es mir nicht nur darum, die Bedienung des Displays zu ermöglichen, sondern auch möglichst alle Einstellungen vornehmen zu können. So dass nach Möglichkeit nichts fest im Quellcode der Firmware hinterlegt ist.
Vom Countdown zum Statusdisplay
Der Timer war relativ schnell fertig, aber sobald die 32×8-LED-Matrix auf dem Schreibtisch stand, entstanden automatisch neue Ideen.
Warum nur einen Countdown anzeigen?
Warum nicht auch:
- „In a Call“
- „On Air“
- „Busy“
- Uhrzeit
- freie Lauftexte
Die technische Grundlage war bereits vorhanden. Aus dem Vortrags-Timer entwickelte sich deshalb Schritt für Schritt eine universelle Informationsanzeige.
Zum jetzigen Zeitpunkt unterstützt das Display Timer, Stoppuhr verschiedene vorkonfigurierte Statusanzeigen und ein kleines Spiel das ich Pixel Attack getauft habe.
Neben der Steuerung über das Webinterface, kann das Display auch per MQTT in Home Assistant integriert werden.
Basierend auf dem ursprünglichen Anwendungsfall, einem Timer, kam mir noch die Idee, neben der Steuerung per Wifi, auch eine Steuerung ohne Netzwerk zu realisieren. Da der D1Mini ja über eine USB-Schnittstelle verfügt, lag der Schluss nahe, die Steuerung auch darüber zu emöglichen. Dafür musste dann aber eine Companion App her, die im System Tray lebt und einen schnellen Zugriff auf die Funktionen und Einstellungen bietet. Darum gibt es jetzt auch eine Companion App für Windows (x64 / arm64) und macOS.
Das Gehäuse
Besonders spannend war die Entwicklung des Gehäuses. Während Firmware und Anwendungen relativ einfach iteriert werden können, kostet jede Änderung am Gehäuse einen neuen Druckvorgang.
Claude erzeugte zunächst ein funktionales Grundmodell auf Basis der gemessenen Komponenten. Die eigentliche Arbeit bestand anschließend darin, Kabelwege, Haltepunkte, Toleranzen und Montagepositionen immer weiter zu optimieren.
Das war einer der Bereiche, in denen die Zusammenarbeit zwischen Mensch und KI besonders deutlich wurde: Die KI erzeugte die Geometrie, die praktische Erprobung erfolgte jedoch am Drucker.
Nach einigen Iterationen war es dann so weit und ich konnte das Gehäuse komplett drucken und es passte auch alles.
Der nächste Schritt war dann die Montage der Elektronik in dem Gehäuse.
Die Montage
Nach dem finalen Zusammenlöten der Bauteile ging es daran diese im frisch gedruckten Case unterzubringen. Da bei der Entwicklung des Gehäuses die Größe der Bauteile berücksichtigt wurde, passte erwartungsgemäß alles.
Was Claude Code wirklich gemacht hat und was nicht
Wenn man heute über KI-gestützte Softwareentwicklung spricht, entsteht schnell der Eindruck, man beschreibt einfach eine Idee und wenige Minuten später entsteht daraus ein fertiges Produkt.
Pixel Status ist ein gutes Beispiel dafür, warum die Realität deutlich interessanter ist.
Große Teile des Projekts wurden tatsächlich gemeinsam mit Claude Code entwickelt. Das betrifft die Firmware des ESP8266, die Weboberfläche, die Companion-App für Windows und macOS, das OpenSCAD-Gehäuse und einen erheblichen Teil der Dokumentation.
Trotzdem würde ich nicht sagen, dass die KI das Projekt gebaut hat.
Der eigentliche Entwicklungsprozess bestand aus hunderten kleinen Entscheidungen. Welche Funktionen sind sinnvoll? Wie soll sich ein Timer verhalten? Wie werden Zustände gespeichert? Welche Daten müssen über MQTT veröffentlicht werden? Wie soll ein Gerät reagieren, wenn WLAN oder MQTT nicht verfügbar sind?
Diese Anforderungen und Ideen kamen nicht von Claude Code.
Sie entstanden während der Entwicklung, durch Tests, eigene Erfahrungen und viele Überlegungen zur praktischen Nutzung.
Ein typisches Beispiel war die ursprüngliche Idee eines Vortrags-Timers.
Die erste Anforderung lautete ungefähr:
Das Gerät soll einen Countdown anzeigen und mobil einsetzbar sein.
Daraus ergaben sich automatisch weitere Fragen:
- Wie wird der Timer gestartet?
- Was passiert beim Pausieren?
- Soll die verbleibende Zeit auch ohne WLAN sichtbar bleiben?
- Wie wird vor Ablauf gewarnt?
- Was passiert nach einem Neustart?
Jede beantwortete Frage erzeugte neue Anforderungen und damit neue Diskussionen mit Claude Code.
Human in the Loop statt Autopilot
Technisch betrachtet funktionierte das Projekt selten nach dem Muster:
„Baue mir ein Statusdisplay.“
Stattdessen war die Arbeit wesentlich iterativer.
Oft wurden zunächst Ideen, Nutzungsszenarien oder technische Randbedingungen beschrieben. Claude Code lieferte daraufhin Vorschläge für Architekturen, Datenstrukturen oder Implementierungen.
Anschließend wurde bewertet:
- Ist der Vorschlag technisch sinnvoll?
- Ist er wartbar?
- Passt er zur vorhandenen Hardware?
- Entspricht er dem gewünschten Benutzererlebnis?
Manche Vorschläge wurden übernommen. Andere wurden verworfen oder mehrfach angepasst.
Gerade bei der Firmware zeigte sich schnell, dass eine gute Architektur wichtiger war als die eigentliche Implementierung. Aus diesem Grund entstand früh die Idee eines zentralen Befehls-Dispatchers, über den heute Weboberfläche, MQTT, USB und Companion-App dieselben Aktionen ausführen.
Die grundlegende Idee kam zwar aus den Diskussionen mit Claude Code, die Entscheidung dafür war letztlich jedoch eine Architekturentscheidung des Menschen.
Genau dort liegt aus meiner Sicht der größte Mehrwert moderner KI-Systeme:
Sie ersetzen nicht die technische Verantwortung. Sie beschleunigen den Weg zu einer Lösung.
Die größte Erkenntnis aus dem Projekt, war die Bestätigung der Annahme, dass KI besonders stark wird, wenn Anforderungen bereits relativ klar formuliert sind.
Je genauer beschrieben wurde:
- welches Problem gelöst werden soll,
- welche Einschränkungen existieren,
- wie sich eine Funktion verhalten soll,
desto besser wurden die Ergebnisse.
Die eigentliche Arbeit verlagerte sich dadurch teilweise weg vom Programmieren und stärker hin zur Beschreibung von Anforderungen, Architektur und Benutzererlebnissen.
Man könnte sagen: Statt jede Zeile Code selbst zu schreiben, bestand die Aufgabe zunehmend darin, die richtigen Fragen zu stellen und die richtigen Entscheidungen zu treffen.
Genau deshalb sehe ich Pixel Status heute weniger als ein ESP8266-Projekt oder eine Statusanzeige.
Es ist vor allem ein Praxisversuch, wie weit man mit KI-Unterstützung bei einem echten Hardware- und Softwareprodukt kommt und welche Rolle dabei weiterhin der Mensch spielt.
Und zumindest in diesem Projekt war das Ergebnis eindeutig:
Claude Code war ein sehr leistungsfähiger Entwicklungspartner. Die Verantwortung für Architektur, Prioritäten, Anforderungen und finale Entscheidungen lag jedoch während des gesamten Projekts beim Menschen.
Die Menge an Arbeit wurde durch KI nicht automatisch kleiner. Statt Stunden in Implementierungsdetails zu investieren, wurde mehr Zeit in Architektur, Anforderungen und Bewertung investiert.
Man könnte sagen: Weniger tippen, mehr entscheiden.
Wie geht es weiter?
Das gesamte Projekt habe ich hier auf GitHub veröffentlicht:
get-adr/PixelStatus
Download der ersten Version (Firmware / Companion Apps): https://github.com/get-adr/PixelStatus/releases/tag/v0.1.0
Außerdem gibt es schon ein kleines Backlog an neuen Features:
– Companion App mit Unterstützung für MS Teams Status per Graph API
– Version mit ESP32 für Bluetooth Anbindung und / oder Matter
Schreibe einen Kommentar