makeIRLPCB engineering field guide

Vibecode AI hardware guides

Vibecode a Game Controller PCB with AI and Gate Checks Guide

Generate a wired game-controller carrier only with exact buttons, axes, USB/HID block, debounce, ESD, mechanics, power, gate checks, and latency/input tests.

Practical PCB integration · KiCad 9 · Manufacturing gate

Vibecoding a game controller: what the generator can and cannot do

MakeIRL's generator treats a game controller prompt as a self-contained project board. Current status: in envelope needs block.

A wired low-speed input board can fit once verified HID, button, and analog-axis blocks exist. Wireless, battery, haptics, and USB high-speed are refused.

Create a wired USB Full-Speed controller with eight buttons, two cataloged potentiometer axes, one status LED, ESD, SWD, and no wireless, battery, motor, or haptics.

MakeIRL V2 extracts a strict CarrierSpec from the prompt, applies a deterministic scope policy, resolves only cataloged blocks, composes deterministic connectivity and exact-MPN BOM data, emits KiCad artifacts, and runs the manufacturing gate. The language model does not invent pins, topology, parts, placement, routing, or substitutions.

What the prompt must specify

  1. Button/joystick/trigger MPNs, contact and axis ranges, pulls, debounce/filter, dead zones, and calibration
  2. Exact USB-capable controller block, HID role/report, poll target, programming/recovery, status, and power current
  3. Handed enclosure datum, control heights, mounting, connector anchoring, cable exit, ESD exposure, and cycle targets

Block plan:

  • Cataloged USB-capable controller carrier
  • Verified digital-input and potentiometer/ADC blocks
  • Verified USB-C data connector, ESD, status, and programming blocks

Interfaces: GPIO buttons, verified ADC axes, USB Full-Speed HID when supported. Power plan: USB bus power within declared sink current; no batteries, motors, haptic drivers, or generated converters.

Layout priorities and gate checks

  • Lock control centers to the enclosure, keep analog returns away from USB and LED current, mechanically anchor the connector, and provide calibration/test access.
  • Freeze the board outline, mounting holes, connector faces, component height zones, test access, and keepouts before evaluating generated placement or routing.

Gate checks:

  1. S1Generated connectivity and schematic parity. Check every input-to-report map, pull and boot states, ADC range/reference, USB CC/ESD/data parity, connector shell, and current limit.
  2. S1Catalog and exact-MPN provenance. Every game controller block, footprint, pin map, required companion, BOM line, and block-status claim must resolve to the pinned catalog version; the prompt cannot create missing hardware.
  3. S2PCB DRC, fabrication profile, and release identity. Run KiCad DRC and schematic parity, compare geometry with one quoted fab profile, regenerate Gerbers/drills/BOM/CPL from the approved revision, and inspect both local and supplier previews.

Human review, failure modes, and validation

  • Review ergonomics, control tolerances and cycle life, USB firmware, latency, analog calibration, ESD, connector stress, and accessibility.
  • A reviewer must check primary datasheets, exact symbol-to-footprint mapping, power and protection, return paths, connector orientation, mechanical fit, test coverage, and every gate waiver before release.

Failure modes:

  • A controller can enumerate but have reversed axes, boot-pin button conflicts, noisy ADC references, or controls that miss enclosure openings.
  • ERC and DRC can prove encoded consistency but cannot prove requirements, component source truth, analogue stability, RF/EMI, thermal margin, firmware, safety, compliance, or delivered product function.

Validation plan:

  • Exercise every input and chord, sweep axes and calibrate endpoints, measure latency/jitter, test both USB orientations/hosts, ESD, and mechanical cycles.
  • Bring up first articles with current limiting, measure every rail before fitting expensive modules, program minimal test firmware, exercise every interface and fault assumption, and retain measurements against the released revision.

Refusal boundary and generator envelope

  • Refuse wireless, lithium, motors/haptics, USB high-speed, or uncataloged analogue controls.
  • The board generator cannot create HID firmware correctness or ergonomic validation from schematic connectivity.

The intended carrier envelope is 2-layer FR-4, at most 100 × 100 mm, at most 40 BOM lines, at most 12 V SELV and 2 A, with cataloged modules and low-speed I²C, UART, GPIO, slow SPI, or power-only USB-C connections. The current catalog is narrower than that intended envelope.

Deterministic policy refuses unsupported or hazardous requests, including mains, motors, lithium charging, RF design, switch-mode power, high-speed buses, excessive size/current, and unknown modules. A refusal is a safety and truthfulness result, not a failed attempt to improvise a circuit.

The current seed catalog contains ESP32-C3 carrier, USB-C power, and Qwiic/status-LED blocks at checked status. They have passed deterministic checks but are not yet physically verified through the documented two-lot bring-up ladder; pages must not call those current seeds verified.

The output is a gated design candidate for engineering review. Current placement/routing can still produce blocking or review findings, so a generated board is not automatically fab-ready, functionally validated, certified, or safe to order. MakeIRL does not autonomously place a fabrication order from a prompt. Human review, source and output inspection, gate resolution, order-specific fab confirmation, and physical bring-up remain required.

Generate a gated candidate, not a blind board

Try a game controller prompt in the generator and review every gated artifact before ordering.

Generate a carrier board