Vibe-Coding mit KI und Arduinos

Vibe-Coding ist in letzter Zeit zu einem beliebten Schlagwort im Bereich der KI geworden und hat viele verschiedene Bedeutungen angenommen. In diesem Artikel zeigen wir Ihnen, wie Vibe-Coding mit echter Hardware funktioniert, die an Ihren KI-Agenten angeschlossen ist. Um Verwirrung zu vermeiden, definieren wir Vibe-Coding als „Hin- und Her-Chat mit Ihrem KI-Agenten, um ein bestimmtes gewünschtes Ergebnis zu erzielen.“ Normalerweise wird dies ausschließlich mit der Stimme gemacht, aber für die Zwecke dieses Artikels werden wir die „gesprochenen“ Aufforderungen, die dem großen Sprachmodell (LLM) gegeben werden, ausdrucken. Wir werden Visual Studio Code mit Copilot im Agentenmodus verwenden und einen Arduino Uno R4 in den USB-Port unseres Computers stecken (in diesem Fall an ein MacBook angeschlossen).

Erste Schritte

Wie jeder Mensch, der ein Projekt beginnt, ist es wichtig, unseren KI-Agenten mit dem richtigen Kontext zu starten. In diesem Screenshot werden Sie bemerken, dass ich Visual Studio Code mit meinem Copiloten direkt in der Mitte des Bildschirms laufen habe.

Beachten Sie die anfängliche Aufforderung: „Ich habe ein Arduino Uno R4 angeschlossen an meinen MacBook hier. Mit arduino-cli benötige ich, dass Sie kommunizieren und validieren, dass ein Arduino angeschlossen ist.“ Ich habe einige wichtige Schlüsselwörter hervorgehoben, die beachtenswert sind. Lassen Sie uns das in zwei Teile aufteilen.

Ich habe ein Arduino Uno R4 angeschlossen an meinen MacBook hier: Zuerst erkläre ich dem LLM genau, welches Gerät ich benutze, dass es „hier“ angeschlossen ist und dass ich einen MacBook verwende. Vielleicht weiß es bereits, dass ich MacOS verwende, aber zusätzlichen Kontext zu geben, schadet nie. Selbst wenn es diesen Kontext aus der Umgebung ziehen könnte, würde es wahrscheinlich eine weitere Abfrage erfordern – etwas, das vermieden werden kann. Diese Informationen sind wichtig, um einen Startpunkt zu haben.

Mit arduino-cli benötige ich von dir, dass du kommunizierst und validierst, dass ein Arduino angeschlossen ist: Ich gebe ihm explizite Anweisungen, welches Werkzeug/Befehl zu verwenden ist (arduino-cli Paket installiert mit brew). Dies schafft erneut eine Abkürzung, um zumindest (wenn nicht viele) Suchvorgänge/Anrufe zu vermeiden, um herauszufinden, welches Werkzeug zu verwenden ist. Ich bin auch skeptisch, ob das Werkzeug sich korrekt konfigurieren kann, wenn es die vollständige Aufgabe erhält, also bitte ich es zu bestätigen, dass es mit dem Arduino kommunizieren kann. Das mag trivial erscheinen, aber es ist äußerst hilfreich, sich von der eigentlichen Aufgabe zu lösen, damit wir sicher sein können, dass wir bereit sind, sobald wir anfangen, Code zu schreiben.

Seine Antwort besteht darin, sofort den arduino-cli Befehl auszuführen (indem zuerst nach dem Standort gesucht wird), um sicherzustellen, dass alles mit dem Arduino-Werkzeug und der Kommunikation zum Board ordnungsgemäß konfiguriert ist. Sobald ich bestätige, dass alles in Ordnung ist, bin ich bereit, ihm den nächsten Satz von Anweisungen zu geben, aber es kommt mir zuvor, indem es einen grundlegenden Sketch erstellt und sicherstellt, dass es ein einfaches Programm auf das Gerät hochladen kann:

Wie Sie im Protokoll sehen können, gibt es einige Probleme, auf die der Copilot Agent stößt. Keine Sorge - einer der schönen Aspekte des agentischen Workflows ist, dass er sich durch Betrachten der Fehlerausgabe „selbst heilen“ und sich korrigieren kann. Letztendlich tut er dies und lädt erfolgreich einen kompilierten Sketch auf das Arduino Uno R4 Gerät hoch.

Vibe Coding mit Feedback

