The vibe coded part of my product wasn't the code, it was the error messages
by•
I let the model write every empty state and failure string in my app because it was fast and the copy read fine.
Then a generation path started failing and the message it showed was calm, vague and reassuring. Nobody reported it. I found it in the logs, not in support, and by then it had been broken for over a week. The writing was good enough to hide a real bug.
So the rule I'd give anyone shipping fast: let the model write your happy path copy, write your failure copy yourself. Error text is the one place in a product where sounding confident and pleasant actively works against you. You want it specific and a bit alarming, because you need the user to tell you.
Has anyone else had the generated part be too polished to notice it was wrong?
12 views
Replies
Let me make this one step earlier: failure copy shouldn't decide whether a generation succeeded. The server should classify the result first. In a flashcard tool I build, a null or even empty response triggers an automatic credit refund. A save failure does too. The message only explains what the system already decided.
But I still write failure copy by hand, I don't rely on it to make users report the bug. If a phrase can mask a faulty path for a week, then the cause of the failure lies in the code and the logs.
@siarheihamanovich Agreed on the ordering, the server decides and the copy only reports. Where it bit us is that the server thought it had succeeded. Valid file, non-zero bytes, 200 back, and the content was wrong in a way no assertion I'd written could see. So success needs a definition beyond it returned something, and that's the part I keep underestimating.