Codifica Vibe con AI e Arduino

| Creato: maggio 30, 2025

Il "vibe coding" è diventato un termine di tendenza nello spazio dell'IA e ultimamente ha assunto molti significati diversi. In questo articolo, vi mostreremo come funziona il vibe coding con hardware reale collegato al vostro Agente IA. Per evitare confusione, definiremo il vibe coding come "dialogare avanti e indietro con il vostro agente IA al fine di ottenere un certo risultato desiderato". Normalmente ciò viene fatto strettamente a voce ma, ai fini di questo articolo, stamperemo il prompt "parlato" dato al modello di linguaggio avanzato (LLM). Utilizzeremo Visual Studio Code con Copilot in modalità Agente e collegheremo un Arduino Uno R4 alla porta USB del nostro computer (collegato in questo caso a un MacBook).

Iniziare

Proprio come qualsiasi umano che inizia un progetto, è importante iniziare il nostro agente IA con il contesto appropriato. In questa schermata, noterete che ho Visual Studio Code in esecuzione con il mio Copilot proprio al centro dello schermo.

Figure 1: Screenshot of initial discussion with Copilot Agent — *Figura 1: Screenshot della discussione iniziale con l'Agente Copilot*

Notate la richiesta iniziale: "Ho un Arduino Uno R4 collegato al mio MacBook qui. Utilizzando arduino-cli ho bisogno che tu comunichi e validi che un Arduino è collegato." Ho evidenziato alcune parole chiave importanti che vale la pena notare. Spezziamola in due parti.

Ho un Arduino Uno R4 collegato al mio MacBook qui: sto iniziando dicendo esattamente al LLM quale dispositivo sto usando, che è collegato "qui" e che sto usando un MacBook. Forse sa già che sto utilizzando MacOS ma dare un contesto aggiuntivo non guasta mai. Anche se potrebbe ricavare quel contesto dall'ambiente, probabilmente richiederebbe un'altra ricerca—qualcosa che può essere evitato. Queste sono informazioni importanti per iniziare.

Utilizzando arduino-cli ho bisogno che tu comunichi e validi che un Arduino sia collegato: sto fornendo istruzioni esplicite su quale strumento/comando utilizzare (pacchetto arduino-cli installato tramite brew). Questo, di nuovo, crea una scorciatoia evitando almeno (se non molti) ricerche/chiamate per capire quale strumento utilizzare. Sono anche scettico sul fatto che lo strumento possa configurarsi correttamente se gli viene assegnato l'intero compito, quindi chiedo di confermare che può comunicare con l'Arduino. Questo potrebbe sembrare banale, ma è estremamente utile separarsi dall'attività effettiva così possiamo assicurarci di essere pronti a procedere una volta iniziata la scrittura del codice.

La sua risposta è di eseguire immediatamente il comando arduino-cli (cercando prima la posizione) per assicurare che tutto riguardo lo strumento Arduino e la comunicazione con la scheda sia configurato correttamente. Una volta confermato che tutto è in ordine, sono pronto a fornirgli il prossimo set di istruzioni ma mi anticipa creando uno sketch di base e assicurandosi che possa caricare un programma di base sul dispositivo:

Figure 2: Copilot attempting to create, compile, and upload a new sketch — *Figura 2: Copilot tenta di creare, compilare e caricare un nuovo sketch*

Come puoi vedere nel registro, ci sono alcuni problemi in cui l'Agente Copilota si imbatte. Nessun problema - uno degli aspetti meravigliosi del flusso di lavoro agente è che può "auto-ripararsi" esaminando l'output dell'errore e correggersi da solo. In ultima analisi, ci riesce e carica con successo uno sketch compilato sul dispositivo Arduino Uno R4.

Vibe Coding con Feedback

