But software doesn't exist alone. No piece of software operates in a purely static isolated world.
Human requirements change. Technological requirements change. The software you wrote on Windows maybe now has to support Linux. So the software you speak of is an abstraction which has very little real-world meaning.
With bounded responsibilities, the team which built the software is likely to have the responsibility of maintaining it after release.
The brutal fact of the matter is that we are all in the business of constructing software mechanisms which will be executed by a silicon chip smaller than our pinky fingernail ... and beyond our direct control.
But there is no difference in kind to building a hammer. Suppose I make and sell hammers. That will be used for things outside my direct control. In fact, the team that designs and builds these will have *less* control than the software developer has. The control issue is not specific to automation.
Also I am not entirely sure that automation should remove the human from the process. There is a lot of research going on right now in things like avionics about how to bring humans back into the process more. And in areas where I work (including financial software), humans need to be in control. So the automation there ends up being less like a robot (something that fully automates tasks) and more like a hammer (something we use to enhance our own working capabilities).