It is dd'ing behind the back of a running Linux system. Anything could happen if the system needs something that isn't in the page cache that happens to be on the bit of disk you just overwrote. While running busybox from a tmpfs removes some of the risk, sshd and other processes on the system are still running from disk; maybe your definition of production ready is happy with that.
Isn't that mitigated by setting the filesystem to read-only? But sure, maybe the solution is to do something like what "takeover.sh" does: https://github.com/marcan/takeover.sh It creates a full running Linux system in RAM and pivots over to that without rebooting. It starts a new SSH server (for the in-memory system) and then you log into the new SSH server to continue your work. Unfortunately takeover.sh is not actively maintained, the open issues suggest it currently is not usable for installing a new system. I am also not entirely sure how to run the OpenBSD installer from such a (Linux kernel based) in-memory rescue environment, without booting into the installer. But, okay. Maybe we can do it better. Anyone know how to duplicate the functionality of "takeover.sh" with OpenBSD? I.e, can we create an in-memory-only OpenBSD system remotely, pivot into it, and then finish the job? This would be useful for many things besides a fresh install, of course -- for example, cloning a disk or doing remote forensics on a potentially compromised server that can't be accessed physically.
