Um artigo publicado pelo site Semiconductor Engineering em 27 de agosto de 2026 defende que a introdução da inteligência artificial no projeto de circuitos de radiofrequência RF seja tratada como um processo gradual, e não como um projeto que exija substituir a plataforma atual ou reconstruir completamente o fluxo de trabalho. A ideia parte de um problema prático: uma grande parte da capacidade das equipes de RF e micro-ondas depende do conhecimento institucional acumulado por engenheiros experientes, incluindo metodologias de projeto de amplificadores de potência, caracterização de dispositivos e decisões tomadas durante o trabalho que não foram documentadas de forma reutilizável.
Segundo o artigo, a perda desse conhecimento prolonga o período de capacitação dos novos engenheiros, desacelera a avaliação do espaço de projeto e pode levar a um novo projeto cuja necessidade poderia ter sido descoberta por meio do teste de um número maior de candidatos. Portanto, a primeira pergunta não deve ser se a equipe adotará a inteligência artificial, mas como construir essa capacidade sem interromper as ferramentas das quais os engenheiros dependem para produzir projetos reais.
Três etapas que podem ser executadas em paralelo
O autor Daren McClearnon, apresentado pela fonte como gerente de produtos de inteligência artificial e aprendizado de máquina da Keysight, propõe uma estrutura de três etapas: captura do conhecimento, coordenação das ferramentas e aceleração da exploração. Essa estrutura não exige concluir uma etapa antes de iniciar a outra.
Capturar a experiência e transformá-la em ativos reutilizáveis
A fonte indica que a experiência em RF normalmente não existe apenas no código, mas está distribuída entre ferramentas, equações e a experiência prática de correlacionar os resultados das simulações com o que aparece no hardware medido. Na etapa de captura, esse conhecimento deve ser convertido em formatos que a equipe possa executar e compartilhar, para posteriormente entregá-lo a agentes de software.
- Exportar esquemas e layouts para código Python com parâmetros ajustáveis.
- Registrar os procedimentos dos especialistas na forma de scripts executáveis.
- Converter o fluxograma da simulação em código documentado que sistemas baseados em agentes possam compreender.
O valor prático dessa etapa não está no uso de um modelo de linguagem por si só, mas em tornar a metodologia interna visível e reproduzível, em vez de mantê-la na memória de indivíduos específicos.
Da escrita de scripts à definição do objetivo
A etapa de coordenação utiliza o conhecimento que foi capturado. Em vez de escrever e gerenciar manualmente cada script, o engenheiro pode definir o resultado desejado, como projetar um amplificador de potência MMIC com ganho superior a 20 dB e potência de saída superior a 28 dBm, deixando para um modelo de linguagem conectado às ferramentas a tarefa de encontrar e invocar as ferramentas adequadas.
Isso não equivale, segundo o artigo, a passar diretamente para a autonomia completa. Atualmente, as organizações geralmente se encontram entre a programação manual e o uso de assistentes colaborativos iniciais que compreendem a intenção do engenheiro, mantendo a supervisão humana próxima. O passo seguinte são agentes especializados que assumem tarefas de várias etapas com delegação parcial, baseados na própria estrutura de coordenação.
Acelerar a exploração mantendo a física sob supervisão
A terceira etapa concentra-se em aumentar o número de projetos que podem ser explorados e reduzir o tempo de espera. A fonte menciona duas ferramentas principais: a modelagem substituta, que substitui processos pesados de simulação eletromagnética por aproximações rápidas baseadas em redes neurais, podendo ser duas ou três ordens de grandeza mais rápida para algumas estruturas; e a otimização apoiada por inteligência artificial, capaz de lidar simultaneamente com um número maior de parâmetros e encontrar soluções adequadas usando um número menor de simulações.
Contudo, a aceleração não tem valor prático se o resultado não for confiável. Os riscos se destacam especialmente no encapsulamento, nas interconexões, no acoplamento, na integridade da alimentação e do terra e nas correntes tridimensionais; esses fatores podem fazer com que uma resposta rápida e confiante se afaste do comportamento real do hardware e, em seguida, dificultar a análise da causa-raiz das falhas. Por isso, a física usada na modelagem deve ser comparada com as medições reais antes de ampliar o escopo da delegação ao sistema.
O que deve ser verificado antes da expansão?
A estrutura também enfatiza a importância de rastrear a origem dos dados, e não apenas a qualidade do modelo. A equipe precisa saber de onde vieram os dados de treinamento do modelo substituto, como foram rotulados e limpos e quais são suas suposições e limitações conhecidas. Essa transparência é o que define os limites da velocidade e impede que ela se transforme em um risco invisível.
A fonte cita o exemplo da empresa Sphere Semi, uma empresa de projeto de RFIC que enfrentava o problema de explorar um projeto por vez. A empresa adotou um fluxo totalmente definido por código e baseado em Python para executar as etapas de geração, simulação, classificação e otimização, com a execução de centenas a milhares de candidatos por meio de simulação conjunta de circuitos e eletromagnética. Segundo os números apresentados no artigo, essa abordagem alcançou um aumento de produtividade de 5 a 10 vezes, uma melhoria de 6 dB no isolamento e uma redução de 30% na área do filtro em comparação com os processos tradicionais de projeto manual.
Leitura da certi.news: a mudança efetiva proposta pelo artigo não é substituir o engenheiro por um agente independente, mas transferir o conhecimento disperso para fluxos executáveis e, em seguida, conectá-los a objetivos de projeto claros e ferramentas de verificação mensuráveis. Isso torna a adoção menos dependente de uma decisão sobre uma única plataforma e mais relacionada à qualidade da documentação, dos dados e das medições. No entanto, os resultados mencionados dizem respeito a um único exemplo, conforme apresentado pela fonte, e por si só não provam que os mesmos ganhos se repetirão em todos os projetos ou ambientes. Além disso, questões como a capacidade de generalização dos modelos substitutos e seus limites quando o encapsulamento, as estruturas ou os dados mudam ainda precisam de verificação específica por cada equipe.