Hardware design has the same problem software had before compilers: the feedback loop is slow and the mistakes are expensive. You change a schematic, you run the checks, you find out three days later that the board does not work. Copperhead is an attempt to shorten that loop with an agent, and what makes it interesting is not that it uses a model — it is what the agent is structurally forbidden from doing.
Verification before capability
The design principle is stated in the tagline: verification-first. In practice that means a change has to validate before the tools that can edit files are unlocked.
The demo shows the mechanic. Asked to add a USB-C power input, the agent first reads the power documentation, then lists the nets and finds 41 of them with no VBUS and no CC1 or CC2. Only after the change proposal validates does it get permission to edit, and it then writes the receptacle into the KiCad schematic and updates the power budget doc in the same pass. ERC comes back clean, a drift check confirms the documentation still matches the schematic, and the decision is recorded.
That ordering is the whole idea. A normal coding agent can write anything at any time and you find out at review. Copperhead inverts it: the agent has to prove the change is valid against the design's own rules before it is allowed to touch the design.
Eight stages, each gated
The workflow is a pipeline of eight stages, and each one is its own agent run. The rule is strict and worth quoting: a stage has to leave its artifact on disk before the next starts, and if a gate fails, the run stops there.
It begins with a brief written in your own words, then a spec at a documented path with budgets attached. Subsequent stages carry the design forward, and the run terminates at the first failure rather than continuing on a broken foundation. That is a very different failure mode from an agent that cheerfully produces a complete-looking output with a mistake buried in the middle.
The example run shows the bookkeeping in the transcript: which files were read, which nets were listed, which regions were edited, the ERC result, the drift check, and the decision recorded to a decision log and changelog. For hardware, where the reason for a design choice is often more valuable than the choice, writing that down automatically is a real contribution.
The drift check is the underrated part
Among the checks, the one that will matter most in six months is the drift check. It compares the documentation against the schematic and fails when they disagree.
Every hardware project accumulates this debt. The power budget doc says 5 V at 1.5 A, the design was revised to 3 A, and nobody updated the doc because the doc is not compiled. Six months later a new engineer reads the doc and designs against the wrong number. Software solved this by making documentation a build artifact; hardware mostly has not, because there was no build.
Having the agent write the decision to a decision log and changelog as part of the run, then verify that the prose still matches the schematic, is a small feature that addresses a large and boring problem. It is also the kind of thing that only works if it is automatic — a drift check nobody runs is worse than no drift check, because it creates false confidence.
The comparison to coding agents is instructive here. Cursor, Claude Code and OpenCode all operate on files whose correctness can be tested by running them. Copperhead operates on files whose correctness can only be partly tested, and it responds by narrowing what it claims rather than widening what it checks.
The honest limits
Two things are true at once. First, the checks are real: ERC and DRC are the electrical and design-rule checks the industry already trusts, run through the standard KiCad CLI. Second, passing them does not mean the circuit works.
ERC catches unconnected pins, conflicting outputs, missing power flags. DRC catches clearance violations, unrouted nets, silkscreen overlaps. Neither knows whether the regulator you chose can supply the current the load draws, whether the thermal path is adequate, or whether the part is in stock. A board can pass both checks and fail on the bench, and the project does not claim otherwise.
That is the same gap that makes LDraw Nova honest about LEGO models: LDraw Nova's checks provide evidence, not proof of buildability. Anyone who has used generative tools for physical objects will recognise the pattern, and the correct response is the same — the tool shortens the loop, you still own the judgement.
The second limit is maturity. Copperhead is at v0.8.1 with 664 GitHub stars and around 375 installs a month. It is open source and installs with a single npm command, it is backed by a list of startup programmes, and it has been used to design a real board — Open Telegraph, an ESP32-S3 Morse key whose KiCad files, decision log and check results are all public. That last part is the strongest evidence on the page: a shipped design with an auditable trail, not a demo video.
Who should use it
It suits someone who already knows KiCad. The agent reads nets, edits schematics and runs checks, but deciding whether the resulting power budget is sensible requires understanding what a power budget is. This is not a tool that lets a beginner design a board.
It suits less well anyone who needs a general-purpose coding agent for firmware — Claude Code or OpenCode handle that, and Copperhead is deliberately narrow: KiCad, ERC, DRC, drift.
What it does offer is the most credible safety model for a hardware agent currently on offer: capability gated behind verification, every stage required to produce evidence, and the decision log written as it goes. That is worth more than a longer feature list.
