Hands
An AI hardware engineer that uses a non-expert human as its hands — the model proposes a circuit, deterministic code decides whether it is safe, and a person wires it one jumper at a time.
- Type
- Artifact
- Where
- Personal
- When
- Oct 2026 → Present
- Duration
- 1 mo
- Status
- Simulation-verified
- Source
- Private · available on request
The problem
Anthropic's Project Fetch showed non-experts programming a robot dog faster with Claude — controlling hardware that already existed. Its write-up names the harder question directly: designing, building and improving new hardware.
The obvious experiment — a model designs a board, a fab makes it, instruments test it — costs money and days per iteration, and a bad board is scrap. I have a CS degree and no electronics background, so there was also no expert anywhere in that loop to assemble or judge the result. That makes me the target user, not the tester.
What I built
The fab became a breadboard kit of roughly $75 around a Raspberry Pi Pico W, and the robot became a person. A model turns a one-sentence spec into a netlist using only the parts on hand; twenty deterministic electrical rules built on datasheet numbers check it, and a failing design goes back to the model with the findings. It never reaches the person.
The person gets one physical action per step, with exact hole coordinates, in the terminal or on a phone-friendly page. Power is gated: a photo check that a vision model only describes and code diffs against the plan, safe-idle firmware on the bare board, and a current reading on the 3V3 rail before anything else runs. Firmware the model writes is parsed with Python's ast and refused if it drives a pin the rules never approved.
I had no hardware to test against, so I built the bench in software: a DC nodal solver, a breadboard evaluated from the wires as actually placed, the same MicroPython firmware running against shims on a virtual clock, and a simulated person who makes injected mistakes. Then I attacked my own gates and found more than twenty ways around them — most because a check lived in the caller instead of in the function that did the dangerous thing.
Screens
What I considered
Rejected. The thing being checked is model output, and a confident wrong design can talk a model checker round. A safety check must give the same input the same verdict every time. The model still gets every finding back as feedback.
Rejected. The most direct test of the question and the most striking demo — at real money and several days per iteration, with failures that end in scrap and no expert to read them.
Chosen. A jumper moves in seconds and a wrong part is not scrap, the person's mistakes become the thing the agent has to recover from, and every gate is a function with a test. The cost is a small, closed world: eight part kinds, USB power under 500 mA, and nothing else allowed.
Results
- The whole loop — design, rule check, guided build, photo check, power-on, firmware, instrumented test and debug — runs end to end on a simulated bench, with 178 tests passing at 89% branch coverage.
- All 7 injectable wiring mistakes are caught and fixed in tests, including the two a camera cannot see, which the instruments catch after power-on.
- A hardening pass found more than 20 bypasses of the safety gates; every one is fixed and has a regression test.
- The real-hardware path — port discovery, flashing, an on-board current monitor, the logic analyzer — is built and tested against fakes, and has not yet run on a physical board.
Architecture
In hindsight
Everything above is proven on a bench I wrote. It has not touched a real Pico, no real model has run the loop end to end — the demos use scripted replies — and the datasheet limits the rules depend on were written from memory and still need checking against the current PDFs. The lesson I would carry into the hardware bring-up is the one the hardening pass taught: put the invariant inside the function that does the dangerous thing from day one, not in the orchestrator that is supposed to call it first.