The Model Eats the Harness

In 2019, Richard Sutton wrote a one-page essay called The Bitter Lesson.^[1]

His thesis was simple, and for anyone who had built a career on clever domain-specific AI, deeply unwelcome. Across seventy years of AI research, general methods that scale with compute have beaten methods that bake in human domain knowledge.

Every time. By a large margin.

Chess: search beat grandmaster heuristics. Go: self-play beat centuries of encoded human strategy. Speech recognition: statistical models beat phoneme and vocal-tract engineering. Computer vision: convolutional nets beat SIFT and HOG and every other hand-crafted feature. Natural language: transformers beat parse trees and part-of-speech tagging.

Sutton's punch line, the one people are still arguing about, is that building in how we think we think doesn't work in the long run.

You can watch this pattern playing out in real time.

Tesla's FSD v11 had roughly 300,000 lines of C++ encoding rules about roundabouts, lane changes, and traffic light behavior. FSD v12 deleted essentially all of it in favor of one neural network mapping camera pixels directly to steering commands.^[2] The underlying idea, learning to drive directly from pixels rather than through a hand-engineered perception pipeline, goes back to work like NVIDIA's 2016 end-to-end steering paper.^[3]

Wayve, the London-based autonomous driving company, calls this "AV2.0": no HD maps, no hand-engineered perception stack, one model end to end.^[4]

OpenAI's Sora generates 3D-consistent video without anyone ever telling the model what 3D is. OpenAI's own description of Sora's spatial reasoning is characteristically dry: "purely phenomena of scale."^[5]

The pattern is consistent. The model eats the pipeline.

Why we still need to build the harness

At Circuitly we build AI tooling for electrical engineers. Schematics, PCBs, netlists, the whole EDA stack.

And every day we make a decision that seems, on its face, to be on the wrong side of the bitter lesson. We wrap language models in elaborate scaffolding. Constraint solvers. DRC checkers. SPICE integrations, routing solvers. Structured tool calls for placing components and routing traces.

If Sutton is right that scale eats scaffolding, why are we investing in scaffolding?

The short answer is that traditional LLM approaches are spectacular at code and terrible at schematics and PCBs. The gap between those two things tells you almost everything you need to know about where most AI tools are and are not useful today.

Code is a token stream. A write_file tool call is nearly isomorphic to what a language model already produces, a linear sequence of characters that either compiles or does not. Compilers, test suites, and type checkers give fast, textual, high-signal feedback. The whole loop fits the model's native shape.

Schematics do not.

A schematic is a 2D constraint graph. Components placed spatially, nets running between them, orientation and grouping and hierarchy and human-centric idioms all mattering simultaneously. A PCB is worse. It is a 3D physical artifact with return paths, controlled impedance lines, thermal zones, EMI considerations, mechanical constraints, and manufacturability rules, some that only reveal themselves at fabrication time.

The feedback loop is slow and expensive. And critically, the output has to be globally consistent, with every trace agreeing with every other trace and every component position agreeing with every net topology.

Not just locally fluent.

Here's a concrete example. If you ask an LLM to produce a schematic by emitting x- and y-coordinates for every part, it fails badly. Components overlap. Nets cross unnecessarily. Pins float in space unattached to anything.

This is not because the model has never seen schematics. It has seen thousands of them.

It fails because you are asking a transformer to do the one thing transformers are worst at: emit a long stream of precise numerical coordinates that all have to agree with each other, with no incremental way to check its work.

The harness move is to invert the problem.

Instead of asking the model for schematic coordinates, you allow it to express intent by giving it a vocabulary of constraints. This op-amp's output is left of that resistor's input. This bypass capacitor is within 5mm of that IC's VCC pin. This bus runs horizontally above that row of components.

The model reasons about constraints. A Cassowary-style solver, the same deterministic 1970s algorithm that powers Apple's Auto Layout, computes the actual coordinates.^[6] The model never touches a number it cannot justify symbolically.

This works because it plays to what LLMs are genuinely good at, which is symbolic reasoning about relationships. And it offloads what they are bad at, which is globally consistent numerical optimization, to a piece of computer science that is exact, fast, and never hallucinates.

It is the AI equivalent of putting a calculator next to a mathematician. The mathematician still does the reasoning. You just don't ask her to multiply seven-digit numbers by hand.

The frontier moves. The harness follows.

The obvious objection to all of this is the one Sutton himself would likely have raised.

With enough compute and enough schematics in the training set, a future frontier model will just emit coordinates directly, and they will be correct. The constraint solver will look, in retrospect, like a quaint transitional technology.

The model will eat the harness.

That is probably true, despite today's challenge that unlike literature, images and code the best electronics data to train on are not public.

It also matters less than it sounds like it should.

What people miss about the bitter lesson is that when the model eats the harness, the harness moves up the stack.

