Two levels: a router, and something to tell it what you meant

Default Avatar
Alain-Sam Cohen

We spent 38 minutes on the Altium OnTrack podcast talking about why autorouters fail, routed three boards submitted by Zach Peterson’s community, and said out loud which parts we can’t handle yet.

A routed four-layer board in the DeepPCB web app, with the revision history listed beside it.
The same board after the run converged.

Watch it: https://www.youtube.com/watch?v=apvE_ElRhiA
Listen: https://podcast.altium.com/e/ai-pcb-routing-without-the-epic-fails-inside-deeppcb/


Zach Peterson opened with the question we get most often. How do you tell an AI tool what you want, so you don’t end up with an epic hardware fail?

If the intent isn’t in the file, an optimiser can’t invent it. A tool that only optimises will happily route your ground net as a signal, because that’s what the layer type says. It will give every trace the same width, because nothing in the file says otherwise. Then you get traces everywhere and you conclude the autorouter doesn’t work. Two hours is not an exaggeration, and it’s worth its own post: what an autorouter configuration actually involves, and what the router does when nobody does it.

Why autorouters have a bad name

Nabil put it plainly. Autorouters don’t fail at routing. Nobody configures them, and configuring one properly takes about two hours. At that point you’d rather route by hand, so you do, and the tool keeps its reputation.

Routing isn’t connecting points. You have to know what a route is doing. Whether there’s a plane under it. Whether it’s USB and needs impedance matching.

So DeepPCB is two things

The Cooper assistant panel offering an overview of the board's configuration.
Cooper reads the board first and says what it found.

The low level is the routing engine. It’s a reinforcement learning router, it’s what DeepPCB has been for years, and it’s the part we’ve spent seven-plus years on. You give it a board, it lays copper, and the result is DRC clean.

On top of that sits Cooper. Cooper is a natural-language assistant whose job is to get your design intent into a form the router can use. It reads your board, tells you what it found, and proposes changes. It has skills, in the same sense that Claude Code and Codex have skills. Change a layer type. Change a track width. Put this net in that class. Route this net for ten minutes.

Cooper orchestrates the routing engine. It doesn’t lay copper.

The part that answers the “won’t a frontier model just do this” question

Cooper runs on an LLM provider. It could run on a different one next month and the product wouldn’t change.

Take the routing engine out and there’s very little left.

That’s why we don’t treat the companies generating schematics from a prompt as competitors. They do that part well. Then they want placement and routing, try an LLM, and find out models are bad at geometry. We’d rather be the compiler for those tools than compete with them. The longer version of that argument is here: why AI generated schematics still need a router, and what we mean by being the compiler. 

The demo, on boards we didn’t pick

Two DeepPCB layers panels side by side: ground and power typed as signal on the left, as power on the right.
Before and after. The same two layers, typed as signal and then as power.
A Cooper suggestion reading "Set GND layer type to POWER", with accept and reject controls.
Cooper proposes, you accept or reject, one at a time.

The boards weren’t ours. We received three from Zach’s community and routed them. On the one we started from scratch on air, Cooper flagged the layer types first, which was the problem we’d just been describing: GND set to signal, power set to signal. It found the notable nets, the decoupling-capacitor rules and some pin-sequencing anomalies, then offered six changes. We took five and left one. You can reject anything Cooper suggests.

Then we let it route while we looked at a run we’d let converge before recording. Fifty seconds of routing is not a board you send to fab. Let it run.

What we don’t support, said on air

A second, more complex board in DeepPCB with Cooper summarising the changes it applied.
A harder board. Arc support is still early, so we kept its arcs and routed from there.

One of the three was considerably harder. Our support for arcs is still early and that board is full of them, so rather than swap it for something friendlier we kept its arcs and routed the board from there. We said that on the episode rather than quietly picking an easier board.

Where this goes

The layers panel after the fix, with ground and power now typed as power layers.
After the fix, with the existing copper protected.

Three roadmaps. Research out of InstaDeep feeds the engine. The missing features get built. And Cooper moves off the side panel into the canvas, so you can point at a congested corner and ask for it.

Routing quality and speed stay the top priority. Everything else is only worth having if the copper is good.

Benchmarks go on this site, run by run, including the revisions that didn’t work.

Full conversation with Zach Peterson on the Altium OnTrack podcast.

Watch: https://www.youtube.com/watch?v=apvE_ElRhiA
Listen: https://podcast.altium.com/e/ai-pcb-routing-without-the-epic-fails-inside-deeppcb/