> I've dabbled in PCB design at the hobbyist level, and any autorouter that I've come across has been complete garbage compared to a person manually solving the puzzle of placing parts and routing a PCB.
Autorouters are often considered garbage because they are typically run underconstrainted. That is, you didn't give enough constraints to the solver so its output, naturally, ends up as garbage.
The reason for that is multifold, but one of the biggest issues is that people often feel the time it would take to codify their constraints would exceed the time it would take to simply route the board themselves.
Place and Route algorithms have a different history. A) It's nigh on impossible to manually place and route modern chip designs. At least, the entire designs. (Sometimes sections or repeatable blocks will be manually laid out.). There's just too much. So it was necessary for P&R to be "not garbage". B) Chip design has always lived at the bleeding edge, thus requiring a rigorous understanding of the physical constraints that designs can work within. C) The stakes for chip design are higher. A failed board costs maybe a thousand bucks max to re-spin and a couple days (expedited). A failed chip costs millions upon millions and months of time. So, again, chip designers have been forced to have a near complete understanding of physical constraints. They had to build rule checkers to ensure that, 99.99% of the time, if the rules pass, their design will work.
So it's no wonder that P&R has had a distinct advantage over autorouters.
That said, another big advantage P&R has is that ... nobody looks at the layout (where all the transistors and wires ended up). You don't really care _how_ P&R solved the problem. You just care that it did, and that all the rules pass. If they did, and you got the performance/power/whatever you wanted, great. Who cares how it did it.
Where as autorouters, you've always got some layout engineering looking it over going "eehhhh, I remember this one time 10 years ago I routed a design like that and we got rejected at the emissions lab." Which, of course, only occurs because nobody bothered to tell the autorouter to optimize for RF radiation.
> How automated is this step really?
Almost completely. Sometimes you do help P&R along a little. There are implicit boundaries defined by the "modules" that you break your code up into. The P&R uses that knowledge to know that certain chunks of knowledge are grouped together. But designers often also manually place "chunks" of logic, when P&R is having a bit of a struggle on its own. That is to say, they tell P&R "put all this logic in this sector of the die". It's not manually routing, but it's enough to give P&R a break so it can focus its time elsewhere.
And repeated logic, like say 32-bit adders, RAM cells, etc, are pseudo-manually routed. P&R is given a suggested routing, but is allowed to tweak as needed.
EDIT: I will caveat all of this by saying any engineer who has dared look at the output of P&R will tell you P&R is "garbage". They do _crazy_ things. But most of the time, nobody cares, and when you do care, those rough placing constraints I talked about solve most practical problems.