Look at how this has already played out in code, which is the most valuable model-native domain we have. LLMs ate syntax highlighting. They ate autocomplete. They ate linters and simple refactoring tools.

And the IDEs got bigger, not smaller.

Cursor, Codex and Claude Code are vastly more elaborate harnesses than bare VS Code was, just operating at a higher level of the stack. Sandboxes. File tree awareness. Test runner integration. Version control operations. Long-horizon planning. Multi-file edits.

The harness moved from help the human type to give the agent enough context to do useful work autonomously.

Tesla is the same story in a different domain.

They deleted 300,000 lines of C++, but they did not ship less code overall. They shifted to enormous fleet data pipelines, shadow-mode evaluation infrastructure, custom training compilers, and simulation environments that dwarf the old rules engine in complexity and value.

The old harness died. The new one is more valuable than the old one ever was.

This is the pattern I would bet on for every AI-augmented domain. The harness that exists today will get eaten. A new harness, operating at a higher level and doing harder work, will take its place.

And then that one will get eaten too.

So the claim is not that Circuitly's constraint solvers will live forever. The claim is that something will always be load-bearing at the frontier, because the frontier keeps moving. At every level of that stack, somebody has to look at the model, look at the domain, and figure out what the model cannot quite do yet.

That is not a model task. It is a taste task.

The human who operates it

The part of this argument I care about most is what it means for the people who work inside these systems.

Every harness is a human's bet on what the model cannot do yet.

Every harness needs someone to operate it. Despite all the autonomy we grant our agents, someone who knows the domain well enough to ultimately give it the right inputs and judge whether the outputs are sound.

When a Circuitly user tells our system which nets on this board are critical, which components are thermally sensitive, or which corner of the layout has to stay under a mechanical keepout, those are not facts the model can generate only from first principles. It is context about their specific design, their specific product, their specific set of tradeoffs.

Some of that context lives in the engineer's head. A lot of it doesn't. It lives in the mechanical CAD files, the product requirements doc, the Slack thread from three weeks ago where the industrial designer changed the enclosure height, the BOM constraints coming from the ops team, the thermal simulation someone ran last quarter.

The more of that context we can pull into the harness, the more the harness can reason on its own. Connect the mechanical files and it knows about the keepout. Connect the product spec and it knows the FCC target. Connect Duro PLM and Slack and it knows about the enclosure change before the engineer has to remember to tell it. The harness gets smarter every time it gets wired to another source of truth.

Which is exactly the operator's job. Not to hold all the context in one head, but to decide what the harness should see, how much to trust what it produces, and when to override it. The frontier moves from "the engineer knows the whole design" to "the engineer curates what the system knows about the design."

The bitter lesson eats hand-engineered features. It does not eat the engineer who knows which sources of truth the system should be reading, and which conclusions from those sources deserve a second look.

As harnesses move up the stack, from autocomplete to agents, from rules to fleet data, from coordinates to constraints to whatever comes next, the judgment required to operate them well moves up too.

The operator role gets more demanding as the tools get more capable, not less. The operator is making decisions about which pieces of an increasingly complex system to trust and which to override.

There will always be room for a harness. So there will always be room for the human who operates it.

That is the bet we are making at Circuitly. Not that constraint solvers are eternal, because they aren't. But that engineers are.

Long live the engineers.

If your team is evaluating an agentic strategy for PCB design, talk to us.

References

1. Richard S. Sutton, "The Bitter Lesson", March 13, 2019.↩
2. Elon Musk described the shift on a livestream demonstrating FSD v12 in August 2023, framing v12 as an end-to-end neural network trained on video that replaced the roughly 300,000 lines of C++ that constituted v11's driving policy. See Not a Tesla App, "Musk Livestreams FSD V12 Showcasing Massive Improvements" (August 2023), and Electrek, "Let's talk about Elon Musk's potato livestream of Tesla FSD v12" (August 28, 2023).↩
3. Mariusz Bojarski et al., "End to End Learning for Self-Driving Cars", NVIDIA, April 25, 2016. arXiv:1604.07316.↩
4. Wayve, "A new approach to self-driving: AV2.0". See also Alex Kendall's interview on the Sequoia Capital Training Data podcast, "How End-to-End Learning Created Autonomous Driving 2.0" (November 2025).↩
5. OpenAI, "Video generation models as world simulators" (Sora technical report), February 15, 2024.↩
6. Greg J. Badros, Alan Borning, and Peter J. Stuckey, "The Cassowary Linear Arithmetic Constraint Solving Algorithm", ACM Transactions on Computer-Human Interaction, Vol. 8, No. 4, December 2001, 267-306 (free PDF). The algorithm dates to Borning's earlier ThingLab work in the 1970s; the ACM paper is the canonical modern reference. Apple's Auto Layout, introduced in OS X 10.7 (2011) and iOS 6 (2012), uses a Cassowary-derived constraint solver.↩