Claude Hardware-in-the-Loop: AI Builds PCBs, Writes Firmware, and Iterates Virtual Prototypes

A developer used Claude Code to complete the entire hardware development process for a full machine—including motors, dozens of sensors, a custom enclosure, and a mainboard—from PCB to firmware to mechanical assembly, all iterated repeatedly in a virtual prototype before placing orders for fabrication. This engineering methodology, which pushes "AI writes code" to "AI builds hardware," along with the accompanying open-source Claude Code skill, is drawing attention on Reddit.

From Writing Scripts to Producing Manufacturing Files: The Basic Loop of Hardware-in-the-Loop

The starting point of this workflow is not drawing schematics, but writing Python scripts. Circuit boards are described as scripts and generated all the way into fab files that can be sent directly to a factory—but only on the condition that ERC/DRC all pass and every component can be validated in real time against LCSC (JLC Parts) for stock and parameters.

The developer emphasizes that component validation is a hard gate: if the part number, footprint, and availability don't all line up, the design isn't complete. This constraint turns AI output from "looks usable" into "theoretically manufacturable."

Firmware likewise comes before physical hardware. Control code runs against the virtual prototype on a PC, and only after passing simulation verification is there any need to spend money on components. The trial-and-error cost of the traditional process—"fab the board first, solder it up, then stuff in code"—is largely eliminated upfront.

ERC/DRC are two fundamental checks in electronic design automation: ERC (Electrical Rules Check) focuses on connection logic at the schematic level, such as power shorts, floating pins, and drive capability conflicts; DRC (Design Rules Check) targets PCB layout and routing, checking whether trace width, spacing, vias, annular ring width, and so on meet manufacturing process requirements. Only when both pass do the generated Gerber, drill, and other fab files meet the basic conditions for factory manufacturing.

LCSC (JLC Parts) is a commonly used electronic component distribution platform in China, providing real-time stock, footprint, parameter, and price data for components. In script-based design, comparing each component against the LCSC database in real time avoids selecting part numbers that are discontinued, out of stock, or have mismatched footprints—a key step in moving "manufacturability" from paper to reality.

The Scale and Duration of a Real Project

The actual project the author ran with this method is a multi-board system: including motors, dozens of sensors, and a custom enclosure. The entire cycle spanned several weeks and went through multiple rounds of iteration, covering PCB, mechanical assembly, control firmware, tooling, and other layers. Every CAD change triggers a recalculation of weight and balance.

This detail deserves separate mention—weight and balance are usually problems that only surface during physical assembly. Automatic recalculation at this level means structural constraints are brought into the iteration loop, rather than discovering a shifted center of gravity after the fact.

According to the author, roughly 800GB of simulation data accumulated in just a few weeks—a magnitude that shows this isn't a few symbolic simulation runs, but validation at scale in parallel.

Automatic recalculation of weight and balance typically relies on the mass properties feature in CAD software: after assigning a material density to each part, the software can automatically calculate overall mass, center of gravity position, and moment of inertia. In a multi-board system, changes in the layout of motors, sensors, and the enclosure directly affect the center of gravity, which in turn affects vibration, balance, and structural stress after assembly. Embedding this calculation into the iteration loop for every CAD change means structural constraints are no longer dependent on manual weighing and adjustment after physical assembly, but are continuously monitored and optimized at the virtual stage.

The Gap Between the Virtual World and Reality: An Order of Magnitude

Whether this method holds up hinges on simulation accuracy. The author's empirical judgment is that the deviation between simulation results and real physics is roughly within an order of magnitude. That phrasing is quite restrained—it doesn't claim simulation can replace physical testing, but it is enough to support design decisions and directional optimization.

Precisely because trade-offs can be made in simulation, AI can perform extreme optimization for specific goals: weight reduction, power savings, functional completeness, or precision—the direction is specified by the user. Going further, AI can generate hundreds of variants of a given part, run simulations on all of them (sometimes overnight), and then let a human make decisions based on the data.

This "generate—simulate—filter" loop essentially batch-processes the most time-consuming exploratory work in hardware design. Human engineers typically don't have the energy to enumerate hundreds of options, but simulation compute can.

"Deviation within an order of magnitude" is a common empirical accuracy description in engineering simulation, meaning the ratio between simulation results and measured values falls roughly between 0.1 and 10. For physical fields such as motor control, thermal management, and structural stress, this accuracy is insufficient to replace final physical testing, but it is sufficient for option screening and trend judgment—for example, when comparing hundreds of part variants, the relative ranking is usually more reliable than absolute values. The author uses this phrasing to draw the boundary between simulation and physical testing: simulation narrows the search space, physical testing provides final confirmation.

Open-Source Methodology and a Cost Warning

After stripping out his own project content, the author open-sourced the methodology and a Claude Code skill at github.com/Kemerd/claude-hardware-in-the-loop. The skill's purpose is to complete the initial environment and methodology setup, and the author explicitly states it isn't something you must rely on long-term—it's just a reasonable starting point.

The full loop of the process is: create and test in the virtual world → order parts → CNC machining → printing → assembly, with the final physical result expected to be reasonably close to the simulation results.

On cost, the author's warning is direct: this process can consume a large number of tokens. Hardware iteration is inherently a long-chain, multi-round endeavor, and every PCB revision and every CAD variant rerun accumulates context and inference overhead, so the cost expectation needs to be calculated upfront.

Claude Code skill is a reusable capability packaging format in Claude Code, typically defining a specific workflow as a skill pack or instruction set so that AI executes tasks in a specific domain according to a preset methodology. In this project, the skill encapsulates the initial environment setup and process methodology for hardware-in-the-loop development; after installation, users get a runnable starting point. The author emphasizes that it isn't a long-term dependency but scaffolding that lowers the barrier to entry—subsequent iterations still rely on the developer's own engineering judgment and project context.

Who This Method Is For

Based on the available information, it is better suited to developers with some hardware background but lacking the time for full iterations: you need to be able to judge whether simulation results are reasonable, and you need to understand basic concepts like ERC/DRC, footprints, and part numbers, so that AI can amplify output in your direction.

It is also not a shortcut to "building hardware from zero." Virtual prototypes reduce trial-and-error costs, but they don't eliminate engineering judgment itself. The author's own phrasing is closer to an invitation: actually build those projects you've always wanted to do but never had time for.