Why 'Don't Be Generic' Doesn't Work

Asked for a competitive analysis. Gave it everything. Market position, three-year data, the specific situation. "Be insightful. Don't be generic."

The output was structured, fluent, professional. And interchangeable with what it would have produced for any company in any market. Every recommendation could have been copy-pasted into a competitor's strategy doc without changing a word.

Twenty controlled runs confirmed what was visible, a specificity-by-framing study separate from the receipt-backed 2x2 below. Specific versus vague crossed with positive versus negative framing. Four combinations. Pure negation ("don't be generic," "avoid clichés," "don't use buzzwords") was indistinguishable from giving no instruction at all.

That removes a label without providing a destination. The model left the default and wandered to the adjacent region. Same neighborhood. Different house number. This is the specificity case of that larger pattern: negation names what to avoid, which the default already routes around; only an anchor forces a different path.

Then the other cell in the design. Same negation, but paired: "Don't include recommendations that could apply to any B2B SaaS company. Every recommendation must reference Northvane's specific assets, 5 years of shipping logistics data, 12 engineers, Pacific Northwest enterprise incumbents."

Strong effect, replicated in direction across generators. An earlier comparison looked Claude-leading, but it was confounded by instruction length and is not comparable; a clean 2x2 on xAI, matched on Gemini Flash, shows the effect is not Claude-specific (raw-versus-density magnitudes in the footer). This is the content-specificity lever. Stacking more explicit constraints is a different lever from a different experiment, model-specific rather than cross-generator: large on GPT, reversed on Gemini, uninformative on Claude. Keep the two separate.

The specificity isn't measurably adding analytical quality. It's adding verifiability.

"Don't be generic" blocks one path. The model takes the next most likely path, which is a variation on generic. "Reference these specific assets" creates an anchor the output has to pass through. The result physically cannot be the same for a different company. The constraint tests itself.

Here's the nuance that matters: in blind testing (5 pairs, domain expert, evaluator's own expertise area), the expert couldn't distinguish specific from generic outputs on quality. Picked specific 3 out of 5 times: chance level. Five pairs is too few to prove the conclusions identical; what it shows is no detectable quality difference. The specificity instruction changes what the output LOOKS LIKE (more data references, more grounded claims), not what it SAYS, at least not measurably.

The demonstrated value is verifiability. The specific output can be checked: every claim traces to something nameable. The generic output makes the same points but you can't verify them. When you need to trust the analysis (regulatory, audit, high-stakes decisions), specificity makes the output auditable. When you're using it as a starting point for your own thinking, it doesn't matter.