← Essays /Post · 02 of 20 · Thoughts

SpotOn: The Two Seats a Harness Can't Fill

I re-sorted the twenty-eight disciplines a hardware product needs. Twenty are files, so the harness owns them. Six stop at a doorway. Two stay human.

·5 min read · · · #build-in-public#solo-founder#hardware#ai-agents#org-of-one
SpotOn: The Two Seats a Harness Can't Fill
On this page

I was a little proud of the last few posts. Agents wrote the firmware, built the app, ran the ML pipeline, spun a PCB. On my own.

Then I got curious. What does it actually take to put a product in front of real people? I sat down and made a list. Firmware, app, backend, PCB, enclosure, power, certification, tooling, marketing, finance, legal… by the time I stopped, there were twenty-eight. Only twelve of them were things I’d call “development.”

I looked at the list again. Every code seat, an agent already had. That’s when I saw why the whole company had felt handled. Code is all files anyway. The other sixteen, I’d been quietly skipping as I counted. Certification? Tooling? Insurance? I’d shoved those to the bottom of the list as “later problems.”

The earlier posts were all a development lens. But development is only twelve of the twenty-eight seats. I’d mistaken those twelve for the whole company. I counted the seats I know how to sit in, and pretended the ones I don’t weren’t there.

The real axis was ‘is it a file?’

At first I asked each discipline the same thing: can an agent do it? That axis broke fast. The line between what an agent can and can’t do didn’t line up with development-vs-not. The real split was somewhere else. Does the output end as a file, or not?

Everything an agent emits is a file. Code is a file, but so is a doc, a CAD model, a config. So the file-ending seats are scattered well outside development. A few examples. A positioning doc isn’t development, but it’s a text file in the end. So is the product roadmap, the landing-page code, the first draft of a certification file. Even security hardening is mostly editing config files. None of them look like development, yet each one lands as a single file. So development or not, all of these went to an agent.

The backend was the sharpest case. I’d planned to stand up a dedicated server and keep running it, a whole discipline bolted on. Then I moved to a BaaS and store billing, and the “run a server” discipline vanished. What was left was a few config files. One person’s job evaporated into a few lines of config.

The seat that only takes you to the doorway

Not all of it ended this cleanly in a file. For some seats I finish the design, the paperwork, the modeling as files, and then one more step is bolted on that leaves my hands.

Take the RF antenna. Where the module sits, how much metal to keep clear around it (the keepout), I draw all of it. That part is a file. But whether the antenna actually passes spec only comes out when you put the board in front of a certified lab’s instruments. That measurement is not a file.

Tooling is the same. How to design the mold, whether it will injection-mold cleanly (the DFM review), I do all of that as files. But cutting the actual steel to make the mold is the mold shop’s job. Certification too: I write the whole technical file and the application. But the physical test at the lab is the one thing I can’t do for them.

A pattern showed up here. A file carries me to the doorway. But crossing that threshold was always one of three things: a physical measurement (real instruments, a real board), a purchase (buying an insurance policy, securing a part allocation), or the judgment of a licensed person (a patent opinion from an attorney). An agent stacks the paperwork right up to the door. It can’t open the door.

Design and paperwork I finish as files reach a doorway; the three crossings past it, a physical measurement, a purchase, and a licensed judgment, are dashed to mark the steps I can't do

The two asterisks on ‘mine’

Counting up: twelve are code, twenty end as a file. The other eight have nothing to do with development, but they’re files, so they’re mine. Six make it to a doorway; two are fully outside. Here is how the twenty-eight split.

In-house · 20 (end as a file): firmware, PCB, power/battery, enclosure CAD, on-device ML, mobile app, iOS, backend, web/landing, security, PM, UX/UI, marketing, signal-integrity bench, sensor bring-up, data collection, QA/reliability, program management, planning/strategy, demand validation

Doorway · 6 (I design it, one last step is external): RF/antenna, tooling/molds, incoming inspection, certification, business/legal, finance/supply chain

Human · 2 (stay a person): industrial design, domain expert

But “mine” comes with two asterisks. A file-ending job still takes time and carries conditions.

The first asterisk is physical. Six of those twenty (the signal-integrity bench, sensor bring-up, QA/reliability, and the like) need a real board in hand before I can touch them. However much I prep in files, execution is zero until a cheap fab run puts a board on my desk. The signal bench especially is my first kill gate. If the signal doesn’t come out clean there, the product stops there. An agent can’t sit here. I know that from being blocked, not from a doc.

The second asterisk is order. Any cash that goes outside (a lab quote, tooling, insurance) gets spent only after the demand gate passes. I finish the design in files now, but the wallet opens after “is anyone actually going to buy this” is settled. Last post I confessed I’d built it backwards. Here that regret turned into a rule.

So “twenty are mine” is only half right. It means no outside person is attached. That’s all it means. Six of them wait on a board; all twenty wait on validation.

The two seats a person ends up in

The two that are fully outside are industrial design and the domain expert. Why those two? Because for both, the output never quite lands as a file.

Industrial design first. Ask an agent for an STL or a render and it delivers. That’s a file. But industrial design’s real value shows up when the thing is in your hand: the feel, where the weight sits, the line your eye catches. Numbers on a drawing don’t hold that. The eye that says “this is a good form” is a trained person’s. A file only holds the shadow of the form.

The domain expert is a bit different. What that person sells is trust. Knowledge you can copy into a document, and that’s a file. But the fact that their name on the product is what makes people believe it, that reputation doesn’t transfer across a hundred pages. Trust doesn’t fit in a file.

The common intuition is that AI replaces coding first. My experience matched it. Coding went over first. Because it’s files. What stayed in human hands to the end was the eye for form and a person’s name. The most defensible seats in the company turned out to be exactly those.

These days, when a new discipline shows up, the first thing I check is whether it ends in a file. When it does, I hand it to the harness and stop thinking about it. When it doesn’t, that’s the part that’s actually my job now. A physical act, a purchase, someone’s trust.

Twenty-six seats went to the harness. The two that are left are empty, and that’s where my time and money go now: finding the right industrial designer, and finding someone whose name the product can borrow. That search is the work the harness freed me up to do.

ecro
Written by ecro

Created an LLM benchmark for firmware. EmbedEval →

Building a project-shaped agent harness for Claude Code, Cursor, and Codex. harness-maker →

Building a terminal that reads your datasheets. NeuroTerm →

Comments

Loading comments...