makeIRLPCB engineering field guide

Vibecode AI hardware guides

Vibecode a Thermal Controller PCB with AI: Safety Limits

Understand why MakeIRL refuses autonomous heater control, and how to specify sensor accuracy, independent cutoff, ready for explicit human gate review.

Practical PCB integration · KiCad 9 · Manufacturing gate

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

MakeIRL's generator treats a thermal controller prompt as a self-contained project board. Current status: refused.

The current policy refuses heater and high-energy control. V2 may generate a sensor-only monitor after verified blocks exist, but not the actuator, power stage, or safety function.

Create a USB-powered temperature monitor for an external cataloged digital sensor, with alarm GPIO and status LED, but no heater, relay, fan, power output, or safety-control claim.

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. Sensor type, range, accuracy, placement, response, calibration, open/short behavior, and environmental limits
  2. Heater/load voltage/current, control dynamics, independent cutoff, fuse, fault energy, safe state, and applicable safety requirements
  3. Connectors, enclosure, thermal coupling, user settings, logging, test fixture, and responsible human reviewer

Block plan:

  • Cataloged controller/module carrier for a monitor-only alternative
  • Verified temperature sensor and low-energy alarm blocks
  • No heater driver, power switch, relay, SMPS, or safety cutoff is generated

Interfaces: I²C/verified temperature input, low-energy alarm GPIO, UART/I²C logging. Power plan: Monitor-only USB power; all heater/load energy remains out of scope and physically absent.

Layout priorities and gate checks

  • For a monitor alternative, separate sensor from board heat, put protection at the sensor cable, and make alarm/test states accessible.
  • 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. Prove the generated alternative contains no heater/load path, verify sensor voltage/address and fault pulls, alarm default, connector pinout, and measurement power.
  2. S1Catalog and exact-MPN provenance. Every thermal 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

  • A qualified reviewer owns control dynamics, runaway hazards, independent cutoff, fault analysis, power hardware, isolation, calibration, and applicable product standards.
  • 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:

  • Firmware, a GPIO, and one temperature sensor cannot contain a shorted switch, stuck processor, detached probe, calibration error, or thermal runaway.
  • 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:

  • Validate only the monitor: calibrate temperature, simulate sensor open/short, reset and power loss, alarm output, logging, and enclosure self-heating.
  • 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 heaters, Peltier devices, fans as thermal actuators, mains, high current, safety cutoffs, and automatic temperature control.
  • Offer a monitor-only board while clearly stating it is not the control or safety boundary.

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 thermal controller prompt in the generator and review every gated artifact before ordering.

Generate a carrier board