The Four Files That Let One Engineer Run an ODM

Everyone's writing about how AI will change hardware development. Almost none of it tells you how, the actual mechanics of getting an agent to do useful work on a real product without the whole thing turning to mush.

Here's the honest answer, and it's less glamorous than the think-pieces: it comes down to four files.

Not a platform. Not a fine-tuned model. Four plain-text markdown files that the engineer and every agent read from and write back to. They're the shared memory, the single source of truth, that lets one architect coordinate a swarm of agents across electronics, firmware, cloud, mechanical, and manufacturing without losing the plot.

The four files

architecture.md, the product's mind. System-level design: block diagram, interfaces, constraints, and (the part people skip) the philosophy of the product. Why it exists, what it must never do, which tradeoffs are already decided. An agent that reads this makes choices that fit the product, instead of choices that are locally clever and globally wrong.

product_spec.md, the contract. Electrical specs, firmware behavior, cloud endpoints, mechanical constraints, test requirements. Concrete and checkable. This is what an agent's output gets measured against: if it's not in the spec, it isn't real.

task_list.md, the work. Every actionable item, small enough to hand off. Agents pick tasks from here; the human supervises. It's the difference between "help me with firmware" (vague, unbounded, useless) and "implement the wake/sleep classifier per spec §4.2," which an agent can actually finish.

learning.md, the memory. Insights, mistakes, patterns, what we learned building this. This is the one nobody writes and everybody needs. It's what stops you, and your agents, from rediscovering the same dead end three weeks later. Over time it becomes a curriculum: the real education of how this product got built.

Why it's four files and not a tool

Because the bottleneck was never the tool. It was context.

An agent is only as good as what it knows about your product at the moment you ask. Dump the whole codebase on it and it drowns; tell it nothing and it hallucinates. The four files are the middle path: a curated, human-maintained picture of the product that any agent can load, act on, and update. The engineer curates the picture. The agents work inside it.

It's also why this generalizes. The same four files structure an air-quality instrument, an industrial controller, and a livestock tag, because the shape of the problem is the same even when the silicon isn't. Start a new product, start the four files, and every agent you point at it is instantly oriented.

The engineer leads; AI amplifies

Notice what didn't change. The engineer still owns the architecture, the integration, the decisions, and the quality gate. AI became the drafting assistant, the reviewer, the simulator, the documentation engine, the thing that keeps learning.md current.

The bottleneck moved. For twenty years the bottleneck in hardware was skill: you needed an EE, an ME, a firmware person, a cloud person, a test engineer, and a tech writer, and coordinating them was most of the job. The bottleneck now is system design: knowing what to build, how to decompose it, and whether the answer coming back is right. That's judgment, and it's the one thing AI can't hand you. You can collapse the cost of iteration, of documentation, of testing, of being wrong. You cannot collapse taste.

This is how we actually build

None of this is theoretical, it's how ARG runs. A cloud-connected industrial controller we shipped this year and our own iAQ-Pro instrument were both built this way: one architect, a set of files, and agents doing the drafting and review underneath (here's what that looks like day to day). It's why a company this size can run a full ODM (design, firmware, cloud, and manufacturing) without the department-sized headcount that used to be the price of admission.

The four files are the whole trick. They're boring on purpose. Boring is what survives contact with a real product.

You can collapse the cost of being wrong. You can't collapse taste.