These things are hard. If you can describe a simple programming task in non-ambiguous language, then that's your program right there.
It might be in pseudocode, but transcribing it into a "real" language is trivial compared to describing the problem in the first place. If it's not, there is probably a programming tool closer to your problem domain that makes it easier.
The biggest business opportunity here is probably helping out with office automation, because not all business minded people can code, not helping professional programmers with boring grunt work.
These sorts of mediation services pop up often, so I understand where you;re coming from. I don't know anything about this one, so I'm talking generally:
I see where you're coming from, but I don't think this service is really trying to solve the (impossible) problem that you lay out. This is more about hiring human labour in an efficient way than it is about making software. From the homepage, I think this is the most interesting example:
Ok, so I can
(1) scrape all the pages;
(2) grab the name, address,
and phone number of every listing; and
(3) put all the listings into a CSV
spreadsheet.
This will be <price redacted>
and take three hours. Is that ok?*
Programming is is a useful skill for this task. For the right person, it's 3 hours work. For the "wrong" person, it could be 3 weeks.
This type of exchange is a kind of economic fundamental. Economies are a long, long way from efficiencies and one of the biggest elements limiting them is what economists term "transaction costs." These are sometimes literal, like paying an attorney to write a contract. More often, it's a general communications difficulty.
Solving those communication problems produces. Programming-oriented-tasks is not necessarily a bad place to explore.
I agree that's the most interesting example, but I also think it falls completely under "office automation". It's not much more complicated to state with lxml (or curl + grep) than it is to state in text if you are fluent with your tools, but it's a bigger hurdle for the average Excel user.
But the example is not terribly useful for a programmer to use in a bigger project, because "put it in a CSV" is too loosely specified for further automation. You would at least need it to be in a specific character set, a specific encoding (html entities or not, BOM or not), specify what to do with invalid entries, the fact that some entries are required and some optional, etc. Even with this simplified example, specifying all these details if what takes time for a programmer, not typing out the code to do it.
Edit: Perhaps I should explain, the reason I'm thinking about this is because I am currently spending a lot of time making these sort of bite sized, well specified, and useful work for a junior developer to get up to speed with. It really is a lot of work.
Really? What about ticketing systems? Certainly when I add a bug or a feature to a ticketing system, it isn't just as difficult as fixing that bug or feature.
The difference being the people working on the ticketing system already have domain knowledge as well as knowledge of the system you are reporting a bug on.
I'm not sure that's the only difference. I'm pretty sure I could walk into many companies and read a ticket and be able to execute without ever having worked on their project before.
It might be in pseudocode, but transcribing it into a "real" language is trivial compared to describing the problem in the first place. If it's not, there is probably a programming tool closer to your problem domain that makes it easier.
The biggest business opportunity here is probably helping out with office automation, because not all business minded people can code, not helping professional programmers with boring grunt work.