Notes

A self-improvement loop with a referee

2026-08-17 4 min readagentsopen-sourcehardwarebuild-in-public

Nobody tapes out a chip to find out whether the design works. By the time a mask order goes in, the design has made its entire case in simulation, and the fabless industry stakes the cost of every mask set on that case holding. The bet keeps paying because the device models under the simulator are calibrated against measured silicon: the proxy inherits the grounding of every wafer that came before it. Simulation is not a rehearsal for the real evidence. Commercially speaking, it is the evidence.

The four criteria

That arrangement matters beyond fab economics, because it is the rock most arguments about self-improving AI systems run aground on. A system that improves itself needs a referee it cannot fool. The author and technologist Ramez Naam put four criteria on one slide at a seminar this month, describing the domains where machine self-improvement has actually worked: evaluation that is near error-free, task volume that is effectively unlimited, feedback at machine speed rather than real-world pace, and a metric that measures the thing you care about instead of a proxy you can game. The slide is below, shared with his permission. Go clears all four, which is how self-play produced a superhuman player. Most of engineering fails the list somewhere, usually on the first criterion or the last.

Slide titled "What Highly Verifiable Means" listing four numbered criteria, each with an example: 1. Error-free evaluation — we can reliably determine whether an answer or action is correct (Go win/loss, theorem-prover proof checking). 2. Unlimited data volume — new games, tasks, or examples can be generated essentially without limit (self-play or procedurally generated problems). 3. Machine-speed feedback — outcomes are produced and evaluated as fast as compute allows, not at the pace of the real world (millions of simulated games overnight). 4. Measures what we actually care about — the metric closely matches the true goal, instead of being an easy-to-game proxy (actual game-winning, not just a flawed benchmark).
Ramez Naam's four criteria for highly verifiable domains, from his seminar talk. Slide reproduced with permission.

Chip design comes closer to clearing it than almost anything else with a physical product. Design-rule checking and layout-versus-schematic are deterministic: the geometry passes the rules or it does not; the layout matches the netlist or it does not. SPICE sits just behind them, exact about the circuit it was asked about and only as truthful as its device models. Task volume is no ceiling either, because every block multiplies into process corners, temperatures, supplies, seeds, and testbench variations, and the list of blocks worth designing is long.

Three speedups, stacked

Naam's third criterion is where the domain gets interesting, because the speedup is a stack, not a single term. Silicon feedback runs at months per experiment; simulation collapses that to hours. Every chip company has had that term for decades. Put an expert human between the runs, though, and most of the gain leaks back out: setup, interpretation, and the choice of next experiment happen at working-hours pace, one design at a time. Agents close that loop continuously and in parallel across blocks. The release notes for Qwen3.8-Max carry a case study of exactly this shape, an accelerator driven through roughly 500 autonomous turns and 71 evaluations with no human in the loop, on an open toolchain; our 2026-08-03 pulse covered it. Commercial EDA then adds a third term that rarely gets framed as a speed problem: licenses. A seat-rationed tool caps loop iterations economically, whatever your compute budget, while on open tools iteration count scales with compute. So the stack is agents over human pilots and open tools over seat-rationing, and our whole operating model is built on running both. The economists have arrived at the same structure from the other direction: a recent NBER working paper by Davidson, Halperin, Houlden, and Korinek models feedback loops across research sectors and finds that automating software research alone does not produce explosive growth, but adding even modest automation of adjacent sectors, chip design first among them, can.

Where simulation leaks

Every version of this conversation lands on the fourth criterion: surely simulation is a proxy, and proxies get gamed. The gap between simulation and silicon is real, and it splits in two. Model fidelity is the smaller half, priced into every commercial tapeout, though wider in our arena than most: sky130 and gf180mcu models have seen less silicon than a foundry's paid decks. The larger half is measurement methodology, testbenches answering a different question than the one they were named after. That is where our own documented failures live. The LDO episode in the wave-two note involved no silicon at all: the loop-stability numbers were real, the quantity was wrong, and the error was found and corrected entirely in simulation. GateTruth, a paper in this week's pulse, makes the general version of the point: a testbench that never fails is not evidence of a correct design. Which argues for the thesis rather than against it. The failure modes that remain are in-loop failures, detectable and correctable at machine speed, and a signal this clear can still be gamed, but not quietly.

Improving the improver

None of that is self-improvement yet. An agent iterating a design toward spec is just fast engineering. The recursion sits one level up, and it is already public: agents doing block work file friction issues against klayout-tools as they hit walls, the tool improves, and the next block starts further ahead. When gf180-bandgap's sim harness, schematic editor, and layout tooling each reimplemented the same PDK lookup differently, that became a public issue against the tool instead of a workaround; the same tool later grew a spec-review capability, and that review is what caught the bandgap's ±1% spec being arithmetically impossible. Improving the design is not the interesting loop. Improving the thing that improves the designs, from design outcomes, is.