Why do you assume AI will rely on hardware so extensively and not work in software?
> How would you do a copy of something that is constantly changing?
You pull the plug on the hardware.
> How would you do a copy of something that is constantly changing?
You pull the plug on the hardware.
Of course, it's reasonable to question whether the technique described in the cite could possibly scale to "growing" something like a general AI, or at least whether it could do so in any remotely practicable span of time. But among AI theorists it's a fairly common surmise, and given results already seen for the technique, it's entirely plausible that a general AI grown by such methods would be so intimately bound to the hardware where it "grew up" that, even assuming you could copy it from its "home machine" to another machine of identical configuration, there's no reason to assume the copy would work correctly, or indeed at all.
(And all of this goes to the question of where precisely you draw the line between hardware and software, anyway. Into which category does a given FPGA's configuration of gates fall? Does your answer change depending on whether that configuration has origin in a Verilog file, or in the result of a process of directed evolution? What about the configuration of neurons in your brain on which runs the consciousness that calls itself "I"? I don't pretend to have definitive answers, or indeed any answers, to such questions as these, but they are certainly worth considering in such a discussion as this one.)
Three reasons:
First, hardware is much faster than software. By the time you've built a virtual machine of some sort you're talking about (an) order(s) of magnitude performance loss. We're still speed-limited in how accurately we can emulate the SNES, for example. Sure, there are cases where it is not too bad of a performance loss, but in the case of something like an AI, I would have to assume that a large chunk of the "core" AI would be self-modifying in some form, and self-modifying code just kills most interpreters/JITters.
Second, any sufficiently complex software will have bugs. And in the case of something like an AI, I would have to assume that a large chunk of the "core" AI would be self-modifying in some form, and as such will probably hit upon some undocumented feature/"feature"/bug of the sandbox and start relying on something instance-specific. Machine learning algorithms make great fuzzers. (I know - I've actually had this happen myself. Was working on a fairly simple robot arena machine-learning "demo", and the winning robot exploited a bug in the arena to mess up other robots. (Fairly basic stack-based VM, robots could run X virtual instruction subticks in a game tick. Some instructions took multiple subticks, and there was a bug where starting an instruction [number of subticks in the instruction]-1 subticks from the end of your turn would execute the instruction on your opponent's turn, pushing it onto their stack.)
And third, I don't see how one could build something that doesn't at some point rely on hardware. Virtual machines still leak data via timing attacks. For that matter, what will you do about I/O? How do you know that the AI isn't relying on the noise on the wall in the background of the webcam for some internal subroutine?
> You pull the plug on the hardware.
Which immediately wipes all data in RAM and data encoded in the current processor state / current GPU state / etc. Great idea!