Usar assistente de IA para programar ESP32: o fluxo que funciona

Claude Code, Codex e Gemini fazem a mesma coisa aqui

Os três assistentes de IA mais usados em bancada de ESP32 hoje são Claude Code, Codex e Gemini, e os exemplos deste artigo valem para os três igualmente — a limitação de que se fala aqui não é de um modelo específico, é de qualquer assistente que conversa por texto.

Um assistente de IA lê o seu código, a mensagem de erro que você colou e a documentação que ele já conhece. Ele não tem porta serial, não tem osciloscópio e não sabe se o LED da sua placa está no GPIO 2 ou no GPIO 8 — a menos que você diga.

Isso não é defeito, é a natureza da ferramenta: ela é boa em gerar código plausível a partir de padrões, e código embarcado plausível ainda assim falha de formas que só aparecem em cima do hardware real. Um platformio.ini com a placa errada compila sem aviso. Um GPIO inventado compila sem aviso. Uma condição de corrida no loop() compila sem aviso.

Enquanto o componente não fala, o diagnóstico é chute

A regra vale para qualquer diagnóstico, humano ou de IA. Pedir para o assistente adivinhar por que a placa reiniciou sozinha, sem colar o log do monitor serial, é pedir uma hipótese, não uma resposta. É válido como primeiro palpite — não como resposta aceita sem confirmar na placa.

O que ele não é

Não é um substituto do teste em bancada, e não é um oráculo de datasheet. Assistentes de IA já erram valor de registrador, nome de macro e pino de periférico com a mesma confiança de quando acertam — o texto sai fluente nos dois casos, e fluência não é a mesma coisa que exatidão. Toda alegação sobre comportamento de hardware que o assistente fizer sem você ter rodado nada ainda é hipótese, não fato.

O que ele facilita de verdade: construir, não só corrigir

O mesmo assistente também escreve firmware novo a partir de uma conversa, sem você digitar a primeira linha — e é aí que ele mais economiza tempo.

O firmware deste kit nasceu assim: três pedidos curtos em chat. Primeiro "pisque o LED onboard do ESP32 a cada segundo". Depois "adicione dois comandos pelo monitor serial, RAPIDO e LENTO, que mudam o intervalo do piscar sem travar o resto do programa". Por fim "adicione um comando STATUS que mostra há quanto tempo a placa está ligada e qual o intervalo atual". Cada pedido foi compilado e testado na placa antes do próximo.

Nenhuma linha foi escrita à mão, e o resultado usa millis() em vez de delay() de saída — sem precisar pedir isso explicitamente, porque a restrição "sem travar o resto do programa" já guiou a resposta. Pedir bem já elimina uma classe inteira de bug.

O que levaria uma tarde de referência e tentativa virou três rodadas de poucos minutos cada. O limite continua o mesmo — compilar não é testar, testar é ligar a placa e ver — mas dentro dele, o assistente tira o trabalho repetitivo do caminho.

Contexto primeiro, código depois

Se o projeto tem convenção própria — nome de pino, biblioteca preferida, versão do framework — diga isso antes de pedir a primeira linha. Um assistente sem contexto preenche os buracos com o exemplo mais comum da internet, que pode não ser o seu.

A mudança menor que resolve o passo atual

Trocar um delay() por millis() numa função é uma revisão que dá pra conferir em trinta segundos. Pedir para reescrever o firmware inteiro de uma vez é pedir por um bug que vai demorar uma tarde para achar, porque ninguém revisa dez mudanças ao mesmo tempo com atenção igual.

Leia a saída inteira, não só o resultado

A primeira linha vermelha do compilador explica a causa; a última quase nunca explica. Isso vale igual para erro lido por você e para erro colado de volta no assistente — colar só a última linha é colar a parte que menos ajuda.

Grave na placa antes do próximo pedido

É aqui que a maioria dos fluxos de "programar com IA" quebra: pedir a próxima função sem ter confirmado que a anterior fez o que devia na placa real, não só no editor. Cada pedido atendido é um checkpoint — só avança depois de ver funcionando.

Cole a saída real, não o resumo dela

"Deu erro de compilação" é informação de menos. Colar o bloco inteiro do terminal — ou o trecho do monitor serial — é o que faz a próxima sugestão do assistente ser sobre o seu erro, e não sobre o erro mais comum que existe com esse nome.

Um pedido fraco e um pedido que funciona

Fraco: "por que meu ESP32 fica reiniciando sozinho?" O assistente vai listar as causas mais comuns de reboot em ESP32 — watchdog, estouro de pilha, brownout, alocação de memória — porque é só isso que ele tem para trabalhar. É uma lista genérica, não um diagnóstico.

Funciona: colar o log real do monitor serial, incluindo a linha de Guru Meditation Error ou o rst:0x... do bootloader, e dizer o que já foi descartado. O assistente ainda pode errar, mas agora está raciocinando sobre o seu reboot, com o único dado que separa "reboot" de "este reboot específico": o que a placa disse antes de cair.

O limite que fica

Nenhum assistente resolve sozinho o problema que só aparece sob carga, em produção, depois de horas — porque nenhum texto de log cabe tudo o que aconteceu antes da falha. Isso continua exigindo instrumentação: log estruturado, contador de heap, timestamp de cada reconexão. O assistente ajuda a escrever essa instrumentação mais rápido. Ele não substitui a decisão de que ela precisa existir.