A IA generativa altera parte do desenvolvimento embebido — mas não a parte decisiva. O que se deslocou, o que se intensificou, e o que recebe enquanto cliente.
A IA generativa consegue hoje produzir drivers padrão, autómatos simples de estado e código boilerplate em SystemVerilog, VHDL, C ou Python. É real, é útil e reduziu o esforço para certas tarefas de rotina.
Daí resulta uma pergunta legítima: o que ainda traz um desenvolvedor experiente em embebido e FPGA neste ambiente?
A resposta é concreta.
Uma IA é um executor rápido. Produz aquilo que lhe é pedido — não aquilo que é necessário. Pedir a uma IA «escreve-me um driver UART» dá um driver UART. Mas não aquele que realmente funciona com este domínio de relógio, esta atribuição de pinos, este comportamento temporal e este tratamento de erros no ambiente alvo.
A verdadeira competência de engenharia não é gerar código. É escrever uma especificação precisa: o que deve acontecer exatamente, em que condições, com que tolerâncias, com que comportamento em caso de falha, em que faixa de temperatura, durante que tempo de vida.
Uma IA melhor não muda isto. Pelo contrário: quanto mais capazes as ferramentas se tornam, mais decisivo é instruí-las corretamente.
Uma IA não acrescenta requisitos em que o cliente não pensou. Não inventa casos especiais. Entrega exatamente o que está na especificação — e nada além disso. O que não está especificado falta no resultado.
Assim, o risco desloca-se inteiramente para a própria especificação. Uma especificação inexperiente descreve corretamente o que o cliente pediu e ignora tudo aquilo que o redator nunca viveu: a falha rara de sensor com certos gradientes de temperatura, o comportamento durante um brown-out simultâneo e bloqueio do barramento I²C, um reset de watchdog durante uma sequência de escrita em flash, o acoplamento eletromagnético em cabos de sensores longos, o comportamento ao reinicialização após um reset não intencional durante uma operação crítica de escrita.
Estes pontos não são requisitos do cliente. São requisitos que um desenvolvedor experiente acrescenta, porque sabe que de outro modo não constariam em parte alguma. Uma especificação é por isso sempre também um catálogo de riscos — e a profundidade desse catálogo é proporcional à experiência de quem a redige.
Numa investigação de segurança a uma bomba de infusão, para a qual fui chamado por um fabricante de dispositivos médicos, manifestou-se uma falha relevante para a segurança que surgiu da ocorrência simultânea de duas falhas individuais: a falha de hardware de um chip de memória e uma rotina de verificação errada para esse mesmo chip. Cada falha por si era controlável. Só a combinação produziu o estado de falha não detetado.
É precisamente esta análise combinada que tem de ser ativamente acrescentada numa especificação. Do requisito «verificar a memória», uma ferramenta gera uma rotina de verificação. A experiência acrescenta o requisito adicional de que a falha da própria rotina de verificação não pode levar a um estado de falha silencioso. Nenhuma ferramenta formula este segundo requisito por iniciativa própria.
A isto somam-se as ciladas próximas do hardware que não constam dos datasheets, mas sim nas cabeças dos desenvolvedores que já tiveram de as perseguir:
Para a maioria das tarefas existem várias soluções que funcionam fundamentalmente. Mas apenas algumas cumprem os requisitos de segurança, fiabilidade e tempo de vida que o produto concreto exige.
Um sistema de IA escolhe o que era frequente nos seus dados de treino. Um desenvolvedor experiente escolhe o que não conduz à catástrofe num sistema relevante para a segurança. Esta decisão de seleção não é um detalhe de implementação. É a verdadeira engenharia.
Em caso de dano, o legislador exige a prova de que o produto, no momento da colocação no mercado, correspondia ao estado da técnica. É a condição central para um fabricante poder afastar a responsabilidade do produto. Com a nova Diretiva europeia sobre responsabilidade do produto e a lei nacional de transposição que dela decorre, este ónus da prova é explicitamente reforçado para software e produtos com software integrado.
O estado da técnica não é um estado estático. É o que entre profissionais é considerado habitual — e atualmente muda de forma acelerada porque novas ferramentas e métodos elevam o padrão de mercado em ciclos curtos.
Daí decorre: quem hoje desenvolve um sistema embebido tem de conhecer e empregar os métodos atualmente mais capazes. Quem não o faz cria para o seu cliente um risco de responsabilidade concreto. Isto pressupõe justamente um desenvolvedor que domine tanto as ferramentas estabelecidas como as novas e saiba fazer a escolha certa.
Uso ferramentas de IA onde poupam tempo mensurável sem criar risco: primeiro esboço de boilerplate, geração de testbenches, documentação, verificação de legibilidade.
Não as uso em substituição de:
O resultado: menos esforço em trabalho de rotina, qualidade consistentemente alta nas tarefas que efetivamente sustentam o projeto, e um processo de desenvolvimento documentado conforme ao estado da técnica atual.
Contrata um desenvolvedor com mais de 35 anos de experiência em FPGA e embebido, que conhece as ferramentas atuais e sabe avaliar os seus limites. Não recebe nem um «projeto gerado por IA» nem um «projeto sem IA». Recebe um sistema funcional pelo qual uma pessoa concreta assume a responsabilidade — e que, em caso de sinistro, pode ser demonstrado como tendo sido desenvolvido segundo o estado da técnica.
Se tem um projeto embebido que exige precisamente esta profundidade, falemos diretamente. Conversa inicial e estimativa aproximada são gratuitas e sem compromisso.