The Autorouter Broke Your Trust. Here’s What’s Actually Different Now.
Every PCB engineer with 20+ years of experience has a horror story about autorouters. The traces that looked fine in the preview but created ground loops that took weeks to debug. The “optimized” routing that ignored every impedance constraint you’d carefully specified. The tool that promised to save hours but cost days in rework.
They’re right to be skeptical. But they’re also missing something.
Actually, the resistance to AI-assisted PCB design isn’t stubbornness or technophobia. It’s pattern recognition: the same skill that makes a senior engineer valuable in the first place. When you’ve watched three generations of “revolutionary” autorouting tools fail to deliver on their promises, skepticism isn’t irrational. It’s earned.
But earned skepticism can become a trap when the underlying technology changes. And to understand why reinforcement learning represents a genuine transformation compared to traditional autorouters, we need to first understand precisely why those autorouters failed.
The Fundamental Problem with Heuristics
Traditional autorouters work on heuristics: predefined rules that attempt to encode good routing practices. Keep traces a certain distance apart. Minimize via count. Prefer certain layer transitions. Route power and ground first. These rules sound reasonable because they are reasonable. They represent decades of accumulated engineering wisdom.
The problem isn’t the individual rules: it is what happens when they interact.
Consider a moderately complex board: a six-layer stack-up with mixed-signal design, DDR4 memory interface, and a switching power supply. Your routing constraints aren’t just numerous. They’re in constant tension with each other. The DDR4 length matching requirements conflict with the need to keep high-speed traces away from the switching regulator. Your impedance targets for differential pairs conflict with the available space after you’ve established proper clearances from the power plane splits. The DFM requirements for via-in-pad conflict with the thermal relief patterns your manufacturer recommends.
A heuristic-based system handles this through priority weighting. Rule A gets priority 1, Rule B gets priority 2, and so on down the list. When rules conflict, the higher priority wins. This sounds systematic until you realize that the optimal priority ordering changes constantly. Not just from board to board, but from region to region within the same board. Near the BGA breakout, via count reduction might matter most. Near the board edge, manufacturability constraints dominate. In the analog section, isolation from digital noise trumps everything else.
No static priority ordering can capture this contextual complexity. And so the autorouter makes locally reasonable decisions that produce globally suboptimal results. The routing is technically DRC-clean but functionally compromised. You spend hours cleaning up what was supposed to save you time.
This isn’t a failure of implementation. It’s a fundamental limitation of the approach. Heuristic systems are expert systems, and expert systems fail when expertise requires weighing thousands of interacting factors simultaneously.
Why Adding More Rules Made It Worse
The natural response to heuristic failures is to add more heuristics. Vendors piled on features: constraint regions, net classes, length-matching wizards, differential pair routing modes. Each addition addressed a specific complaint. Each addition also increased the combinatorial complexity of the rule interactions.
This means that you can spend nearly as much time configuring the autorouter constraints as you would have spent routing manually. The tools can become so feature-rich, that using them effectively requires understanding the internal decision-making process in detail. This defeated the purpose of automation. You end up debugging the autorouter’s interpretation of your rules instead of just routing the board.
This is the expert system paradox. As you add rules to handle edge cases, you create new edge cases from rule interactions. The system becomes more capable on paper but less predictable in practice. Engineers lose trust because they can’t predict when the tool will help versus when it will create new problems.
The honest autorouter vendors eventually acknowledged this. They started positioning their tools as “interactive” routing assistants rather than push-button solutions. Use the autorouter for the easy sections. Do the critical routing manually. This was reasonable advice, but it was also an admission that the core technology had hit its ceiling.
What Reinforcement Learning Actually Does Differently
Reinforcement learning (RL) doesn’t start with rules. It starts with goals and feedback.
The distinction matters more than it might initially seem. In an RL system, you specify what you want to achieve, for instance minimize signal integrity violations, meet length matching requirements, satisfy DFM constraints, reduce via count. The system then learns through millions of trial iterations which actions lead to those outcomes. The learning process discovers strategies, rather than having strategies prescribed.
This is closer to how human experts actually develop expertise. A senior layout engineer doesn’t route boards by consciously applying a checklist of rules. They’ve developed intuition through years of feedback, seeing which decisions led to first-pass manufacturing success and which led to phone calls from the fab about yield problems. They’ve internalized patterns that they might struggle to articulate explicitly.
RL systems learn similar patterns, but from a compressed experience base. Google’s 2021 Nature paper on chip placement demonstrated that their RL system, trained on thousands of placement scenarios, developed strategies that human experts found novel but valid upon examination. The system wasn’t just mimicking human approaches faster, it was also discovering approaches humans hadn’t considered.
The same principle applies to PCB routing. An RL system trained on diverse board topologies learns to balance constraints not through static priority weights but through learned value functions that adapt to local context. Near a BGA breakout, it recognizes the pattern and applies strategies it learned were effective for BGA breakouts. Near analog sections, it shifts approaches based on what worked for analog isolation in training.
Critically, this isn’t magic. The system can only learn from the feedback it receives. If your training process doesn’t include signal integrity simulation, the system won’t learn to optimize for signal integrity. If your training boards don’t include RF sections, the system won’t develop RF routing intuition. The quality of RL output is bounded by the quality and diversity of the training process.
The Honest Limitations
The above doesn’t mean that the problem is solved, and here are the limitations; because overselling is exactly what destroyed trust in the previous generation of tools.
RL systems are fundamentally interpolation engines. They perform well on problems that resemble their training distribution and degrade on problems that don’t. If you’re designing a board with a topology or constraint set that’s genuinely novel, as regularly seen in cutting-edge work, an RL system will fall back on its nearest learned approximations. Sometimes those approximations are good enough. Sometimes they’re not.
The systems also can’t explain their reasoning in the way a human expert can. When an experienced layout engineer makes an unusual routing decision, you can ask why and get an answer that references specific signal integrity concerns or manufacturing experience. An RL system can tell you that it learned this approach produced good outcomes, but it can’t articulate the underlying principle. For verification and debugging, this opacity is a genuine limitation.
Manufacturing variation presents another boundary. RL systems learn from idealized models of how boards behave. Real manufacturing involves process variation, material property tolerances, and fabrication house-specific quirks that affect what’s actually buildable. A system trained on textbook stack-up assumptions might produce routes that work in simulation but cause problems with your specific fab’s actual capabilities.
Perhaps most importantly, RL systems can’t handle requirements that weren’t in the training objective. If you have an unusual constraint, for example thermal considerations that aren’t captured in standard models, EMI requirements for certification you haven’t achieved before, or even mechanical stress concerns from board flex, the system has no way to account for factors it wasn’t trained to optimize.
These limitations aren’t temporary. They’re inherent to the approach. Acknowledging them is the prerequisite for using the technology effectively.
The 80/20 Reality
What really creates value is not helping with complex problems, but eliminating repetitive and tedious work, because we can see that’s where you, engineers, spend most of your time.
The DDR4 interface on your board might require genuine expertise to route correctly. But the GPIO breakout to the debug connector doesn’t. The power supply filter section might need careful attention to current flow and thermal relief. But the status LED routing is just busywork.
Senior engineers spend significant portions of their layout time on tasks that don’t benefit from their hard-won expertise.
This is where RL-based tools like DeepPCB change the economics. Not by replacing expert judgment on critical sections, but by handling the routine work that doesn’t require expert judgment. The system routes the straightforward sections while the engineer focuses on the parts where experience and intuition actually matter.
The result isn’t faster boards because the AI routes faster than humans (though it does). The result is faster boards because engineers spend their time on high-value problems instead of tedious ones. The 80% of a board that’s electrically straightforward gets handled automatically. The 20% that requires genuine expertise gets full human attention. ¹²³
This is a different value proposition than autorouters promised. Autorouters promised to replace the layout process. RL-based tools are better understood as augmenting engineer capability; handling the routine work so humans can focus on the interesting problems.
What Changes Practically
If you’ve been burned by autorouters before, the practical question is what you should do differently with RL-based tools.
First, adjust your verification approach. Traditional autorouters often produced DRC-clean routes that failed functionally. RL systems trained on signal integrity objectives produce routes optimized for electrical performance, but you should still verify that performance through simulation. The AI’s training objective and your actual requirements might not perfectly align.
Second, expect iteration. RL systems learn from feedback, and the commercial tools increasingly support providing feedback that improves results on your specific design patterns. The first board you run through the system might require more cleanup than the tenth. This is different from traditional autorouters, where the hundredth board wasn’t notably better than the first.
Third, understand the training distribution. Ask vendors what board types, stack-up configurations, and constraint categories their system was trained on. A system trained primarily on consumer electronics might not perform well on aerospace designs, and vice versa. The more your work resembles the training set, the better results you’ll get.
Fourth, maintain your expertise. RL systems are tools, not replacements. The engineers who get the most value from them are the ones who understand the underlying principles well enough to recognize when the AI’s output needs adjustment. Delegating layout to AI while atrophying your own layout skills is a trap.
The Bigger Picture
The history of automation in engineering is a history of overpromise and eventual delivery. CAD systems were going to replace drafting, and eventually they did, but it took decades longer than vendors predicted and happened differently than anyone expected.
Simulation was going to eliminate physical prototyping, and eventually it reduced physical prototyping dramatically, but it required far more sophisticated tools and expertise than early advocates anticipated.
AI in PCB design is on a similar trajectory. The autorouter generation overpromised and underdelivered. The current generation of RL-based tools is more technically capable, but it’s still early in the adoption curve. The engineers who benefit most will be the ones who engage with the technology critically, understanding both its genuine capabilities and its real limitations.
Your skepticism served you well with autorouters. Now it can serve you differently: not as a reason to dismiss new approaches entirely, but as the foundation for evaluating them rigorously. The question isn’t whether AI will eventually handle most routine PCB layout work. The trajectory of every adjacent field suggests it will. The question is whether the current tools have crossed the threshold from “interesting research” to “practical utility.” The answer is increasingly yes, but the only way to know for certain is to test that proposition against your own designs, your own constraints, and your own judgment.
That judgment is exactly what decades of experience developed. The new tools don’t replace it. They’re finally good enough to deserve it.
¹ https://www.eng-tips.com/threads/pcb-auto-routing-software-cadence-allegro-specctra.188518 -> ~90% completion with the autorouter, then spending “several weeks tearing up and rerouting tracks to get to 100%”
² https://resources.altium.com/p/to-autoroute-or-not-to-autoroute-a-history-of-failed-design-automation
³ https://www.bigmessowires.com/2019/03/27/pcb-autorouting
