Why you need a harness, not a chatbot

Every few weeks someone shows us a demo where a language model draws a schematic in a chat window, and asks why we bother with all the machinery — the checkers, the version control, the distributor APIs, the review gates. Why not just let the model design?

The answer is the same reason airlines don't "just let the pilot fly." The pilot is essential and also insufficient. Modern aviation is safe because of everything wrapped around human judgment: checklists, instruments, cross-checks, a second pair of eyes on final approach. Remove the wrap and the same pilot becomes dramatically more dangerous, not because they got worse, but because nothing catches the day they're wrong.

A harness is that wrap, for AI in electronics. It's the difference between a model that talks about circuits and a system you'd let touch a design that ships.

What a harness actually is

Strip the word down to its engineering content and a harness is four commitments, stacked:

• Native files. Agents read and write the same KiCad, Altium, Cadence, or Siemens files your team edits and your fab consumes. No screenshots, no lossy intermediate formats, no "we'll convert it back later."
• Deterministic checks on everything. Every agent-proposed change passes through verification that runs as code — ERC, DRC, netlist comparison against the schematic, footprint pin-count against the datasheet, BOM lines against lifecycle status. Not "the model reviewed its own work." Code. Same input, same verdict, every time.
• Live data. When an agent selects a part, the package, stock, price, and lifecycle status come from distributor and PLM APIs at that moment. The model's memory is treated as a rumor until a database confirms it.
• Diffs and review. All of it lands in version control as a change a human can see, question, and merge — or reject. The agent proposes; the engineer disposes.

Notice what's not on the list: a smarter model. The harness is deliberately model-agnostic. Models leapfrog each other every few months; the harness is the part of the system that doesn't churn, and it's what lets you swap the model underneath without re-earning trust from scratch.

Because electronics is unforgiving

The case for the harness starts with the physics of the domain. Software failures are cheap and reversible — that's why AI worked there first, and why the "just ship it and iterate" culture exists at all. Electronics failures are neither. A swapped pin pair survives every visual inspection, passes an under-constrained ERC, and announces itself at bring-up as a dead board — or worse, three months later as a thermal failure in the field. The feedback loop is measured in fab weeks and the tuition is measured in respins.

In software, you can afford to discover that the AI was wrong. In electronics, you have to prevent it — or catch it while it's still a diff.

This is the asymmetry that breaks naive AI adoption. A model that's right 95% of the time is a miracle in a domain with cheap failures and a menace in a domain with expensive ones. You cannot close that gap by prompting harder. You close it by putting deterministic machinery on the output path — machinery that doesn't get tired, doesn't skim, and treats the 20th change of the day exactly like the first.

Two kinds of work, two kinds of machinery

The design of a harness follows from one observation: engineering work splits cleanly into decisions that have a right answer and decisions that have a defensible answer.

Whether the netlist matches the schematic has a right answer. Whether pin 4 of that regulator is EN or PG has a right answer — it's printed in the datasheet. Whether your creepage clearances meet the rule you set has a right answer. Every one of these should be checked by code, because code is the only thing that checks the same way at 5 p.m. on a Friday as it does on Monday morning.

Whether to use a two-stage filter or a bigger inductor; whether the BOM should absorb a 40-cent cost increase to stay single-source; whether that layout compromise near the connector is acceptable — these are judgment calls where competent engineers legitimately disagree. This is where a model's reasoning genuinely earns its seat, and where its proposal deserves a human reviewer rather than a rubber stamp.

The harness routes each kind of work to the right machinery: agentic judgment for the open questions, deterministic verification for the closed ones, and human review as the final gate on both. Most failed AI-for-hardware products die by mixing these up — asking the model to verify (it will confidently approve its own hallucination) or asking rigid automation to make judgment calls (it will optimize the wrong thing precisely).

What goes wrong without one, specifically

It's worth being concrete about the failure modes, because each layer of the harness is a scar with a story:

Note the pattern in the last column: every failure mode ends in lost trust, and trust is the actual currency here. Engineers don't abandon AI tools because the tools are useless — they abandon them after the first unexplained, unverified, expensive mistake. The harness isn't just error prevention; it's the mechanism by which a tool stays trusted long enough to compound.

The precedent: software already ran this experiment

If the harness sounds elaborate, remember that software engineering already ran this exact experiment and published the results. AI coding agents became trustworthy not when models crossed some intelligence threshold, but when their output was forced through the existing discipline: branch, commit, CI, tests, review, merge. The infrastructure that had been keeping humans honest for fifteen years turned out to be exactly what kept the machines honest too.

Electronics never built that infrastructure — not because hardware engineers are less rigorous (they're more rigorous, out of necessity) but because their rigor lives in processes and people rather than in tooling: the senior engineer who reviews everything, the checklist in a wiki, the design review meeting. That rigor doesn't scale to an agent making forty changes an hour. Encoding it into machinery — checks as code, review as diffs, history as version control — is what a harness is. It's not a new idea. It's CI/CD, finally arriving at the discipline whose mistakes cost the most. (More on how the pieces map in our guide to agent concepts for EEs.)

The question that follows

Once a team accepts the argument, the next question is always the same: do we build this ourselves or buy it? Building one means solving native format access for every ECAD tool you use, writing and maintaining the deterministic check suite, integrating distributor and PLM APIs, and keeping all of it current as models and tool versions churn underneath you. It's a real platform, not a script — we wrote an honest accounting of what it takes in how to build an internal AI program for electronics.

But whichever way a team goes, the conclusion of this article is the same: the harness isn't overhead on the way to AI value. It is the AI value. The model was always the easy part to acquire — it's an API call. The loop around it is the part that decides whether AI in your electronics org becomes a compounding asset or a cautionary tale told at design reviews.

Frequently asked questions