Cars no, rockets yes. Modern pilotless systems employ very different physics models to reach their destination and the physics models get refined with more testing (usage). Modern missiles can adapt to different altitudes, environments (temperature, humidity) and factor into their mission execution meteorological parameters too...
You're both talking very much about software. When Rodéric used cars and rockets as examples, I understood him to mean as examples of physical engineering where physical testing produces bug-free products, ergo correct testing of software can produce bug-free products in the same vein. I've just Googled how many parts a car is made out of and Toyota says 30,000. 30,000 lines of code is nothing, and that 30,000 lines of code could well be dependent on thousands/millions of lines of library code you don't have control over, and countless lines of OS code you have no control over, and potentially the many interactions between those parts of code in parallel. I recall a Naughty Dog bug on PS1 where the memory card was wiped by save games thanks to a controller timing issue or somesuch. The level of bizarreness in outcome doesn't happen in other fields AFAIK, save maybe the most esoteric of quantum sciences.I work in automotive engineering, and in fact part of my work is QA (well, I do testspec and testimplementation). And I can tell you... there is more than you'd like. In a networked car (modern car, that is), you'll have 50+ ECUs communicating with each other at all times...
I dare say 30,000 lines of bug-free code is doable on the simplest of processors if you're not trying to do anything too adventurous. If you start doing really funky things to extract performance or capacity from very limited components such as self-modifying code and poke/peeking to memory addresses, even only 30,000 lines of code could be extremely to keep 100% bug free.
Of course, Rodéric is more saying that where a car is 30,000 components, each component is a self-contained unit made and tested to spec, each functional piece of code can and should be constructed similarly, so the final software is an assemblage of working parts that can be trusted to work because each part does. But I'm not convinced game development can be economical produced in such fashion.