A IA acelera o trabalho, mas ela escreve o que parece certo, não o que foi provado. Em firmware, o erro costuma ser silencioso: o código compila, roda na bancada e falha no campo. Conhecer os riscos é o que separa quem guia a IA de quem só copia e cola.
A IA completa o texto de forma plausível, e isso inclui inventar funções, parâmetros ou bibliotecas. Também mistura versões: o que valia no ESP-IDF 4 ou no Arduino Core 2 pode não compilar (ou se comportar diferente) no ESP-IDF 5 ou no Core 3. Sempre diga a versão que você usa e confira na documentação oficial.
Código que compila e roda bem por horas e trava no terceiro dia. Alocação sem liberação e uso repetido de String em laços fragmentam a memória, que no ESP32 é pouca. Monitore a memória livre (heap) e peça código sem alocação dinâmica dentro de laços.
Tarefas do FreeRTOS com pilha pequena demais, ou buffers grandes declarados como variáveis locais, derrubam a placa com um reinício (Guru Meditation Error). A IA raramente calcula o tamanho de pilha de verdade: meça com o marcador de uso mínimo da pilha e ajuste.
Variáveis compartilhadas entre tarefas ou interrupções sem proteção, funções bloqueantes (delay, laços esperando resposta) e falta de tempo limite (timeout) em rede e em leitura de sensor. O código parece certo e falha só de vez em quando, o pior tipo de defeito.
A IA chuta números de pino. Ela pode usar pinos reservados à flash, pinos de boot ou pinos só de entrada, e esquecer que o nível lógico é 3,3 V. Confira cada pino contra o esquemático e o datasheet da sua placa antes de ligar qualquer coisa.
Exemplos copiados pela IA costumam trazer senha escrita no código, conexão sem verificar certificado, senha padrão e atualização remota (OTA) sem autenticação. Em rede de fábrica, isso abre a porta para quem estiver na mesma rede.
Colar no chat a senha do Wi-Fi, chaves de API, tokens ou código proprietário da empresa os envia para fora. Troque por valores de exemplo (placeholders) antes de colar e guarde os segredos fora do código.
Quem não entende o que o código faz não consegue perceber o erro. É por isso que a base teórica (eletrônica, protocolos, memória, tarefas) não é opcional: é ela que permite guiar a IA e julgar a resposta.
Defina o contrato de arquitetura antes de pedir código: placa, framework, versão e regras (sem delay, tarefas, tempo limite).
Peça a arquitetura e os riscos primeiro, e só depois o código.
Trabalhe em passos pequenos: compile e teste a cada mudança, em vez de aceitar um arquivo enorme de uma vez.
Ligue os avisos do compilador e use análise estática. Um aviso ignorado hoje é um travamento amanhã.
Meça o que a IA não mede: memória livre, uso de pilha de cada tarefa e tempo de resposta.
Use watchdog, tempo limite em toda operação de rede ou de sensor e reconexão automática.
Confira todos os pinos e limites elétricos no esquemático e no datasheet.
Mantenha segredos fora do código e nunca cole credenciais reais no chat.
Peça uma revisão por uma segunda IA ou por uma pessoa, com o papel de revisor sênior.
Versione tudo com git, para poder voltar atrás, e teste na bancada antes de levar ao campo.
Parada de emergência, intertravamento de proteções e qualquer função que proteja pessoas devem usar dispositivos e projetos de segurança próprios, previstos nas normas, e não código de firmware gerado por IA em um ESP32. Use a IA para acelerar o que é seguro errar e valide tudo o que toca em máquina real.
