Codage de vibrations avec l'IA et les Arduinos

Le codage par vibration est devenu un terme à la mode dans l'espace de l'IA et il a pris de nombreuses significations différentes dernièrement. Dans cet article, nous allons vous montrer comment fonctionne le codage par vibration avec du vrai matériel connecté à votre agent IA. Afin d'éviter toute confusion, nous définirons le codage par vibration comme « discuter aller-retour avec votre agent IA afin d'atteindre un certain résultat souhaité. » Normalement, cela se fait strictement par la voix mais pour les besoins de cet article, nous imprimerons l'invite « parlée » donnée au modèle de langage de grande taille (LLM). Nous utiliserons Visual Studio Code avec Copilot en mode Agent et brancherons un Arduino Uno R4 dans le port USB de notre ordinateur (attaché à un MacBook dans ce cas).

Commencer

Tout comme tout humain commençant un projet, il est important de commencer notre agent IA avec le contexte approprié. Dans cette capture d'écran, vous remarquerez que j'ai Visual Studio Code en cours d'exécution avec mon Copilot juste au centre de l'écran.

Remarquez la consigne initiale : « J'ai un Arduino Uno R4 connecté à mon MacBook ici. En utilisant arduino-cli, j'ai besoin que vous communiquiez et validiez qu'un Arduino est connecté. » J'ai mis en gras quelques mots-clés importants qui méritent d'être notés. Décortiquons cela en deux parties.

J'ai un Arduino Uno R4 connecté à mon MacBook ici : je commence par dire exactement à la LLM quel appareil j'utilise, qu'il est connecté « ici », et que j'utilise un MacBook. Peut-être qu'elle sait déjà que je fonctionne sous MacOS mais donner ce contexte supplémentaire ne fait jamais de mal. Même si elle peut tirer ce contexte de l'environnement, cela nécessiterait probablement une autre recherche—quelque chose qui peut être évité. Ce sont des informations importantes pour bien commencer.

En utilisant arduino-cli, j'ai besoin que vous communiquiez et validiez qu'un Arduino est connecté : je lui donne des instructions explicites sur quel outil/commande utiliser (le paquet arduino-cli installé via brew). Cela, encore une fois, crée un raccourci en évitant au moins (sinon de nombreux) recherches/appels pour déterminer quel outil utiliser. Je suis également sceptique quant à la capacité de l'outil à se configurer correctement s'il reçoit la tâche complète, donc je lui demande de confirmer qu'il peut communiquer avec l'Arduino. Cela peut sembler trivial, mais c'est extrêmement utile pour se détacher de la tâche réelle afin que nous puissions nous assurer que tout est prêt avant de commencer à écrire du code.

Sa réponse est d'exécuter immédiatement la commande arduino-cli (en cherchant d'abord l'emplacement) pour s'assurer que tout est correctement configuré avec l'outil Arduino et la communication avec la carte. Une fois que j'ai confirmé que tout fonctionne correctement, je suis prêt à lui donner le prochain ensemble d'instructions, mais il me devance en créant un croquis de base et en s'assurant qu'il peut téléverser un programme de base sur l'appareil :

Comme vous pouvez le voir dans le journal, il y a quelques problèmes auxquels l'agent Copilot est confronté. Pas de souci - l'un des aspects remarquables du flux de travail agentic est qu'il peut s'auto-réparer en examinant la sortie d'erreur et se corriger lui-même. En fin de compte, il réussit et télécharge un croquis compilé avec succès sur le dispositif Arduino Uno R4.

Vibe Coding with Feedback

Lorsqu'il s'agit de coder l'ambiance générale des applications web, il est assez facile pour l'agent de recevoir des retours. En supposant que l'agent ait accès à la ligne de commande (ce qui est le cas dans notre situation), il peut faire en sorte que l'application fournisse un retour après que le script soit terminé. Prenons un exemple simple où nous demandons à notre agent d'écrire une application qui lit un fichier CSV, convertit le contenu en un tableau markdown, puis écrit le contenu dans un fichier .md. Il y a plusieurs façons de valider que le script a fonctionné. L'approche la plus courante serait d'écrire des tests (quelque chose que l'agent peut facilement faire) ou l'agent peut simplement vérifier l'existence du nouveau fichier et examiner le contenu du fichier. Une application web avec une interface utilisateur pourrait fonctionner de manière similaire également. L'agent peut effectuer une opération curl sur la page web et lire le contenu HTML. Dans un exemple où nous avons seulement écrit un backend web, nous pouvons demander à l'agent d'écrire des tests ou également effectuer des requêtes curl et vérifier les codes de réponse, le texte du corps, etc.

Lorsqu'il s'agit de systèmes embarqués, la validation (surtout lors de la mise en service de la carte) se fait généralement visuellement ou à travers une série de vérifications manuelles. Considérez la manière la plus primitive de valider un exemple de LED clignotante en regardant visuellement la LED et en vérifiant qu'elle clignote. Envoyer des signaux dans un ADC et regarder la télémétrie sortante n'est généralement pas scripté de manière automatisée dès le début - cela vient généralement plus tard une fois que nous avons écrit des tests automatisés. Lors de la programmation vibreuse avec un flux de travail agentique pour les systèmes embarqués, nous devons intégrer la télémétrie comme mécanisme de retour. L'agent ne saura pas si le code fonctionne puisqu'il ne peut pas regarder la LED (du moins pas avec les technologies agentiques d'aujourd'hui). C'est là qu'il est important de souligner qu'il génère quelque chose que nous pouvons lire via la ligne de commande et valider :

À ce stade, il crée un exemple qui non seulement allume la LED mais fournit également de la télémétrie sur la sortie série indiquant « LED_ON » et « LED_OFF ». Il sait automatiquement comment récupérer ces réponses également :

Un problème courant avec ce type de demande (également rencontré avec les demandes de commande "SSH") est que le processus ne se terminera jamais après que l'agent ait émis la commande dans le terminal. Le moniteur CLI Arduino fonctionnera indéfiniment, ce qui signifie que l'agent restera bloqué pour toujours. Il est assez logique de supposer qu'une sorte de délai d'attente sera introduit dans les agents lors des mises à jour futures, mais dans cet exemple, avec ce flux de travail, cela n'existe pas. Je dois informer l'agent que son terminal est bloqué et qu'il doit en tenir compte :

Et avec cela, la commande est corrigée et l'agent peut maintenant continuer à itérer sur des exemples de code plus sophistiqués. À ce stade, nous avons établi une manière pour l'agent de non seulement obtenir un retour sur le fait que le code a été compilé et téléchargé, mais aussi qu'il s'est exécuté correctement sur le dispositif cible.

Conclusion

Se lancer dans la programmation de vibrations pour un système embarqué peut sembler contre-intuitif et parfois même relever de la "magie noire". La clé d'une session de codage de vibrations réussie avec un agent et votre dispositif embarqué est de s'assurer que l'agent reçoit toujours suffisamment de retours. Il doit non seulement savoir que le code se compile/se téléverse, mais aussi qu'il fonctionne correctement sur le dispositif cible également. Bien que certains de ces exemples aient été un peu rudimentaires, ils constituent la base pour un développement plus complexe et sophistiqué avec IA en boucle et matériel en boucle. Armé de ces exemples et de ces tutoriels, vous devriez maintenant être capable de commencer à écrire, compiler et exécuter du code embarqué généré par IA sans même lever le petit doigt.