A librarian wrote a guide to turning off intrusive AI features. It made the front page this week, and it is the most useful product feedback I have read in a while — mostly because it was never addressed to product teams.
It is not an anti-AI piece. Nobody in it argues that machine assistance is worthless. They are describing, patiently and in order, how to make software stop interrupting them.
Which is a different complaint entirely, and a much more damning one.
Assistive, or intrusive
The line people are drawing is not between AI and no AI. It is between a tool that waits to be asked and one that inserts itself.
The same summarisation feature is welcome behind a button and resented when it rewrites the top of a page you were already reading. Nothing about the model changed between those two cases. What changed is who started it.
That distinction is invisible in a feature spec and obvious to anyone using the thing.
It also has a precise cost in our world. If a hint arrives before a learner has formed an attempt, it replaces the retrieval the exercise existed to produce. They read a correct answer, feel the pleasant click of recognition, and remember nothing — because recognition is not retrieval.
Offer the same hint thirty seconds later, on request, after a real attempt, and it lands on a mind that has committed to something. The correction sticks. Same sentence, same model, opposite outcome. The timing is not a detail; the timing is the intervention.
The number that flatters you
Here is where it gets uncomfortable for whoever owns the roadmap.
It is easy to report high adoption of something on by default and awkward to turn off. That number measures your defaults, not your product.
The number that would actually tell you something is how many people would switch it on themselves. Almost nobody instruments for that, because the answer is usually worse and nobody asks for a metric that makes them look bad.
And if a meaningful share of your users go hunting for instructions to disable a feature, that is also a usage signal. Just not one that goes in the deck.
So: ship the capability, and let the person ask for it. Make the first invocation cheap and obvious, make the second one automatic if they want it, and never make the third one mandatory. Then measure what you are actually claiming — not that the feature ran, but that somebody chose it and came back.
The guide is here. It is worth asking, before you read it: if someone wrote one of these about your product, which feature would be at the top?
One email when we publish. Research, product decisions, and what teams report back.