Codificación de Vibraciones con IA y Arduinos

La codificación por vibras se ha convertido en una palabra de moda popular en el espacio de la IA y últimamente ha adquirido muchos significados diferentes. En este artículo, vamos a mostrarte cómo funciona la codificación por vibras con hardware real conectado a tu Agente de IA. Para evitar confusiones, definiremos la codificación por vibras como "charlar de ida y vuelta con tu agente de IA para lograr un resultado deseado específico". Normalmente esto se hace estrictamente por voz, pero para los fines de este artículo, imprimiremos el prompt "hablado" dado al modelo de lenguaje grande (LLM). Estaremos usando Visual Studio Code con Copilot en modo Agente y conectaremos un Arduino Uno R4 al puerto USB de nuestra computadora (conectado a un MacBook en este caso).

Comenzando

Al igual que cualquier humano que inicia un proyecto, es importante comenzar a nuestro agente de IA con el contexto adecuado. En esta captura de pantalla, notarás que tengo Visual Studio Code ejecutándose con mi Copilot justo en el centro de la pantalla.

Observe la indicación inicial: "Tengo un Arduino Uno R4 conectado a mi MacBook aquí. Usando arduino-cli necesito que comuniques y valides que un Arduino está conectado." He resaltado algunas palabras clave importantes que vale la pena notar. Desglosémoslo en dos partes.

Tengo un Arduino Uno R4 conectado a mi MacBook aquí: Estoy comenzando por decirle al LLM exactamente qué dispositivo estoy usando, que está conectado "aquí", y que estoy usando un MacBook. Quizás ya sabe que estoy operando en MacOS pero darle el contexto adicional nunca está de más. Incluso si puede obtener ese contexto del entorno, probablemente requeriría otra búsqueda, algo que se puede evitar. Estos son datos importantes para comenzar.

Usando arduino-cli necesito que comuniques y valides que un Arduino está conectado: te estoy dando instrucciones explícitas sobre qué herramienta/comando usar (paquete arduino-cli instalado usando brew). Esto, de nuevo, crea un atajo evitando al menos (si no muchos) búsquedas/llamadas para averiguar qué herramienta usar. También soy escéptico de si la herramienta puede configurarse correctamente si se le da la tarea completa, así que le pido que confirme que puede comunicarse con el Arduino. Esto puede parecer trivial, pero es extremadamente útil separarlo de la tarea actual para que podamos asegurarnos de que estamos listos para comenzar una vez que empecemos a escribir código.

Su respuesta es ejecutar inmediatamente el comando arduino-cli (buscando primero la ubicación) para asegurar que todo con la herramienta Arduino y la comunicación con la placa esté configurada correctamente. Una vez que confirmo que todo está en orden, estoy listo para darle el siguiente conjunto de instrucciones, pero me adelanta creando un boceto básico y asegurándose de que puede subir un programa básico al dispositivo:

Como puedes ver en el registro, hay algunos problemas con los que se encuentra el Agente Copiloto. No te preocupes, uno de los aspectos más destacados del flujo de trabajo agente es que puede "autocorregirse" al observar la salida de error y corregirse a sí mismo. Finalmente, lo hace y carga un boceto compilado exitosamente en el dispositivo Arduino Uno R4.

Vibe Coding with Feedback

Cuando se trata de la codificación de la vibra genérica de aplicaciones web, es bastante fácil para el agente obtener retroalimentación. Asumiendo que el agente tiene acceso a la línea de comandos (lo cual es el caso en nuestra situación), puede hacer que la aplicación proporcione retroalimentación después de que el script se haya completado. Tomemos un ejemplo trivial donde le pedimos a nuestro agente que escriba una aplicación que lea un archivo CSV, convierta el contenido en una tabla de markdown y luego escriba el contenido en un archivo .md. Hay un par de maneras de validar que el script funcionó. El enfoque más común sería escribir pruebas (algo que el agente puede hacer fácilmente) o el agente simplemente puede verificar la existencia del nuevo archivo y revisar el contenido del archivo. Una aplicación web con un front end podría funcionar de manera similar también. El Agente puede realizar una operación curl en la página web y leer el contenido HTML. En un ejemplo donde solo hemos escrito un backend web, podemos hacer que el agente escriba pruebas o también realice solicitudes curl y verifique los códigos de respuesta, el texto del cuerpo, etc.

Cuando se trata de Sistemas Embebidos, la validación (especialmente durante el arranque de la placa) típicamente ocurre de manera visual o a través de una serie de chequeos manuales. Considera la forma más primitiva de validar un ejemplo de LED parpadeante mirando visualmente el LED y verificando que parpadee. Introducir señales en un ADC y observar la telemetría que sale usualmente no se scriptea de manera automatizada desde el principio - eso generalmente viene después, una vez que hemos escrito pruebas automatizadas. Cuando programamos con un flujo de trabajo agente para sistemas embebidos, necesitamos incorporar la telemetría como un mecanismo de retroalimentación. El agente no sabrá si el código está funcionando ya que no puede mirar el LED (al menos no con las tecnologías agentes de hoy en día). Aquí es donde es importante enfatizar que genera algo que podemos leer a través de la línea de comandos y validarlo:

En este punto crea un ejemplo que no solo enciende el LED sino que también proporciona telemetría a través de la salida serial indicando “LED_ON” y “LED_OFF”. También sabe automáticamente cómo recuperar estas respuestas:

Un problema común con este tipo de solicitud (también encontrado con solicitudes de comandos “SSH”) es que el proceso nunca terminará después de que el agente emita el comando dentro del terminal. El monitor de Arduino CLI se ejecutará indefinidamente, lo que significa que el agente se colgará para siempre. Es bastante lógico suponer que se introducirá algún tipo de tiempo de espera en los agentes en futuras actualizaciones, pero en este ejemplo, con este flujo de trabajo, eso no existe. Tengo que informar al agente de que su terminal se colgó y necesita tenerlo en cuenta:

Y con eso, el comando se corrige y el agente ahora puede continuar iterando en ejemplos de código más sofisticados. A este punto, hemos establecido una manera para que el agente no solo obtenga retroalimentación sobre si el código se compiló y cargó, sino también que se ejecutó correctamente en el dispositivo objetivo.

Conclusión

Iniciar en la codificación de vibraciones para un sistema embebido puede parecer poco intuitivo y a veces incluso como "magia negra". La clave para una sesión de codificación de vibraciones exitosa con un agente y tu dispositivo embebido es asegurar que el agente siempre reciba suficiente retroalimentación. No solo necesita saber que el código se compila/carga, sino también que funciona correctamente en el dispositivo objetivo también. Aunque algunos de estos ejemplos fueron un poco rudimentarios, son la base para el desarrollo más complejo y sofisticado con IA en el bucle y hardware en el bucle. Armado con estos ejemplos y tutoriales, ahora deberías ser capaz de comenzar a escribir, compilar y ejecutar código embebido generado por IA sin siquiera mover un dedo.