Codificação de Vibrações com AI e Arduinos

Ari Mahpour
|  Criada: Maio 30, 2025
Codificação de Vibrações com AI e Arduinos

A codificação de vibração tornou-se uma palavra de ordem popular no espaço da IA e ultimamente adquiriu muitos significados diferentes. Neste artigo, vamos mostrar como a codificação de vibração funciona com hardware real conectado ao seu Agente de IA. Para evitar confusão, definiremos codificação de vibração como "conversar de ida e volta com seu agente de IA para alcançar um determinado resultado desejado." Normalmente, isso é feito estritamente por voz, mas para os propósitos deste artigo, vamos imprimir o prompt "falado" dado ao modelo de linguagem de grande escala (LLM). Estaremos usando o Visual Studio Code com Copilot no modo Agente e conectaremos um Arduino Uno R4 na porta USB do nosso computador (conectado a um MacBook neste caso).

Começando

Assim como qualquer humano iniciando um projeto, é importante começar nosso agente de IA com o contexto adequado. Nesta captura de tela, você notará que tenho o Visual Studio Code rodando com meu Copilot bem no centro da tela.

Figure 1: Screenshot of initial discussion with Copilot Agent
Figura 1: Captura de tela da discussão inicial com o Agente Copilot

Observe o prompt inicial: “Eu tenho um Arduino Uno R4 conectado ao meu MacBook aqui. Usando arduino-cli, preciso que você comunique e valide que um Arduino está conectado.” Eu destaquei algumas palavras-chave importantes que valem a pena notar. Vamos dividir isso em duas partes.

Eu tenho um Arduino Uno R4 conectado ao meu MacBook aqui: Estou começando por informar ao LLM exatamente qual dispositivo estou usando, que está conectado "aqui", e que estou usando um MacBook. Talvez ele já saiba que estou rodando no MacOS, mas dar esse contexto extra nunca é demais. Mesmo que possa obter esse contexto do ambiente, provavelmente exigiria outra consulta — algo que pode ser evitado. Essas são informações importantes para começar.

Usando arduino-cli, preciso que você comunique e valide que um Arduino está conectado: Estou dando instruções explícitas sobre qual ferramenta/comando usar (pacote arduino-cli instalado usando brew). Isso, novamente, cria um atalho evitando pelo menos (se não muitas) buscas/chamadas para descobrir qual ferramenta usar. Também estou cético sobre se a ferramenta pode se configurar corretamente se receber a tarefa completa, então peço que confirme se pode se comunicar com o Arduino. Isso pode parecer trivial, mas é extremamente útil separar isso da tarefa real para que possamos garantir que estamos prontos para começar a escrever o código.

Sua resposta é executar imediatamente o comando arduino-cli (procurando primeiro a localização) para garantir que tudo com a ferramenta Arduino e a comunicação com a placa esteja configurada corretamente. Uma vez que confirmo que tudo está funcionando, estou pronto para dar o próximo conjunto de instruções, mas ele me antecipa criando um esboço básico e garantindo que pode carregar um programa básico no dispositivo:

Figure 2: Copilot attempting to create, compile, and upload a new sketch
Figura 2: Copilot tentando criar, compilar e carregar um novo esboço

Como você pode ver no registro, existem alguns problemas com os quais o Agente Copiloto se depara. Sem preocupações - um dos aspectos mais interessantes do fluxo de trabalho agente é que ele pode "se curar" ao analisar a saída de erro e corrigir-se. No final das contas, ele consegue e faz o upload de um esboço compilado com sucesso para o dispositivo Arduino Uno R4.

Vibe Coding with Feedback

