There's a moment when you're building a product page or a marketplace listing and you need a social proof stat. Something to put under the logo. "Trusted by X users." "Loved by Y creators." A number, a weight, a reason to take this seriously. If you don't have one, the temptation — or rather, the AI's default — is to invent one.
The number it invented was twelve thousand. "Trusted by 12,000+ creators." It appeared in a mockup I was reviewing, written with the same confident specificity as a real stat. It was entirely fabricated. No survey, no database query, no research. The AI had encountered the shape of a sentence that needed a number and filled it in.
That's the failure mode that concerns me most: not wrong code, which throws an error, but wrong copy, which reads fine and ships.
Here are three times I had to stop and fix it.
1.The feature list for an app that didn't have those features
I was writing a marketplace listing for a small consumer app — the kind of listing that, if it misrepresents functionality, gets the submission rejected outright or, worse, gets through and then lands complaints from every user who installs it expecting something the app doesn't do.
The AI produced a feature list. Three of the items on it didn't exist. Not "exists but isn't polished" — they were config flags set to false, or they were described nowhere in the codebase at all. A walk checklist that wasn't implemented. A third-party integration that was never built. A mode that had been discussed but not shipped.
Each item was plausible. The product was the kind of product that would have those features. The AI knew what a product like this should do, and it wrote what should exist rather than what does exist. That's a reasonable move for a brainstorming session and a catastrophic one for a listing that goes in front of a review board.
The rule I wrote: before writing a single feature claim, read the relevant code or config and confirm the feature is there. Not in the spec — in the running code. Specs drift. Config flags are the truth.
2.The copy that described the wrong system behaviour
I wrote a settings screen for a field service app. The copy said that engineers "auto-sync from bookings" — meaning, in the reading I intended, that engineer details were pulled from booking records automatically.
What the code actually did was more precise and more important: engineer name and email came from the booking, yes, but portal access still required those same engineers to be on an explicit allowlist in the settings. The copy I wrote implied the connection was seamless end-to-end. It wasn't. There was a gate in the middle that the copy made invisible.
A site owner who read that copy carefully, set up their bookings, didn't touch the allowlist, and then couldn't understand why their engineers were getting unauthorised errors — that's not a UX problem. It's a trust problem. The product said one thing and did another.
The fix: before writing any copy that says "the system does X when Y," read the code path end-to-end. Every check, every gate, every condition. Write copy that describes what the code does, not what the feature is called or what you intended it to do. Especially watch for the word "automatically" — it almost always hides a step that isn't automatic.
3.The product page written for the wrong reader
I was building a landing page for a tool aimed at professional agency owners — people who build websites for a living, who have tried dozens of products, who can smell a template from the second paragraph. The AI wrote something with the energy of a SaaS landing page circa 2019. "Free forever." Exclamation marks. "Unlock your potential." The kind of copy a designer looks at once and closes the tab.
The problem wasn't the words exactly — it was that the copy had been written without any real model of who was reading it. Wix Studio partners are designers. They judge visual and editorial quality the same way. They are skeptical of tools by default because they've been burned by tools. They respond to quiet confidence and plain description, not to enthusiasm for its own sake.
There's also a separate issue: a young company writing copy about heritage it doesn't have. "Years of experience." "Long-established." These phrases aren't lies in the way that invented feature lists are lies — they're softer, more aspirational — but they set a reader expectation that the product then has to meet. If you're eighteen months old and you're writing as though you've been doing this for a decade, you will be found out, and you will have written the story that makes being found out hurt most.
The pattern underneath
Three surfaces — a feature list, a settings screen, a landing page — and the same underlying failure: the copy described the intended product rather than the actual one. Features that should exist but don't. Behaviour that was designed but has a gate in the middle. Heritage that's aspirational rather than earned.
AI is extraordinarily good at filling the shape of a sentence. It will produce confident, specific, plausible copy for whatever container you give it. That's useful and it's also dangerous — because specific and plausible and wrong is the hardest kind of wrong to catch.
The practice I run now:
- Feature claims: traced back to the code before writing. Not the spec.
The code.
- Behavioural copy: read the code path end-to-end, every gate, before
writing a sentence that says what the system does.
- Social proof: left empty with an honest placeholder until a real number
exists. No inventory, no testimonials, nothing that was written to fill a shape.
- Audience check: one paragraph before drafting, answering: who is reading
this, what do they value, what makes them skeptical, what tone would a peer use.
The discipline isn't harder than writing the wrong thing and finding out later. It's considerably faster.