I am going to think about a problem, and if I come up with a solution I am sure is correct, I shall implement it. If I do not, I will search the web for a solution. If I find one, I will make sure it is correct, and then implement it. If I do not, I am going to ask some friends of mine about it. If they do not know the solution, I will temporaily loose the constraints and implement a solution that is "good enough", then I will make the problem my next research problem.
Implementing an algorithm we are not sure that works correctly is not only a waste of time -- it is actually harmful, for it is possible to ship an algorithm that only seem to work correctly. Test cases will not prove that a solution is correct.
I suspect that in many people's experience, "a solution that I am sure is correct" is anything but, until you've actually tested it. And testing it often takes far less time than puzzling over it and pondering. And so claiming that you never implement anything until you're absolutely certain it's correct smacks of youthful naivete, of the type common to college students who've never implemented anything.
In many of the more interesting fields, it's often not well-defined what it means for an algorithm to be "correct" anyway. What would a "correct" web search algorithm look like? How about a "correct" recommendation algorithm? A "correct" flight fare prediction algorithm? A "correct" stock trading algorithm? A "correct" Starcraft AI? There're "better" and "worse" algorithms for these, but there's no such thing as a "correct" one.
For many problems that do have an obvious "correct" solution (eg. OCR, face recognition, fare optimization), getting there is a nearly intractable problem, and the interesting part is in figuring out how you can approximate it as well as possible with the resources you have available is the best you can do.
You are right in what you say, however I think I have been misunderstood. It is well defined what it means for an algorithm to be correct -- it means that it returns expected output for a given input. Ambiguous situations you are talking about are when the problem is not well defined. That is why I used the word "algorithm" in my first comment. Trial and error is perfectly fine when we are not exactly sure what result we expect, but we will "feel" when it's good enough. It is unacceptable if we know exactly what the result should be, though.
When the problem is well-defined, like word-wrapping, or sorting, or whatever, if you blindly stagger and write code hoping it will work, instead of stopping to think why it should work, you are doing it wrong.
Implementing an algorithm we are not sure that works correctly is not only a waste of time -- it is actually harmful, for it is possible to ship an algorithm that only seem to work correctly. Test cases will not prove that a solution is correct.