I have seen many senior programmers who think their code is doing X when it is really doing Y. I've seen a very small number of programmers whose code is always doing what they think it is doing. Every member of the latter group of programmers spends considerable energy double-checking themselves.
Therefore if you're taking short-cuts, the possibility that your code is doing something other than what you think it is is realistic, not ludicrous. Now it may be appropriate for you to take those shortcuts. But you shouldn't take them without being honest with yourself about the risk.
But what do you consider a short-cut? How much testing is enough? Doesn't the situation dictate what is enough and what is really a short-cut? What needs to be tested at a startup IS NOT the same as what should be tested inside a large corporation.
And what "risk" are you referring to? As I've stated, I decided to side with "more features" than "100% test coverage". Sure there is "risk" that there are bugs, but a) there are bugs regardless of how much testing you do and b) I've decided I'd lose users because I don't have features that stand out above the competition rather than because a minority of those features have minor bugs. So to me, the bigger risk is not developing more features.
Therefore if you're taking short-cuts, the possibility that your code is doing something other than what you think it is is realistic, not ludicrous. Now it may be appropriate for you to take those shortcuts. But you shouldn't take them without being honest with yourself about the risk.