IA e vibecoding
Por que um gate de fabricação importa mais que um projetista de IA
Um gate de PCB verifica ERC, DRC, paridade, BOM, estoque, Gerbers, furação, posicionamento e revisões antes que qualquer pedido seja feito.
Publicado em Atualizado em
Velocidade é irrelevante se a fronteira de liberação é fraca
Um projetista de IA pode criar rapidamente um esquemático ou layout. Uma pessoa experiente também pode fazer uma mudança rápida sob prazo. Ambos podem produzir uma placa que parece pronta enquanto a BOM aponta ao encapsulamento errado, a PCB está desatualizada em relação ao esquemático ou o arquivo contém a furação de ontem.
Um gate de fabricação fica entre o trabalho editável e um pedido irreversível. Só aceita uma versão quando verificações independentes e revisores identificados satisfazem os critérios. Não importa se o projeto foi desenhado à mão, gerado por código, roteado por otimizador ou editado por agente.
Por isso o gate dura mais que qualquer projetista específico. Ferramentas mudam; a necessidade de dados rastreáveis e coerentes permanece.
Defina entrada e saída com precisão
A entrada é um candidato versionado:
- requisitos e exceções aprovadas;
- esquemático, PCB, projeto, regras e bibliotecas KiCad exatos;
- MPNs e alternativas aprovadas;
- versões de ferramentas e dependências;
- dados mecânicos e perfil de capacidade da fábrica.
A saída é um único pacote imutável:
- Gerbers e furação;
- BOM e pick-and-place;
- desenhos de fabricação e montagem;
- STEP, IPC-2581, teste e programação quando aplicáveis;
- relatórios ERC/DRC e outras verificações;
- revisão, hashes, aprovações e notas.
O significado de liberar para fabricação é essa transição controlada. Uma pasta final-final não é um processo de liberação.
Camada 1: integridade e identidade
Antes dos testes elétricos, falhe para símbolos montados sem MPN, footprints sem mapeamento de encapsulamento revisado, variáveis não resolvidas ou bibliotecas ausentes, versão desconhecida, mudanças geradas não registradas, DNP incoerente ou regras sem revisão associada.
Para bibliotecas geradas, exija contrato de pinos baseado em documento primário. O ERC não detecta símbolo e footprint coerentemente errados, como explica por que os LLMs inventam números de pinos.
Camada 2: verificações determinísticas do KiCad
Execute as verificações em uma pasta de build limpa e faça o comando falhar quando houver violações. Um esqueleto de shell para o KiCad 9 é:
#!/usr/bin/env bash
set -euo pipefail
SCH="hardware/controller.kicad_sch"
PCB="hardware/controller.kicad_pcb"
OUT="build/release"
rm -rf "$OUT"
mkdir -p "$OUT/checks" "$OUT/gerbers" "$OUT/drill" "$OUT/assembly"
kicad-cli sch erc \
--severity-error --severity-warning \
--exit-code-violations \
-o "$OUT/checks/erc.rpt" \
"$SCH"
kicad-cli pcb drc \
--schematic-parity \
--severity-error --severity-warning \
--exit-code-violations \
-o "$OUT/checks/drc.rpt" \
"$PCB"
--exit-code-violations retorna status diferente de zero quando há violações; --schematic-parity compara PCB e esquemático. Esse é o núcleo da automação headless do KiCad, mas não é o gate inteiro.
Não deixe CI verde suprimindo avisos: cada exclusão exige motivo técnico, responsável, local e revisão. Prefira corrigir a configuração das regras ou o projeto.
Camada 3: coerência de suprimentos e montagem
Exporte a BOM do esquemático verificado:
kicad-cli sch export bom \
--fields 'Reference,Value,Footprint,Manufacturer,MPN,${QUANTITY},${DNP}' \
--labels 'Refs,Value,Footprint,Manufacturer,MPN,Qty,DNP' \
--group-by 'Value,Footprint,Manufacturer,MPN' \
--exclude-dnp \
-o "$OUT/assembly/bom.csv" \
"$SCH"
kicad-cli pcb export pos \
--format csv --units mm --side both --exclude-dnp \
-o "$OUT/assembly/positions.csv" \
"$PCB"
Adicione scripts que comparem referências montadas, rejeitem posições duplicadas, exijam MPNs, validem footprints e confiram estoque/ciclo de vida das peças críticas. A entrada do catálogo da montadora deve corresponder ao mesmo MPN e encapsulamento. BOM/CPL sintaticamente válidos ainda podem indicar a peça errada.
Camada 4: regenere do zero
Nunca promova arquivos deixados por uma execução anterior. Gere tudo na pasta de liberação vazia:
kicad-cli pcb export gerbers \
--layers F.Cu,B.Cu,F.Mask,B.Mask,F.Silkscreen,B.Silkscreen,Edge.Cuts \
-o "$OUT/gerbers/" \
"$PCB"
kicad-cli pcb export drill \
--format excellon --excellon-units mm \
--generate-map --map-format pdf \
-o "$OUT/drill/" \
"$PCB"
test -s "$OUT/assembly/bom.csv"
test -s "$OUT/assembly/positions.csv"
Adapte as camadas ao stackup: quatro camadas exigem os cobres internos. Verifique nomes esperados, um único contorno, cobre não vazio e origens iguais. Aplique os limites específicos da fábrica indicados na checklist DFM para PCB.
Gere hashes quando tudo estiver final:
find "$OUT" -type f ! -name SHA256SUMS -print \
| LC_ALL=C sort \
| while IFS= read -r file; do shasum -a 256 "$file"; done \
> "$OUT/SHA256SUMS"
Commit e checksum comprovam quais bytes foram aprovados e enviados.
Camada 5: revisão visual e técnica
Exija assinaturas nominais para potência, reset/boot, proteção, mapeamento de pinos, desacoplamento, loops e retornos, RF/alta velocidade, térmica, orientação dos conectores, gabinete, acesso de teste, sobreposição Gerber/furos, prévia de montagem, rotações, espelhamento inferior, DNP e opções da cotação.
Quem revisa deve inspecionar as saídas, não só a tela do KiCad. O render da fábrica é outra visão independente. Para produção ou protótipos caros, separe aprovação e pedido: compras só deve enviar o arquivo cujo checksum coincide com o registro assinado.
O gate verifica a liberação, não o funcionamento
Um gate limpo comprova que regras codificadas passaram e artefatos são coerentes. Não prova requisitos, sobrevivência a falhas, EMC ou operação em temperatura. Bring-up e verificação física continuam no plano.
Essa fronteira também é onde um fluxo como o MakeIRL pode ser útil: o valor não está apenas em gerar uma placa, mas em tornar inevitáveis as verificações fundamentadas em evidências antes da fabricação. Qualquer ferramenta deve ser julgada pelos artefatos e controles que expõe.
O gate importa mais que um projetista de IA porque contém erros de qualquer projetista. Transforma velocidade em iteração controlada: gere livremente, falhe de forma visível, aprove de propósito e peça uma única revisão rastreável.