Usar un asistente de IA para programar ESP32: el flujo que funciona

Claude Code, Codex y Gemini hacen aquí lo mismo

Los tres asistentes de IA más utilizados hoy en una mesa de trabajo con ESP32 son Claude Code, Codex y Gemini, y los ejemplos de este artículo sirven para los tres por igual. La limitación de la que hablamos no es de un modelo concreto, sino de cualquier asistente que conversa por texto.

Un asistente de IA lee tu código, el mensaje de error que pegaste y la documentación que ya conoce. No tiene puerto serie, osciloscopio ni forma de saber si el LED de tu placa está en GPIO 2 o GPIO 8, a menos que se lo digas.

No es un defecto, es la naturaleza de la herramienta: es buena generando código plausible a partir de patrones, y el código embebido plausible puede fallar de formas que solo aparecen sobre el hardware real. Un platformio.ini con la placa equivocada compila sin avisos. Un GPIO inventado compila sin avisos. Una condición de carrera en loop() compila sin avisos.

Mientras el componente no habla, el diagnóstico es una suposición

La regla sirve para cualquier diagnóstico, humano o de IA. Pedir al asistente que adivine por qué la placa se reinició sola sin pegar el registro del monitor serie es pedir una hipótesis, no una respuesta. Es válido como primera conjetura, pero no como respuesta aceptada sin confirmarla en la placa.

Lo que no es

No es un sustituto de la prueba en la mesa ni un oráculo de datasheets. Los asistentes de IA se equivocan con valores de registros, nombres de macros y pines de periféricos con la misma seguridad con la que aciertan. El texto resulta fluido en ambos casos y fluidez no significa exactitud. Toda afirmación sobre el comportamiento del hardware hecha antes de ejecutar nada es una hipótesis, no un hecho.

Lo que realmente facilita: construir, no solo corregir

El mismo asistente también escribe firmware nuevo a partir de una conversación sin que tengas que escribir la primera línea, y ahí es donde más tiempo ahorra.

El firmware de este kit nació así: tres peticiones breves en un chat. Primero, "haz parpadear el LED integrado del ESP32 cada segundo". Después, "añade dos comandos en el monitor serie, RAPIDO y LENTO, que cambien el intervalo del parpadeo sin bloquear el resto del programa". Por último, "añade un comando STATUS que muestre cuánto tiempo lleva encendida la placa y cuál es el intervalo actual". Cada petición se compiló y probó en la placa antes de hacer la siguiente.

No se escribió ninguna línea a mano y el resultado usa millis() en lugar de un delay() sin control, porque la restricción "sin bloquear el resto del programa" ya guiaba la respuesta. Pedir bien elimina una clase completa de errores.

Lo que habría requerido una tarde de referencias y ensayo se convirtió en tres rondas de pocos minutos. El límite sigue siendo el mismo: compilar no es probar; probar es conectar la placa y observarla. Pero dentro de ese límite, el asistente elimina el trabajo repetitivo.

Contexto primero, código después

Si el proyecto tiene convenciones propias, como nombres de pines, biblioteca preferida o versión del framework, indícalas antes de pedir la primera línea. Sin contexto, el asistente rellena los huecos con el ejemplo más común de Internet, que puede no ser el tuyo.

El cambio pequeño que resuelve el paso actual

Cambiar delay() por millis() en una función es una revisión que puedes comprobar en treinta segundos. Pedir que reescriba todo el firmware de una vez es pedir un error que tardará una tarde en encontrarse, porque nadie revisa diez cambios simultáneos con la misma atención.

Lee toda la salida, no solo el resultado

La primera línea roja del compilador explica la causa; la última casi nunca. Esto vale tanto para el error que lees tú como para el que pegas al asistente. Pegar solo la última línea es pegar la parte menos útil.

Graba la placa antes de hacer la siguiente petición

Aquí se rompen la mayoría de los flujos de "programar con IA": pedir la siguiente función sin confirmar que la anterior hizo lo que debía en la placa real y no solo en el editor. Cada petición atendida es un punto de control; avanza solo después de verla funcionar.

Pega la salida real, no su resumen

"Tuvo un error de compilación" es muy poca información. Pegar el bloque completo de la terminal, o el fragmento del monitor serie, hace que la siguiente sugerencia trate tu error y no el error más común con ese nombre.

Una petición débil y una que funciona

Débil: "¿por qué mi ESP32 se reinicia solo?" El asistente enumerará las causas más comunes de reinicio en ESP32, watchdog, desbordamiento de pila, brownout y asignación de memoria, porque es todo lo que tiene para trabajar. Es una lista genérica, no un diagnóstico.

Funciona: pega el registro real del monitor serie, incluida la línea de Guru Meditation Error o el rst:0x... del bootloader, y explica qué ya has descartado. El asistente todavía puede equivocarse, pero ahora razona sobre tu reinicio utilizando el único dato que separa "un reinicio" de "este reinicio concreto": lo que dijo la placa antes de caer.

El límite que permanece

Ningún asistente resuelve por sí solo el problema que aparece únicamente bajo carga, en producción y después de horas, porque ningún texto de log contiene todo lo que ocurrió antes del fallo. Eso sigue requiriendo instrumentación: logs estructurados, contador de heap y timestamp de cada reconexión. El asistente ayuda a escribir esa instrumentación más rápido. No sustituye la decisión de que debe existir.