Good vibes only
We have one rule we enforce harder than any other on the prompts that write your apps: never tell the model what not to do. Write "never import from App.jsx" into a prompt and you have shipped the exact spelling of the mistake into every generation. So we teach the good shape instead, and the good shape wins.
This week we wrote the same rule down for people. It's called good-vibes-only, and it goes like this: every sentence that speaks for the product names the good thing you can do, never the bummer it avoids. A bummer sentence isn't softened. It's inverted.
The one we caught this week
We were writing up a way to introduce Vibes to people who run game nights. The draft said the thing you'd remix a scoreboard for is the house rule your table always argues about. Accurate, probably. Every table has one.
And it's exactly wrong, for the same reason the prompt rule exists. It puts an argument in the reader's head at the moment they're deciding whether to try something. The reason to change the app, in that sentence, is that someone at the table is wrong.
The version that shipped: experiment with new rules, open rifts in the space-time continuum. Same feature. Same scoreboard. The reason to change it is now that changing it is fun. Nobody is wrong. Something might explode, in the good way.
That's the whole rule. The tell, in any draft, is a sentence whose reason to act is that something is wrong, missing, late, or somebody else's fault. Find that sentence and flip it.
Nine more, from our own screens
Every row here is a real string. The first and third shipped months ago, each for its own reason. The rest shipped in the same change as this post: writing it down is what made the bummer column visible, and once a sentence is visible under this rule it does not survive the afternoon.
| Where | Bummer | Dope |
|---|---|---|
| Waiting on a build | "Still sending your prompt, this is taking longer than usual…" | "Still working on it…" |
| A visitor about to leave | "Sign in to save & load your data" | "Sign in and keep what you make, on every device." |
| Un-following someone | "They can no longer see your posts." | "They stop receiving your new posts." |
| Opening a friends-only app | "This vibe is private. Ask them to let you in." | "This one's for their people. Ask to join and they get a note." |
| The button on that screen | "Request access" | "Ask to join" |
| The end of the free grant | "You're out of AI credits — top up to keep going." | "You've built through your credits. Top up and keep going." |
| An app that never got a working build | "This app was never finished" | "Still being made" |
| Who can open a private app | "Only approved members can open this vibe." | "Opens for the people you approve." |
| A chat turn that changed no code | "Nothing in the app changed this time." | "Your app is as it was. This one was a conversation." |
The first one is real and recent. The slow-build line originally shipped with "this is taking longer than usual." Two faults: "longer than usual" tells the reader the wait is abnormal when nothing is breaking, and "sending your prompt" leaks our plumbing at the moment they're least sure anything works. The replacement is one calm, present-tense sentence about the work, and it covers every kind of wait because the reader's situation is the same in all of them.
Get posts like this in your inbox
One email field. Real updates. No algorithm required.
The third is a rule we'd already written for a different reason. Vibes is local-first: when you stop sharing with someone, their phone keeps the copy it already has. So "they can no longer see" would be a lie. "They stop receiving" is true, and it turned out to also be kinder. Honest copy and inviting copy point the same way more often than you'd think.
The second and the sixth are also decisions about what the product does, not just what it says. "Keep what you make" only works because an anonymous visitor's work really is saved on their device and really does travel with them when they sign in. A gate dressed up as an invitation is still a gate. And "you've built through your credits" is only fair because the number it refers to is the one you spent, not one we hid.
Why it works, and why it's not magic
The Nielsen Norman Group's error-message guidelines put it plainly: "Don't use phrasing that blames users or implies they are doing something wrong, such as invalid, illegal, or incorrect," and "the proper usage of any system lies with its creators and not with the system's users." Their example is a shipping threshold framed as what to add to the cart rather than what you failed to spend. Same inversion.
The behavioral literature is more modest than the marketing blogs suggest, and it's worth being honest about that. The classic meta-analysis of gain-framed versus loss-framed messages found a real but small-to-medium effect, and follow-up work shows it depends on the behavior and the person. A test across three newsrooms and 222,385 readers varied gain and loss frames on subscription appeals and found the frame mattered less than people expected. So we don't claim a conversion lift from a verb.
The claim is about attention. A next-token predictor continues whatever is most present in its context, and so, roughly, do you. Fill the context with a vivid picture of the thing done right and that's what gets reached for. Fill it with the mistake, the loss, the argument, and that's what's in the room. The prompt rule and the copy rule are one rule: attention is the steering wheel.
Where the "don't" goes
This doesn't mean the product runs on vibes and hope. The things that must hold always, who can read what, what a rejected write does, how a wait ends, are enforced in code, where a rule is a rail rather than a request. That's the same split the prompt rule makes: the runtime owns the invariants, and the words own the taste.
What it does mean is that every sentence gets one more pass before it ships. Read it as someone who's deciding whether to try. If the reason they'd act is that something's wrong, rewrite it so the reason is that something's possible.
Try a rule nobody has played by yet
Describe the app you want. Then change it, just to see what happens.
Start building →