O problema de 55,6%: por que LLMs de fronteira falham em código embarcado

55,6%.

Esse é o pass@1 do DeepSeek-R1 no EmbedBench quando recebe um esquema de circuito junto com a descrição da tarefa. 50,0% sem o esquema. Melhor pontuação do melhor modelo de raciocínio no primeiro benchmark abrangente para LLMs no desenvolvimento de sistemas embarcados. A migração entre plataformas para o ESP-IDF atinge um máximo de 29,4%, estabelecido pelo Claude 3.7 Sonnet (Thinking).

Leve um segundo para pensar nisso. Os mesmos modelos que criam um aplicativo Next.js em uma única tentativa estão jogando moeda para firmware. E o benchmark testou apenas três placas.

Esse número 1.553 é a contagem ao vivo de pio boards --json-output contra o PlatformIO Core 6.1.18 no dia em que este post foi escrito, e o PlatformIO-MCP envolve esse catálogo diretamente. Portanto, quando dizemos "1.553 placas", queremos dizer um servidor MCP que você pode npx-instalar hoje que sabe como construir, gravar e monitorar contra qualquer uma delas.

O que o EmbedBench realmente mede

EmbedAgent (Wang et al., 2025) é o artigo. EmbedBench é o benchmark. 126 casos, nove componentes eletrônicos, três plataformas de hardware -- Arduino Uno, ESP32, Raspberry Pi Pico. Os autores avaliam LLMs em três papéis que um engenheiro embarcado real desempenha: Programador (escrever código dado um esquema), Arquiteto (projetar o circuito e o código a partir de uma descrição da tarefa), Integrador (portar código funcional de uma plataforma para outra). A pontuação é pass@1 contra o simulador de circuito virtual Wokwi. Ou o teste passa ou não passa.

A metodologia é sólida; o simulador é determinístico, o suporte é automatizado e a métrica não deixa espaço para crédito parcial. Portanto, os números são reais. Eles também são incompletos de uma maneira que importa mais para um engenheiro embarcado do que para as pessoas que escrevem o artigo.

O que o suporte não consegue ver

EmbedBench é de tentativa única em um simulador. O modelo recebe a tarefa uma vez e escreve a resposta uma vez. Não há erro de compilador retornado, nenhum error: 'GPIO_NUM_45' não foi declarado neste escopo para o modelo ler e reagir. Não há gravação em uma placa real e nenhum monitor serial para confirmar que o LED realmente piscou na taxa que deveria. O papel de Arquiteto pode devolver um circuito com a mapeamento de pinos errado e nunca descobrir até que o teste falhe.

Isso não é como ninguém escreve firmware. O desenvolvimento embarcado é iterativo. Você compila, lê o ruído da ferramenta, corrige a inclusão ausente, grava, observa o log serial, altera a taxa de transmissão, corrige o erro de um em um no ISR do temporizador, grava novamente. O benchmark mede o palpite inicial e o relata como se fosse todo o ciclo.

Os próprios modos de falha do artigo confirmam isso. Os LLMs falharam em displays de 7 segmentos porque erraram os níveis de tensão e os mapeamentos de segmentos. Eles falharam em botões de pressão porque não lidaram com o debounce. Eles falharam na migração para ESP-IDF porque alucinaram sintaxe para um framework que mal viram no treinamento. Cada uma dessas falhas é o tipo de coisa que uma compilação, uma gravação e uma impressão serial pegariam na segunda ou terceira iteração.

O que muda com um loop real

Esta é a parte da história que o PlatformIO-MCP preenche. O servidor MCP fornece a um agente as quatro ferramentas que tornam a iteração possível: ele pode construir um projeto, enviar o binário para uma placa, observar a linha serial e perguntar quais placas estão conectadas. Nenhuma dessas ferramentas corrige a lacuna de conhecimento subjacente no ESP-IDF ou nas tabelas de tensão de 7 segmentos; o que elas corrigem é a ausência de um sinal de feedback. Um modelo que é enviado na terceira tentativa supera um modelo que acerta na primeira tentativa, toda vez. O loop é a diferença.

Uma nota para o público de clientes seguros

As equipes que escrevem firmware para essas plataformas tendem a ser as mesmas equipes com requisitos de segurança rigorosos: defesa, aeroespacial, médica, industrial. MCP mais inferência local mais um agente de código aberto mais a ferramenta PlatformIO on-prem é uma pilha que atende aos requisitos para esses ambientes. Os números do benchmark e a história de implantação acabam sendo a mesma conversa.

Experimente o loop

npx pio-mcp dashboard

platformio-mcp está no npm, repositório em github.com/jl-codes/platformio-mcp. Um comando, placas reais, todo o ciclo de feedback que o benchmark não mediu. Se você executou um agente contra um ESP32 ou um STM32 e tem dados para compartilhar, me envie uma DM em X