If you're trying to replace the software developers that take fully-fleshed-out work items (including a complete pseudocode description of business logic, edge

If you're trying to replace the software developers that take fully-fleshed-out work items (including a complete pseudocode description of business logic, edge cases, failure modes, acceptable data ranges...), then you might have some success. But then you've only managed to replace the lowliest of developers. Even in my experience as an enterprise developer, I've yet to come across anyone that didn't bring some amount of independent thought to the process. And, due to the nature of our work, almost all of us learn to question assumptions, hone definitions of behavior, ponder possible failure scenarios, and just in general ask the "what if?" questions that will bite us if left undiscovered. Our ability to translate that into a standard machine-readable language is really a small fraction of the value we contribute. Yes, it is a barrier to entry—and it's seen as akin to voodoo by some non-technical types—but replacing it with something with a "friendlier" interface doesn't shrink the problem domain in the slightest.