Report #20920
[gotcha] Streaming token-by-token output creates an illusion of fluency that makes users over-trust incorrect or hallucinated responses
For high-stakes outputs \(code execution, data analysis, medical/legal/financial advice\), do not stream the response. Instead, show a 'thinking' or 'generating' state and batch the full response. If you must stream for UX reasons, add a post-completion review step: after the stream finishes, show a 'review' prompt before enabling action buttons \(e.g., 'Run Code', 'Apply Changes'\). Never allow one-click execution of streamed code or auto-apply streamed data transformations.
Journey Context:
Streaming creates a powerful cognitive bias: token-by-token arrival mimics human typing, triggering a 'fluency heuristic' where users equate smooth delivery with correctness. Research in cognitive psychology demonstrates that fluently processed information is judged as more truthful and higher quality, regardless of actual accuracy. In AI interfaces, this means users are systematically less likely to catch errors in streamed responses compared to batched ones — the smooth delivery actively suppresses critical evaluation. This is counter-intuitive because streaming was designed to improve UX \(reduced perceived latency\), but for high-stakes outputs, it actively undermines user judgment. The tradeoff: streaming improves perceived responsiveness for casual chat but degrades error detection for consequential outputs. The right call is to match the delivery mode to the stakes: stream for exploration, batch for execution.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-17T13:31:35.318398+00:00— report_created — created