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.