Tohum

O Dashboard do Cenk: O Paradoxo da IA no Mundo Embedded

Infográfico: o paradoxo da IA em sistemas embarcados — ganhos reais em tarefas delimitadas, dívida negativa no nível de sistema

A história destilada de 25 estudos.

Terça-feira de manhã, 9:14. Numa pequena startup de IoT em Ancara, Cenk, um engenheiro de firmware sénior, olha para o ecrã. Precisa de configurar amostragem de ADC baseada em DMA numa placa STM32. Pergunta ao Claude — o código chega, compila, é gravado na flash. Os sensores produzem dados. Cenk sorri. Na semana seguinte, doze contadores de água inteligentes no terreno começam a bloquear aleatoriamente. O culpado: uma configuração incorreta do clock de um periférico. O compilador não conseguiu apanhar; o silício apanhou. Cenk olha para o seu dashboard e pergunta-se: estará esta ferramenta realmente a acelerar-nos, ou apenas a fazer-nos sentir rápidos?

Cenk não está sozinho. Dois dos estudos mais marcantes de 2025 contradizem-se abertamente. Na experiência controlada da METR, 16 programadores open source experientes demoraram mais 19% a concluir tarefas quando usaram ferramentas de IA — tinham previsto antecipadamente uma aceleração de 24% e, mesmo depois, continuaram a acreditar que tinham sido 20% mais rápidos. Nesse mesmo ano, um RCT conjunto da Microsoft, do MIT e de Princeton com 4.867 programadores mediu um aumento de 26% nos PRs semanais. Dois estudos, duas direções opostas. Qual deles domina no mundo dos sistemas embebidos?

A ferramenta realmente ensina, acelera, democratiza

A evidência é forte. No estudo de Englhardt no CHI 2024, o fluxo de trabalho humano–IA elevou as taxas de sucesso de compilação de sensores LoRa de 25% para 100% — mesmo utilizadores sem qualquer experiência de hardware conseguiram construir sensores funcionais. No mesmo estudo, o GPT-4 reduziu o consumo de corrente do chip nRF52 por um fator de 740× através de otimização de energia específica do contexto — até 12,2 microampéres. No estudo de um ano da TATA 1mg com 300 engenheiros, os programadores juniores registaram ganhos de produtividade até 77%. Segundo o DORA 2025, 90% dos programadores já usam IA; 80% reportam efeitos positivos na produtividade.

Código que compila não é código que funciona

No benchmark EmbedAgent de junho de 2025, o DeepSeek-R1 atingiu apenas 55% de pass@1 em 126 tarefas embebidas; a portabilidade entre plataformas derrubou-o para 29% no ESP-IDF. Ainda mais marcante: o Claude-3.7-Thinking gastou 78% dos seus tokens de raciocínio não em planeamento, mas a corrigir o seu próprio código com bugs — o efeito de overthinking. Um artigo de 2026 na Future Internet testou 27 LLMs numa stack completa de IoT (sensor → InfluxDB → Grafana); quase todos produziram firmware que compilava mas estava errado para o hardware. Incompatibilidades de versões de bibliotecas, campos de bits de registos incorretos, fórmulas de sensores alucinadas.
O mundo embebido tem uma particularidade: os bugs vivem longe. Numa aplicação web, um bug atualiza a página; em firmware, um bug inutiliza dez mil dispositivos no terreno. A análise da GitClear a 211 milhões de linhas de código mostra que o código duplicado cresceu 48% de 2020 a 2024; em repositórios com uso intensivo de IA, a dívida acumulada de refatoração é 34% superior. Para equipas de IoT, isto não é um problema de luxo — a memória é curta, a bateria é curta, as atualizações OTA são caras. Código inchado significa menor vida útil da bateria, significa recolhas de produto. No inquérito do Stack Overflow 2025, “desconfiar ativamente da IA” saltou de 31% para 46%.

Que porta vigia, e qual abre?

Ambos os lados têm razão — sob condições diferentes. Eis a hipótese que emerge da interseção de cinco estudos: os LLMs entregam ganhos fortes em IoT em tarefas delimitadas, verificáveis e descartáveis. Escrever um parser de protocolo, gerar uma função de calibração de sensor, montar a estrutura de um teste de regressão, redigir documentação. Fora dessa fronteira — design ao nível do sistema, rotinas críticas em timing, integração multi-componente, módulos críticos de segurança — a capacidade colapsa drasticamente. O ganho não vem da ferramenta, mas da disciplina de engenharia construída à sua volta. Como diz o DORA: a IA é um amplificador.

Cenk senta-se no segundo teste de campo na terça-feira seguinte. Desta vez, a equipa verifica cada linha de DMA que o LLM escreveu num osciloscópio. Duas horas extra de trabalho, mais baratas do que uma semana de recolha no terreno. O seu dashboard continua aberto; os números de produtividade estão a subir — desta vez mais devagar, mas de forma duradoura. Em 2026, a verdadeira questão para as equipas de IoT não é “devemos usar IA?” A verdadeira questão é: que porta vigia, e qual abre? Porque o que separa −19% de +26% não é o modelo — é a disciplina de o usar.

Fontes: