Matt Starfield, the Senior Electrical Engineer at Solid Product Design, opened the talk with a song lyric he wrote as a graduate student, twenty years earlier:
My body is weak, but my mind continues to think of a way to create a machine to proceed with my work while my body's asleep.
Today that machine sits on his desk. A Raspberry Pi 5 runs Hapimatic, the meta-harness he has built over the past ten months, and the agents it runs now flash firmware onto real boards, drive the instruments on his bench, and check their own work. The talk traced how he got there: a series of bottlenecks, each removed in turn, until the last one was Starfield himself.
What Hapimatic is
A meta-harness is software that sits one layer above the command-line agent tools developers already use, such as Claude Code, Codex CLI, Gemini CLI, and OpenCode. Working at that layer lets Hapimatic share context between sessions, orchestrate fleets of them, add features the vendors do not ship, apply sandboxing policies and guardrails, and present the same interface on a desktop, a tablet, or a phone.
The other half of the design is that GitHub is the shared work surface. Every issue is a unit of work, and every session records what it did there. If a session goes down, another one starts and picks up where the last one stopped, because the state lives in GitHub rather than in any one session's memory.
Accelerating output
Starfield measured the effect on output against two baselines: his own best year of commits, and the public history of VS Code, an open-source project. By his count, working with Hapimatic he commits at about ten times the per-engineer rate he found for that team, with 4,247 commits so far this year. Pull requests and closed issues told the same story. Even the busiest week of closed issues in the VS Code history he examined fell short of a typical week for him, and his best full week was 210 issues closed. Because he uses the tools to build the tools, the curve keeps climbing.
He also tracks AI thinking hours. With many agents running at once, one hour on the clock can hold five, ten, or twenty hours of agent work. The live count stood at 6,003 hours, which he put at 750 eight-hour workdays, or about two years of working hours in four months. The work is split close to evenly between the Raspberry Pi in his office and cloud machines.
Removing the friction
The philosophy behind Hapimatic is simple: find what is slowing the work down, and remove it. Its history is a list of those bottlenecks.
It began in March 2023, when his friend Brad Flaugher introduced Starfield to Claude. Running Claude Code on a Raspberry Pi meant sitting at the desk, so he tried Happy Coder, a free app that tunneled to it, but its free relay server dropped often. HAPI, a fork of Happy Coder built around a self-hosted server, fixed that and exposed the next problem: the Pi itself crashed about every two days. A solid-state drive and the official power supply ended the crashes, and the Pi has now run for about eight months without one. In early January he forked HAPI to improve its interface, and Hapimatic began.
Each fix exposed the next limit. Ideas arrived faster than he could write them down, so he moved to voice transcription and used GitHub Issues as the backlog. Large initiatives overflowed the agents' 200K-token context window, so the work was split into stages, each in its own session: format the issue, research and plan, implement, and test, with the plan kept in GitHub for the next session to execute. The arrival of a 1 million-token window helped further. As the application grew, bugs became the bottleneck, so the system began filing its own bugs back into the same pipeline, an early form of recursive self-improvement.
Compute came next. One Raspberry Pi reliably runs about ten sessions at a time, so Hapimatic became a federated mesh of nodes in which any session can talk to any other, and then grew into cloud machines. Starfield now typically runs 20 or 30 sessions at once. With everything else automated, the last bottleneck was him. On hardware work an agent could flash firmware onto a board, but a person still had to test the result and report back, so on nights and weekends the system stopped.
Closing the loop
The answer was to move from in the loop to on it:
So I put myself on the loop instead of in the loop
Starfield taught his agents to use the lab's instruments: oscilloscopes, power supplies, programmer-debuggers, power profilers, an electronic load, and a pan-tilt-zoom camera in the ceiling that looks down on the bench. An agent can now update firmware on a real board, measure the result, feed what it sees back to itself, and keep iterating, then send a message by Telegram or email when the work is done. Testing and feedback, the last manual steps, run without him. He walked through six cases from his bench.
A flickering display. A client's energy-harvesting device was meant to show its voltage and current steadily on an LCD, but the reading flickered. An agent knows what it told a screen to show, not what the screen actually shows, so the camera was the only way to close that loop. The system found a firmware fault that made the device hunt back and forth, and after the fix its performance held steady.
A battery that would not charge. A device drew no charge current at all. Watching it try to charge, the system found that the maximum charge current, set at 7.5 amps, overshot and tripped the battery's own 8-amp protection circuit. Replacing the resistor that sets the limit brought it down to 3.85 amps, and the device charged normally.
A design review. Starfield handed the system an Arduino Nano-style board he designed in Eagle in 2017. It converted the design to KiCad, reviewed it against rules drawn from his experience, and profiled its power draw under different operating conditions.
Low-power firmware. A client's battery-powered device had inefficient firmware. The system measured it with a power profiler, changed the firmware, and stretched the runtime from 5 days to 138 days. The device was on a breadboard with no schematic, so the system drew one as well.
A misconfigured fuel gauge. A cellular wearable for livestock was expected to run about nine days but lasted about one. The system ran seven power tests under different firmware conditions and found the device efficient. The fuel gauge was misconfigured and shut it down early. After the fix the device ran 17 days before the test was stopped, with enough charge left to project a 20-day runtime.
A battery with no data sheet. For a battery of unknown origin, the system drove an electronic load to characterize its charge curves and produced a full report on that specific battery, more useful than a data sheet for its model.
What's next
Next, Starfield plans to extend the PCB pipeline to the fab, so the system can send a finished design for manufacture and report on the order instead of stopping when the design is done. He also wants to bring the same closed loop to other labs, beyond the one other user on the system today. A further idea is a modular pod: a rack unit holding the instruments, a Raspberry Pi, cameras, and room for the device under test, a portable AI-driven hardware lab. The backlog holds more than 700 ideas, including shareable sessions and an extensions marketplace. On the day of the talk, the Hapimatic core was released as open source.
Questions from the room
Asked how he keeps remote work from damaging the test bench, Starfield said that safety comes from experience and guardrails, that he is usually still in the lab during development, and that every failure becomes a bug report fed back into the system. His standing question to it is:
What do we need to do to make this problem never happen again?
After long enough, he said, problems have become rare.
Asked about context degradation across sessions, and about agents chasing a problem in the wrong place, he pointed to the same habit of hunting down each failure, to larger context windows, to Hapimatic's own compaction system, and above all to GitHub. Each session leaves its useful output in the issue, and the next session starts from that record, so he no longer sees context degradation.