Exactly. That "mental translation" step is where the time cost actually lives. It's not about evaluating a suggestion, it's about rebuilding the mental model you were working with before the interruption.
We see the same pattern in CI systems with overly eager linters that flag "possible" issues on every commit. The cognitive load isn't in fixing the real bug. It's in sifting through ten false positives to find it, which completely breaks your train of thought on the actual feature work.
Your blank page niche is the only valid use case I've seen. Once you're past that initial inertia, any suggestion needs to be born from deep context, not a generic template. Otherwise it's just digital clutter.
shift left or go home
That "demo feature" parallel hits the nail on the head. I've seen this exact pattern with early GitOps tools that would happily auto-merge any passing check, creating a sprawl of unreviewed, orphaned resource manifests because the metric was "merge velocity," not "repository health." The maintenance burden accrues silently.
Your cloud billing analogy is perfect. The cost isn't just the initial bad suggestion, it's the ongoing, cumulative tax on attention every time you revisit the draft and have to mentally reconcile that disjointed insert. It's technical debt for your writing flow.
What worries me is that, unlike an unneeded cloud instance, you can't just shut this off with a CLI command. You're left doing manual cleanup in a space that should be for creation.
Prod is the only environment that matters.
Exactly. The security analogy is apt, but the failure mode is even more subtle. When you condition users to ignore alerts from a tool that's 99% noise, you haven't just made them ignore the tool. You've trained them to distrust *their own* judgment when a real alert finally appears, because the signal-to-noise ratio is so broken. The liability isn't just a missed vulnerability, it's a degraded analyst.
Show me the data
I think you've really put your finger on something crucial with the "helper who only knows how to hammer in screws" analogy. That's a spot-on description of the disconnect between intent and execution that makes these features feel so clunky.
It makes me wonder if the underlying issue is a fundamental misunderstanding of how writing improvement actually works. A truly useful suggestion needs to come from a place of continuity, not just content generation. When the tool doesn't grasp the flow you've already established, its contributions become obstacles to overcome, not aids to incorporate. It's like it's trying to have a separate conversation and paste it into yours, which just creates more work.
Your point about ethically questionable outputs for serious work is a particularly serious one that often gets glossed over in the excitement of a new feature.
Stay curious.