DEVIN FARM

what they built

Devin Farm lets cloud Devin sessions build and test real hardware the way they already build web apps. Boards stay plugged into one always-on rig, a Jetson Orin Nano with an Arduino Uno Q and a webcam, and any Devin session can lease a board, flash code, run it, and get a verdict from the camera. The agent never gets to grade its own work. The rig runs a FastAPI daemon (rigd) that handles leases, a FIFO queue per board, fencing tokens, flashing by git SHA, and a reset to idle afterwards. Several sessions share one rig in parallel, but only the lease holder can touch a board, so agents can't overwrite each other. Each session joins our Tailscale network with its own one-hour ephemeral key. ACL tags limit it to the rig's session API, so it gets no shell and no other boards. A bad flash stays on one chip. The camera verifier uses OpenCV with a homography fitted to all 104 LEDs of the Uno Q matrix, at about 0.6 px reprojection error. It reads the matrix cell by cell and only exports the cropped board region. Logs never count as a pass. On our rig, it confirmed the target heart at 104/104 cells and rejected a wrong image with 23 cells off. A control plane launches sessions through the Devin API v3. It injects each session's network key as a session secret, caps ACUs, and asks Devin for a structured claim that the camera then checks. A React/TypeScript UI shows a live bubble map of sessions, leases, and the queue, plus an evidence page per verdict with the camera frame and an expected-vs-measured grid. Devin is the user of the product. Each session reads a hardware ticket, leases a board, pushes code, asks the camera to verify, and iterates on the measured result rather than its own logs. One ticket is a trap: the obvious tutorial solution prints READY but lights the wrong LED, and only the camera catches it. We also built the four lanes (rig, verifier, control, UI) with coding agents working in parallel against one shared interface contract.