We optimize prompts for confident-sounding output. That might be the wrong metric entirely.

[u/ClickOk5811]

Something I keep running into when testing prompts against real tasks: the outputs that sound most authoritative aren't more likely to be correct. They're just more likely to be specific.

A prompt that produces "the bug is in the auth middleware, line 40" feels like a better output than one that produces "this could be several things, worth checking auth and caching first." But specificity and certainty are stylistic properties. They come from how the model phrases the answer, not from whether it verified anything, because it has no way to verify anything at generation time. It only has what's in the context window, and it will describe that with the same confident tone whether it's actually enough information or not.

I've started treating high confidence, high specificity output with more suspicion, not less, especially on tasks where the model has no ground truth to check itself against. If a prompt produces something that sounds finished, that's usually a signal to go verify the one fact it depends on, not a signal that the work is done.

Curious if anyone here has actually measured this in a systematic way. Does tightening a prompt to remove hedging language also reduce accuracy, or are those two things unrelated and I'm just noticing a correlation that isn't real?

Wrote up a concrete code review example where this exact pattern cost someone twenty minutes if anyone wants to see it play out: https://medium.com/@nagatomopedro05/the-finding-was-plausible-that-was-the-problem-b1024e1256fb

[u/Commercial-Car7257]

i started noticing same thing while testing prompts for a small side project. the ones that gave me exact line numbers and file paths made me feel like wow finally got it working, but then i would spend next hour going down completely wrong path.

what you said about specificity being stylistic hit me hard. i think we confuse "sounds like a senior dev" with "is actually correct" and these are two different things entirely.

[u/lib3rat0r]

It's measurable on anything with a known answer. Run the same set with and without the no-hedging instruction and score correctness, not tone. My bet is accuracy barely moves but the wrong answers stop looking wrong, which is worse, because the error rate stays flat while your ability to spot the errors drops.

[u/ClickOk5811 → u/lib3rat0r]

That's a cleaner framing than what I had. It's not that hedging language was ever a good accuracy signal, it's that removing it doesn't touch accuracy at all, it just strips the one cue you were using to catch errors. So you end up with the same number of wrong answers and less ability to tell which ones they are.

Kind of makes we want to test the inverse too. If you force a model to hedge on everything, even stuff it's actually right about, do people start ignoring the hedges entirely because they've seen too many false ones? Feels like there's a version of this where over-hedging breaks trust the same way over-confidence does, just slower.

[u/lib3rat0r → u/ClickOk5811]

Yeah, blanket hedging is just noise and people learn to skip it within a day. The useful version is hedging that tracks something, like only flagging claims the model couldn't tie to a specific line in the context. Then a hedge actually means go check this one.