Agents Propose Diffs. Humans Approve.

The AI-in-engineering conversation is asking the wrong question. Every week brings a new demo of an agent editing a schematic, rerouting a board, or generating a bracket — and every week the commentary fixates on model capability. Is it smart enough yet? Can it design the whole thing?

The wrong debate is capability versus intelligence. The right one is capability versus context. Nobody ships a production board that a model drew unsupervised, and that isn't because the models are dumb. It's because hardware engineering has no place to put an agent's output where it can be inspected, validated, and approved before it becomes product truth.

Agents propose diffs. Humans approve. That sentence is the whole strategy. Everything else is implementation detail.

The wrong debate

Software already ran this experiment. The winning pattern there wasn't autonomous commits — it was the pull request. Agents draft, CI runs, a human reviews, the diff lands or it doesn't. Nobody argues that coding agents should have push-to-main access. The industry converged on propose-and-review because it preserves speed while keeping a verifiable chain of custody on every change.

Hardware skipped that conversation because it never had the infrastructure. There is no hardware equivalent of CI that's universally wired up, no standard pull request against a product definition that spans mechanical, electrical, and firmware. So the debate stays stuck at the capability level: watch a model route a board on a demo livestream, argue about whether it's ready, repeat.

The benchmark data says capability isn't the bottleneck. Agents built for software lose 37% to 58% of their resolved rate when moved to hardware tasks — not because the models got dumber, but because hardware bugs propagate across parallel instantiated modules through signal flow rather than along a software-style call graph. Software-tuned agents stop at the symptom file instead of tracing back through the instantiation chain. The same agent, the same weights, the same scaffolding — pointed at a problem where context is everything, it collapses. That is a context problem, not a capability problem.

What agents actually lack

Strip the demos down and the missing pieces are the same in every shop:

Product state. An agent that can read a schematic but can't see the current BOM revision, the open ECOs, or which revision is actually released is guessing. It has a file; you have a product.

Dependencies. Change a capacitor value and the agent should know the ripple budget, the derating policy, the approved-vendor list, and the three other nets that share that rail. Most agents see a graph of components. You need a graph of constraints.

History. Why is this trace 8 mil instead of 6? Because three years ago a field return taught you something. That knowledge lives in a Jira ticket, an email, or a senior engineer's head — nowhere the agent can read.

Permissions. Who is allowed to touch the power section? Who signs off on a stackup change? In software this is CODEOWNERS. In hardware it's tribal knowledge.

Validation. This is the big one. A software agent gets a compiler, a test suite, and CI for free. A hardware agent gets… a DRC run if someone wired it up, and good luck with the rest. An MIT study of agentic AI in engineering landed exactly here: adoption is constrained less by model capability than by fragmented and machine-unfriendly data, limited API access to legacy toolchains, and missing verification frameworks. Read that again. Not capability. Data, APIs, verification.

When the validation layer is missing, teams build it by hand — or they don't use agents at all on anything that matters. Both outcomes point at the same gap.

The pattern the market is improvising

Look at what practitioners are actually doing and the shape of the future is visible in the scaffolding.

Electronic design benchmark EEBench grades agents on real circuits with deterministic SPICE checks — the closest thing hardware has to a test suite for agents. The best models land around 60% on the leaderboard, and the benchmark's own conclusion is blunt: they wouldn't ask an agent to design a pacemaker and blindly install the result. Human review isn't a nicety. It is the evaluation layer.

Meanwhile, the community is hand-building the missing tool access. There are now half a dozen open-source MCP servers bridging agents to KiCad and Altium — schematic manipulation, PCB routing, EMC and signal-integrity review — written by individuals and small shops because the vendors don't ship native agent APIs. PTC just launched a native FeatureScript MCP server for Onshape, which tells you the vendors see the gap too. But notice what all this scaffolding has in common: it gives agents access, not judgment. Every one of these tools assumes a human is still in the loop, watching the session, reviewing the diff.

The most telling finding from the hardware-agent benchmarks: give an agent one round of testbench feedback — tell it where the bug is and what the fix has to look like — and its resolved rate jumps 42% to 45%. Feedback and verification do more work than any model upgrade. The market is converging, from both ends, on the same architecture: agent proposes, infrastructure validates, human approves.

Propose diffs, never commits

So here is the thesis, stated as an operating rule: Propose diffs; never commits.

An engineering agent should never write directly to the product definition. It should produce a proposed change — a diff against the current state, with rationale, with the affected constraints enumerated — and submit it to a gate. The gate runs validation. A human reviews. Then, and only then, does the change land.

This is not anti-agent conservatism. It is the only architecture that survives contact with production hardware, for three reasons:

First, hardware changes are expensive to undo. A bad software commit costs a revert. A bad hardware change costs a respin, a line-down, or a field return. The asymmetry between "propose" and "commit" is the entire business.

Second, diffs are reviewable and commits are not. A diff says: here is what changed, why, and what it touches. That is the unit of engineering judgment. An autonomous agent mutating the design in place produces archaeology, not engineering — a feature tree nobody can reason about, with no recoverable design intent.

Third, the approval gate is where your organization's knowledge actually lives. Derating policies, approved vendors, sign-off matrices, lessons from the last field return — none of this is in the model. It belongs in the gate, enforced the same way every time, whether the change came from a senior engineer or an agent at 2 AM.

Stop bad hardware changes before they ship. That is the job. Not "let agents design everything" and not "keep agents away from everything." The gate.

What the approval gate needs to check

If propose-diffs is the pattern, the gate is the product. Here is the minimum viable checklist — the things every proposed agent change should clear before a human sees it:

1. Scope. What exactly changed, against which revision? The diff must be computable and complete. No silent side effects in files the agent "didn't touch."
2. Constraint conformance. Every affected design constraint — electrical, mechanical, thermal, manufacturing — checked against the current rule set, not the agent's memory of the rule set.
3. Dependency impact. What else does this change touch? Cross-discipline effects enumerated: the schematic edit that moves a connector, the connector move that breaks the enclosure, the enclosure change that fails the drop test margin.
4. Traceability. Who proposed it, when, with what inputs, under whose authority? The audit trail starts at proposal, not at approval.
5. Human sign-off routing. The right approver for the blast radius — power section changes go to the power engineer, stackup changes go to the SI lead. Permissions encoded, not assumed.
6. Rollback plan. If this ships and it's wrong, what is the path back? For hardware, "revert the commit" is not always an answer. The gate should know that.

None of this requires a smarter model. It requires shared product context and validation infrastructure — the exact things the research says are missing. Build the gate, and every agent gets better overnight, because every agent finally has somewhere to submit its work.

The industry keeps asking when agents will be capable enough to design hardware autonomously. Wrong question, wrong finish line. The finish line is a governed loop: agents propose diffs, infrastructure validates them, humans approve. The teams that build that loop first won't just use agents more safely — they'll use them more, on harder problems, faster than everyone still arguing about capability.

Agents propose diffs. Humans approve. Build for that, and the capability debate takes care of itself.