Wenn es um die generische Vibe-Codierung von Webanwendungen geht, ist es für den Agenten ziemlich einfach, Feedback zu erhalten. Vorausgesetzt, der Agent hat Zugriff auf die Befehlszeile (was in unserem Fall zutrifft), kann er die Anwendung Feedback geben lassen, nachdem das Skript abgeschlossen ist. Nehmen wir ein einfaches Beispiel, bei dem wir unseren Agenten bitten, eine Anwendung zu schreiben, die eine CSV-Datei einliest, den Inhalt in eine Markdown-Tabelle umwandelt und dann den Inhalt in eine .md-Datei schreibt. Es gibt ein paar Möglichkeiten, um zu überprüfen, ob das Skript funktioniert hat. Der häufigste Ansatz wäre, Tests zu schreiben (etwas, das der Agent leicht tun kann), oder der Agent kann einfach nach der Existenz der neuen Datei suchen und den Inhalt der Datei überprüfen. Eine Webanwendung mit einem Frontend könnte auf ähnliche Weise funktionieren. Der Agent kann eine Curl-Operation auf der Webseite durchführen und den HTML-Inhalt auslesen. In einem Beispiel, in dem wir nur ein Web-Backend geschrieben haben, kann der Agent Tests schreiben oder auch Curl-Anfragen durchführen und auf die Antwortcodes, den Textkörper usw. überprüfen.

Wenn es um eingebettete Systeme geht, erfolgt die Validierung (insbesondere beim Hochfahren der Platine) typischerweise visuell oder durch eine Reihe manueller Überprüfungen. Betrachten Sie die primitivste Art der Validierung eines blinkenden LED-Beispiels, indem Sie visuell auf die LED schauen und verifizieren, dass sie blinkt. Signale in einen ADC zu treiben und die daraus resultierende Telemetrie zu betrachten, wird normalerweise nicht von Anfang an automatisiert skriptiert - das kommt in der Regel später, sobald wir automatisierte Tests geschrieben haben. Wenn wir mit einem agentenbasierten Workflow für eingebettete Systeme vibrierend codieren, müssen wir Telemetrie als Feedbackmechanismus einbauen. Der Agent wird nicht wissen, ob der Code funktioniert, da er die LED nicht sehen kann (zumindest nicht mit den heutigen agentenbasierten Technologien). Hier ist es wichtig zu betonen, dass es etwas erzeugt, das wir über die Befehlszeile lesen und validieren können:

Zu diesem Zeitpunkt erstellt es ein Beispiel, das nicht nur die LED einschaltet, sondern auch Telemetrie über die serielle Ausgabe liefert, die „LED_ON“ und „LED_OFF“ angibt. Es weiß auch automatisch, wie diese Antworten abgerufen werden können:

Ein häufiges Problem bei dieser Art von Anfrage (auch bei „SSH“-Befehlsanfragen zu finden) ist, dass der Prozess nie beendet wird, nachdem der Agent den Befehl im Terminal ausgeführt hat. Der Arduino CLI-Monitor läuft unendlich weiter, was bedeutet, dass der Agent für immer hängen bleibt. Es ist ziemlich logisch anzunehmen, dass in zukünftigen Updates irgendeine Art von Timeout in die Agenten eingeführt wird, aber in diesem Beispiel, mit diesem Workflow, existiert das nicht. Ich muss den Agenten informieren, dass sein Terminal hängengeblieben ist und er das berücksichtigen muss:

Und damit ist der Befehl korrigiert und der Agent kann nun weiterhin an komplexeren Codebeispielen arbeiten. Bis zu diesem Punkt haben wir eine Möglichkeit etabliert, wie der Agent nicht nur Feedback darüber erhalten kann, ob der Code kompiliert und hochgeladen wurde, sondern auch, dass er korrekt auf dem Zielgerät ausgeführt wurde.

Schlussfolgerung

Der Einstieg in die Vibe-Codierung für ein eingebettetes System mag zunächst unintuitiv und manchmal sogar wie "schwarze Magie" erscheinen. Der Schlüssel zu einer erfolgreichen Vibe-Coding-Sitzung mit einem Agenten und Ihrem eingebetteten Gerät besteht darin, sicherzustellen, dass der Agent immer ausreichendes Feedback erhält. Es muss nicht nur wissen, dass der Code kompiliert/hochgeladen wird, sondern auch, dass er korrekt auf dem Zielgerät funktioniert. Auch wenn einige dieser Beispiele ein wenig rudimentär waren, bilden sie die Grundlage für komplexere, ausgefeiltere Entwicklungen mit KI-im-Loop und Hardware-im-Loop. Mit diesen Beispielen und Anleitungen sollten Sie jetzt in der Lage sein, ohne einen Finger zu rühren, KI-generierten eingebetteten Code zu schreiben, zu kompilieren und auszuführen.