Quando se trata de codificação de vibração genérica de aplicações web, é bastante fácil para o agente obter feedback. Assumindo que o agente tenha acesso à linha de comando (o que acontece no nosso caso), ele pode fazer com que a aplicação forneça feedback após a conclusão do script. Pegue um exemplo trivial onde pedimos ao nosso agente para escrever uma aplicação que lê um arquivo CSV, converte o conteúdo em uma tabela markdown e, em seguida, escreve o conteúdo em um arquivo .md. Existem algumas maneiras de validar que o script funcionou. A abordagem mais comum seria escrever testes (algo que o agente pode fazer facilmente) ou o agente pode simplesmente verificar a existência do novo arquivo e revisar o conteúdo do arquivo. Uma aplicação web com uma interface também poderia funcionar de maneira semelhante. O Agente pode realizar uma operação curl na página web e ler o conteúdo HTML. Em um exemplo onde só escrevemos um backend web, podemos fazer com que o agente escreva testes ou também realize solicitações curl e verifique os códigos de resposta, texto do corpo, etc.

Quando se trata de Sistemas Embarcados, a validação (especialmente durante a inicialização da placa) normalmente acontece visualmente ou por meio de uma série de verificações manuais. Considere a maneira mais primitiva de validar um exemplo de LED piscante, olhando visualmente para o LED e verificando se ele pisca. Inserir sinais em um ADC e observar a telemetria resultante geralmente não é scriptado de forma automatizada desde o início - isso geralmente vem mais tarde, uma vez que escrevemos testes automatizados. Quando estamos codificando com um fluxo de trabalho agente para sistemas embarcados, precisamos incorporar a telemetria como um mecanismo de feedback. O agente não saberá se o código está funcionando, pois ele não pode olhar para o LED (pelo menos não com as tecnologias agentes de hoje). É aqui que é importante enfatizar que ele gera algo que podemos ler via linha de comando e validar:

Figure 3: Request to create an example with telemetry and validation
Figura 3: Solicitação para criar um exemplo com telemetria e validação

Neste ponto, ele cria um exemplo que não apenas aciona o LED, mas também fornece telemetria pela saída serial indicando “LED_ON” e “LED_OFF”. Ele automaticamente sabe como recuperar essas respostas também:

Figure 4: Telemetry over serial but with open-ended process
Figura 4: Telemetria via serial, mas com processo aberto

Um problema comum com esse tipo de solicitação (também encontrado com solicitações de comando “SSH”) é que o processo nunca terminará após o agente emitir o comando dentro do terminal. O monitor do Arduino CLI continuará funcionando indefinidamente, o que significa que o agente ficará pendurado para sempre. É bastante lógico supor que algum tipo de tempo limite será introduzido nos agentes em futuras atualizações, mas neste exemplo, com este fluxo de trabalho, isso não existe. Eu tenho que informar ao agente que seu terminal travou e ele precisa levar isso em conta:

Figure 5: Fix for hung terminal
Figura 5: Correção para terminal travado

E com isso o comando é corrigido e o agente agora pode continuar a iterar em exemplos de código mais sofisticados. Até este ponto, estabelecemos uma maneira do agente não apenas receber feedback sobre se o código foi compilado e carregado, mas também que ele funcionou corretamente no dispositivo alvo.

Conclusão

Iniciar-se na codificação de vibrações para um sistema embutido pode parecer contra-intuitivo e, às vezes, até mesmo "magia negra". A chave para uma sessão de codificação de vibrações bem-sucedida com um agente e seu dispositivo embutido é garantir que o agente sempre receba feedback suficiente. Não basta apenas saber que o código compila/carrega, mas também que funciona corretamente no dispositivo alvo. Embora alguns desses exemplos tenham sido um pouco rudimentares, eles são a base para o desenvolvimento mais complexo e sofisticado com AI-in-the-loop e hardware-in-the-loop. Armado com esses exemplos e tutoriais, você agora deve ser capaz de começar a escrever, compilar e executar código embutido gerado por IA sem sequer levantar um dedo.

Sobre o autor

Sobre o autor

Ari is an engineer with broad experience in designing, manufacturing, testing, and integrating electrical, mechanical, and software systems. He is passionate about bringing design, verification, and test engineers together to work as a cohesive unit.

Recursos relacionados

Retornar a página inicial
Thank you, you are now subscribed to updates.