Quando si tratta di codifica di vibrazioni generiche di applicazioni web, è abbastanza facile per l'agente ottenere feedback. Supponendo che l'agente abbia accesso alla riga di comando (come nel nostro caso), può far fornire feedback dall'applicazione dopo che lo script è stato completato. Prendiamo un esempio banale in cui chiediamo al nostro agente di scrivere un'applicazione che legge un file CSV, converte il contenuto in una tabella markdown e poi scrive il contenuto in un file .md. Ci sono un paio di modi per validare che lo script abbia funzionato. L'approccio più comune sarebbe scrivere dei test (cosa che l'agente può fare facilmente) oppure l'agente può semplicemente controllare l'esistenza del nuovo file e rivedere il contenuto del file. Un'applicazione web con un front end potrebbe funzionare in modo simile. L'Agente può eseguire un'operazione curl sulla pagina web e leggere il contenuto HTML. In un esempio in cui abbiamo scritto solo un backend web, possiamo far scrivere dei test all'agente o eseguire anche richieste curl e controllare i codici di risposta, il testo del corpo, ecc.

Quando si tratta di Sistemi Embedded, la validazione (specialmente durante l'avvio della scheda) avviene tipicamente in modo visivo o attraverso una serie di controlli manuali. Considerate il modo più primitivo di validare un esempio di LED lampeggiante osservando visivamente il LED e verificando che lampeggi. Inviare segnali in un ADC e osservare la telemetria in uscita di solito non è automatizzato fin dall'inizio - ciò avviene generalmente più tardi, una volta che abbiamo scritto test automatizzati. Quando si programma in modo vibrazionale con un flusso di lavoro agente per i sistemi embedded, dobbiamo integrare la telemetria come meccanismo di feedback. L'agente non saprà se il codice sta funzionando poiché non può guardare il LED (almeno non con le tecnologie agentiche di oggi). Qui è importante sottolineare che genera qualcosa che possiamo leggere tramite la riga di comando e validarlo:

Figure 3: Request to create an example with telemetry and validation — *Figura 3: Richiesta di creare un esempio con telemetria e validazione*

In questo punto crea un esempio che non solo accende il LED ma fornisce anche telemetria sull'uscita seriale indicando "LED_ON" e "LED_OFF". Sa automaticamente come recuperare queste risposte anche:

Figure 4: Telemetry over serial but with open-ended process — *Figura 4: Telemetria su seriale ma con processo aperto*

Un problema comune con questo tipo di richiesta (riscontrato anche con le richieste di comando “SSH”) è che il processo non terminerà mai dopo che l'agente ha emesso il comando all'interno del terminale. Il monitor dell'Arduino CLI continuerà a funzionare all'infinito, il che significa che l'agente rimarrà bloccato per sempre. È abbastanza logico supporre che in futuro verrà introdotto qualche tipo di timeout negli agenti, ma in questo esempio, con questo flusso di lavoro, ciò non esiste. Devo informare l'agente che il suo terminale si è bloccato e che deve tenerne conto:

Figure 5: Fix for hung terminal — *Figura 5: Correzione per il terminale bloccato*

E con ciò il comando è corretto e l'agente può ora continuare a iterare su esempi di codice più sofisticati. A questo punto abbiamo stabilito un modo per l'agente non solo di ricevere feedback su se il codice è stato compilato e caricato, ma anche che è stato eseguito correttamente sul dispositivo di destinazione.

Conclusione

Iniziare a programmare vibrazioni per un sistema embedded può sembrare poco intuitivo e a volte persino "magia nera". La chiave per una sessione di programmazione delle vibrazioni di successo con un agente e il tuo dispositivo embedded è assicurarsi che l'agente riceva sempre un feedback sufficiente. Non solo deve sapere che il codice viene compilato/caricato, ma anche che funziona correttamente sul dispositivo di destinazione. Anche se alcuni di questi esempi erano un po' rudimentali, sono la base per sviluppi più complessi e sofisticati con AI nel loop e hardware nel loop. Armato di questi esempi e tutorial, ora dovresti essere in grado di iniziare a scrivere, compilare ed eseguire codice embedded generato dall'AI senza nemmeno muovere un dito.

Sull'Autore

Ari è un ingegnere con una solida esperienza nei campi di progettazione, produzione, collaudo e integrazione di sistemi elettrici, meccanici e software. Ama riunire gli ingegneri addetti alla progettazione, alla verifica e al collaudo e farli lavorare insieme come un'unità affiatata.

Più contenuto di: Ari Mahpour