No, that's a bad analogy. A circuit board is not something that gets re-built every time you make a change. You can't just arbitrarily run traces around a board and expect a working design that meets EMI/EMC requirements.
I'll coin a new term here to classify this kind of problem: NP-incomplete. A problem that's known to be NP-hard, and is actually now impossible because you the program doesn't have all the information it needs to solve the problem.
To properly route a board, the tool would need to know what kinds of loads are at each end of a net, how thick the trace needs to be, where the return path for the current loops involved are, the edge transition times of all signals on the board.
You have to know not to route delicate high-impedance signals next to high dV/dt power traces, how to properly split and combine ground planes, how to respect creepage/clearance requirements for voltage isolated systems, etc.
About the best we can do today is to use autorouting for not-so-critical traces after the work for everything else is done, and even then it only really works well when you have PCB area to spare. In the worst cases, like some 2-layer boards, an autorouter will inappropriately chop up your ground plane with the traces it needs to route and turn what was a good board with solid return paths into a poorly routed mess.
The reason autorouting sort of works in VLSI devices is because all of these requirements are baked into the tools themselves. Every signal has a timing requirement, an impedance requirement, fanout limits, etc. When you are only dealing with digital logic, it makes the job much easier.
Interesting. I used to program CNCs (lasers and punching machines) for automotive parts. We couldn't rely on the path planner either. If the punching machine's turret ran too close to the clamps, it would crash and put it all out of alignment. There goes a day of production. The planner assumed all material was rigid, but when perforating thin material that wasn't the case. You'd end up with corners bouncing up into the turret that get caught and crumple the sheet metal like paper. The third issue happened when the auto path wanted to change tools multiple times.
It turns out that manually programming paths to account for those issues actually generate hundreds of saved production hours per year.
I'll coin a new term here to classify this kind of problem: NP-incomplete. A problem that's known to be NP-hard, and is actually now impossible because you the program doesn't have all the information it needs to solve the problem.
To properly route a board, the tool would need to know what kinds of loads are at each end of a net, how thick the trace needs to be, where the return path for the current loops involved are, the edge transition times of all signals on the board.
You have to know not to route delicate high-impedance signals next to high dV/dt power traces, how to properly split and combine ground planes, how to respect creepage/clearance requirements for voltage isolated systems, etc.
About the best we can do today is to use autorouting for not-so-critical traces after the work for everything else is done, and even then it only really works well when you have PCB area to spare. In the worst cases, like some 2-layer boards, an autorouter will inappropriately chop up your ground plane with the traces it needs to route and turn what was a good board with solid return paths into a poorly routed mess.
The reason autorouting sort of works in VLSI devices is because all of these requirements are baked into the tools themselves. Every signal has a timing requirement, an impedance requirement, fanout limits, etc. When you are only dealing with digital logic, it makes the job much easier.