IA e vibecoding
O que é vibecoding de hardware e ele pode funcionar com segurança?
Vibecoding de hardware usa linguagem natural e agentes para criar eletrônica, mas só funciona com restrições explícitas, verificações e testes físicos.
Publicado em Atualizado em
Vibecoding de hardware é uma interface, não um método de engenharia
Em software, “vibe coding” costuma significar descrever um resultado em linguagem natural, deixar um agente gerar ou modificar código e orientá-lo por testes. No hardware, o agente pode selecionar componentes, escrever o circuito, editar um esquemático, posicionar ou rotear uma PCB, executar ferramentas EDA e preparar arquivos de fabricação.
A interface é útil: permite expressar intenção sem conhecer cada ação do KiCad ou formato de arquivo. Ela não elimina as restrições elétricas, térmicas, mecânicas, de suprimentos e fabricação que fazem uma placa funcionar.
O ciclo de feedback também é mais severo do que o de uma página web. Compilar leva segundos; fabricar e entregar uma PCB leva dias, e um pino errado pode destruir uma peça. A versão segura se parece menos com “prompt, pedido e esperança” e mais com:
descrever → formalizar → gerar → inspecionar → verificar → fabricar → testar
O agente pode acelerar cada transição, mas não deve ser a única fonte de verdade em uma etapa irreversível.
O que ele pode fazer bem
Funciona melhor com blocos conhecidos, bem documentados e critérios explícitos:
- portadoras de módulos de rádio pré-certificados;
- breakouts de sensores e conectores;
- placas simples de microcontrolador baseadas em referência comprovada;
- placas de LED, botões, Qwiic/I2C ou distribuição simples de energia;
- variantes de um projeto revisado;
- BOMs, regras, scripts de liberação e planos de teste.
Um agente ajuda especialmente no trabalho repetitivo: campos consistentes, revisão de desacoplamento, primeira netlist ou execução de verificações do KiCad. O guia posterior sobre vibecoding de uma placa ESP32 mostra o tipo de projeto delimitado baseado em módulo que pode se beneficiar.
O mesmo fluxo não é lugar seguro para aprender por falha quando a placa envolve rede elétrica, baterias de alta energia, funções de segurança, uso médico, movimento perigoso, conversão de alta potência ou RF sujeita a conformidade. A IA pode ajudar especialistas, mas a conveniência da linguagem natural não fornece competência nem certificação.
Transforme o prompt em um contrato de requisitos
“Faça uma placa de sensor ambiental” deixa quase tudo em aberto. Uma entrada útil define interfaces, limites, mecânica e testes:
function: "USB-powered temperature and humidity logger"
input_power:
connector: "USB-C receptacle, 5 V sink only"
max_current_mA: 300
logic:
module: "ESP32-C3 module with onboard antenna"
interfaces:
- "I2C sensor at 3.3 V"
- "UART test pads"
mechanical:
outline_mm: [45, 30]
mounting_holes: "4 x M2.5, grounded: no"
manufacturing:
layers: 2
assembly_side: "top only"
fab_rules: "named vendor standard capability profile"
acceptance:
- "ERC and DRC have zero unwaived errors or warnings"
- "USB input current stays below 300 mA"
- "sensor reads within its stated tolerance at room reference"
O contrato expõe perguntas antes do cobre: USB precisa de dados ou só energia? Qual variante? Onde a antena pode avançar e qual keepout exige? Os furos são isolados? Um bom agente devolve decisões não resolvidas em vez de inventá-las.
O fluxo completo da linguagem natural até a placa trata esse contrato estruturado como o começo do projeto, não como documentação escrita depois.
Fundamente cada peça em evidência primária
Para cada componente não trivial, guarde MPN, revisão do datasheet, desenho do encapsulamento, mapa de pinos e notas de aplicação. Busca e distribuidores ajudam na descoberta, mas não comprovam pinagem.
Um modelo pode produzir com confiança uma tabela plausível de outro encapsulamento. O mecanismo da falha e as contramedidas são explicados em por que os LLMs inventam números de pinos. Nenhum símbolo ou footprint gerado deve ser aprovado antes de comparar cada pad com documentação primária.
Peça páginas e campos, mas confira a citação: o modelo pode confundir vistas superior e inferior ou citar uma página que não sustenta a frase.
Exija saídas editáveis e inspecionáveis
Um agente útil produz artefatos normais: esquemático e PCB KiCad, código do circuito, BOM com MPNs, restrições legíveis e registro de liberação. Um render não basta; Gerbers sem rastreabilidade ao esquemático também não.
Revise:
- correspondência símbolo-footprint;
- limites e sequência de alimentação;
- valores e posição do desacoplamento;
- orientação e espaço dos conectores;
- loops, retornos, impedância e nets sensíveis;
- caminhos térmicos, pads expostos e cobre;
- estoque, ciclo de vida e encapsulamento de montagem.
Se a ferramenta não explica por que uma net existe ou qual fonte sustenta uma escolha, o tempo economizado na geração migra para a auditoria.
Coloque verificações determinísticas no caminho
Execute o KiCad independentemente do agente:
kicad-cli sch erc \
--severity-error --severity-warning \
--exit-code-violations \
-o build/erc.rpt board.kicad_sch
kicad-cli pcb drc \
--schematic-parity \
--severity-error --severity-warning \
--exit-code-violations \
-o build/drc.rpt board.kicad_pcb
Essas verificações encontram violações e divergências, mas não provam que o símbolo coincide com o datasheet nem que o circuito atende aos requisitos. Adicione conciliação BOM/CPL, revisão documental, inspeção Gerber e checklist assinada. Esse processo em camadas é o gate de fabricação.
Ele pode realmente funcionar?
Sim, em projetos delimitados, com entrada específica, peças fundamentadas em documentos primários, saída editável e uma pessoa competente responsável pela liberação. Pode encurtar o caminho da intenção ao primeiro protótipo e tornar a criação de hardware acessível a quem pensa mais naturalmente em código ou prosa.
Não pode tornar a ambiguidade segura. Bring-up com corrente limitada, verificação dos trilhos antes de montar peças caras, testes de firmware, medições térmicas e plano para a segunda revisão continuam necessários. O vibecoding de hardware é mais confiável quando o “vibe” termina na interface de requisitos e o restante do fluxo é engenharia explícita.