Qué es el vibecoding de hardware y si puede usarse con seguridad

El vibecoding de hardware es una interfaz, no un método de ingeniería

En software, «vibe coding» suele significar describir un resultado en lenguaje natural, dejar que un agente genere o modifique código y dirigirlo mediante pruebas. Aplicado al hardware, el agente puede seleccionar componentes, escribir una descripción del circuito, editar el esquema, colocar o enrutar una PCB, ejecutar herramientas EDA y preparar archivos de fabricación.

La interfaz es útil: permite expresar la intención sin dominar cada gesto de KiCad o formato de archivo. No elimina las restricciones eléctricas, térmicas, mecánicas, de suministro o fabricación que hacen funcionar una placa.

El ciclo de feedback también es más duro que en una web. Compilar lleva segundos; fabricar y entregar una PCB lleva días y un pin incorrecto puede destruir un componente. La versión segura se parece menos a «prompt, pedido y esperanza» y más a:

describir → formalizar → generar → inspeccionar → comprobar → fabricar → probar

El agente puede acelerar cada transición, pero no debe ser la única fuente de verdad en un paso irreversible.

Qué puede hacer bien

Funciona mejor cuando el diseño combina bloques conocidos y bien documentados, con criterios de aceptación explícitos. Por ejemplo:

• portadoras para módulos de radio previamente certificados;
• adaptadores de sensores y conectores;
• placas sencillas de microcontrolador basadas en una referencia probada;
• placas de LED, botones, Qwiic/I2C o distribución simple de energía;
• variantes revisadas con otros conectores u opciones de población;
• generación de BOM, reglas, scripts de liberación y planes de prueba.

Un agente ayuda especialmente con trabajo repetitivo: campos coherentes de componentes, revisión del desacoplo, primera netlist o ejecución de controles de KiCad. La guía posterior sobre vibecoding de una placa ESP32 muestra el tipo de diseño acotado basado en un módulo que puede beneficiarse.

El mismo flujo no es un lugar seguro para aprender mediante fallos si la placa maneja red eléctrica, baterías de alta energía, funciones de seguridad, uso médico, movimiento peligroso, conversión de alta potencia o RF sujeta a conformidad. La IA puede ayudar a especialistas, pero la comodidad del lenguaje natural no aporta competencia ni certificación.

Convierte el prompt en un contrato de requisitos

«Haz una placa de sensor ambiental» deja casi todas las decisiones abiertas. Una entrada útil define interfaces, límites, mecánica y pruebas:

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"

El contrato hace visibles las preguntas antes de que exista cobre. ¿USB debe transmitir datos o solo alimentar? ¿Qué variante exacta del módulo? ¿Dónde puede sobresalir la antena y qué keepout necesita? ¿Los agujeros están aislados? Un buen agente devuelve las decisiones pendientes en vez de inventarlas.

El flujo completo desde lenguaje natural hasta una placa trata este contrato estructurado como el principio del diseño, no como documentación redactada a posteriori.

Fundamenta cada componente en evidencia primaria

Para cada pieza no trivial conserva el MPN, la revisión de la hoja de datos del fabricante, el dibujo del encapsulado, el mapa de pines y las notas de aplicación relevantes. Los buscadores y distribuidores ayudan a descubrir; no demuestran una asignación de pines.

Un modelo puede producir una tabla de pines fluida y plausible de otro encapsulado o dispositivo relacionado. El mecanismo del fallo y sus contramedidas se explican en por qué los LLM inventan números de pin. Ningún símbolo o footprint generado debe aprobarse hasta contrastar cada pad con la documentación primaria.

Pide páginas y campos concretos, pero comprueba tú mismo la cita: el modelo puede confundir vistas superior e inferior o citar una página real que no respalda la afirmación.

Exige salidas editables e inspeccionables

Un agente útil produce artefactos normales: esquemas y placas KiCad, código de circuito, BOM con MPN exactos, restricciones legibles y un registro de liberación. Una imagen renderizada no basta; tampoco Gerbers sin trazabilidad hasta el esquema.

Revisa lo mismo que en una placa manual:

• correspondencia entre pines de símbolo y footprint;
• límites y secuencia del árbol de alimentación;
• valores y posición física del desacoplo;
• orientación de conectores y holgura mecánica;
• bucles de corriente, retornos, impedancia y nets sensibles;
• caminos térmicos, pads expuestos y área de cobre;
• stock, ciclo de vida y coincidencia con el encapsulado del montaje.

Si la herramienta no explica por qué existe una net o qué fuente respalda un componente, el ahorro de generación se traslada a la auditoría.

Intercala comprobaciones deterministas

Ejecuta KiCad de forma independiente al 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

Estos controles encuentran infracciones y divergencias, pero no demuestran que el símbolo coincida con la hoja de datos ni que el circuito cumpla requisitos. Añade conciliación BOM/CPL, revisión documental, inspección Gerber y una lista firmada de liberación. Ese proceso por capas es la puerta de fabricación.

¿Puede funcionar de verdad?

Sí, en diseños acotados donde la entrada sea específica, los componentes estén respaldados por documentos primarios, la salida siga siendo editable y una persona competente asuma la liberación. Puede acortar el camino desde la intención hasta un primer prototipo y acercar la creación de hardware a quienes piensan con más naturalidad en código o en prosa.

No puede convertir la ambigüedad en algo seguro. La puesta en marcha con corriente limitada, la comprobación de líneas antes de montar componentes caros, las pruebas de firmware, las mediciones térmicas y el plan para la segunda revisión siguen siendo necesarios. El vibecoding de hardware resulta más creíble cuando el «vibe» termina en la interfaz de requisitos y el resto del flujo es ingeniería explícita.