Why: avoid premature optimisation

“Premature optimization is the root of all evil.”

“We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.”

Knuth's point was never "don't optimise". It was "don't optimise yet": find the critical 3% first, then spend the effort there. Hardware has the same trap, with a higher price. The premature optimisation in a hardware project is choosing the architecture first, because it is the familiar one or the one in the reference design, and then spending weeks polishing its bit widths, its timing and its area. The polish is real work, and it can still be work on the wrong design.

Avoid premature optimisation: exploration finds the critical 3% worth optimising.

Micro-optimise the default design, or explore first

The animation runs both strategies on the real M1 data, for the dds_250msps spec: a direct digital synthesiser that needs a new sin/cos pair at 250 million samples a second or more, with a maximum error of 2^-13. Every point is a design scored by the repository's own models.

Loading the animation…

Micro-optimise the default. Start from the reference design, the iterative CORDIC with a 16-bit datapath and 14 micro-rotations (the one in the reference RTL). It misses the accuracy target, so improve it the way a careful engineer would, one knob at a time: widen the datapath, add an iteration, add guard bits, change the rounding, keeping every change that helps. After 4 steps it meets the accuracy target, at 204 LUTs and 10.8 MSPS. No single move improves it further.

Then look at the whole family. The best any of the 39,690 iterative designs can do at this accuracy is 11.1 MSPS. The spec needs about 22× that. The equation says why: an iterative CORDIC delivers one result every $N+3$ cycles, and at this accuracy $N$ cannot shrink. No amount of polishing gets past that ceiling.

Explore first. Across all four families the true Pareto front for this spec has 56 designs, and every one is a fully pipelined CORDIC above 250 MSPS. The spec's own choice uses 905 LUTs at 264 MSPS: 24× the throughput of the best iterative design, at equal accuracy. The critical 3% here was one decision, the architecture family, and only exploration finds it.

An AI agent is the perfect environment for trade-off exploration

Exploring is the part engineers skip, because it is tedious and it looks like no progress. It is exactly the part an agent is good at:

• It is cheap. A complete exploration of one spec cost $0.0073 to $0.064 in LLM usage in the latest eval, depending on the model measured.
• It is tireless. Each run is a checkpointed LangGraph thread that can pause for a human and resume, so several agents can run around the clock, each on a real design decision.
• It explains itself. Every decision comes with the model's reasoning, recorded in the run's trace: why it ruled a family out, why it narrowed a range, why it stopped.
• A human still picks the point. The agent proposes; the graph pauses (interrupt()) to confirm the spec and to choose a design off the front.
• It never invents a number. The model chooses families, ranges and next steps. The golden model, the cost model and the optimiser produce every figure, so the numbers are as good as the models, and no better.

The agent does not replace the optimiser; it drives it. In milestone 1 it was the better selector, finding a design closer to the true optimum than NSGA-II or random search on every feasible spec, and the worse front-mapper: on two of the three specs plain NSGA-II covered far more of the trade-off curve. Milestone 2 let the agent ask the optimiser to map the front, and closed that gap (0.96–1.09× NSGA-II's hypervolume) while keeping the better selection in 8 of 9 cells. The agent finds the critical 3% for this spec, or proves there is none, and now hands back the whole trade-off curve around it.