Then begin to recognize potentially shit earlier in the process and while you do enough many rounds of that, confirming your expectations, you can just look at the code and say "this is shit" and be quite confident that you're right.
That's not to say that there wouldn't be a similar process working towards recognizing "When to rewrite this shit?" There is and the answer it gives is "Rarely".
A seasoned programmer will balance between "this is shit" and "not rewriting this shit". And there's nothing wrong with shit, because the shit is shipping and mostly works unlike the ultimate refactoring that nobody has time to write.
So it's the programmer's job to fix shit, and occasionally write new stuff that shall be deemed shit by a later fellow colleague.
Instead of pointing at the vague shitty attitudes towards shit, the author should probably just roll up his sleeves and start fixing the shit.