Most users never open the settings panel. They run your AI product exactly as it arrives, and they judge it on what it does out of the box. Which means the defaults you ship are not a fallback. They are the product for almost everyone.
I've watched teams spend a quarter debating a feature and thirty seconds deciding its default. The debate went into whether the AI could auto-send, auto-apply, auto-categorize. The default — on or off — got picked in the last minute of the meeting, usually toward "on," because on demos better.
That's backwards. The default is the decision. Everything else is an option.
The default is the opinion you actually ship
A settings toggle looks like neutrality. You built both behaviors, you let the user choose, you stayed out of it. But you didn't. You chose the starting point, and the starting point is where the overwhelming majority of users stay.
So a default is a statement. "On by default" says I am confident enough in this behavior to run it on you before you've decided to trust me. "Off by default" says this is powerful enough that you should turn it on deliberately. Both are strong claims. Shipping one without noticing you made a claim is how trust gets spent without anyone deciding to spend it.
The uncomfortable version: your default autonomy level is a bet on your worst output, not your average one. Because the default runs on every user, including the ones who won't notice when it's wrong.
The three questions I ask before setting a default
I don't set an AI default by asking what demos best. I ask three questions in order.
1. What does this action cost if the AI is wrong? Not the average case — the bad case. A wrong auto-categorization costs a re-file. A wrong auto-send costs a relationship. The cost of the worst plausible error sets the ceiling on how much autonomy the default can carry. High-cost, hard-to-reverse actions do not get an "on by default." Ever.
2. Can the user tell it happened? A default that acts silently is far more dangerous than one that acts visibly. If the AI does something by default and the user can't see that it did, they can't catch the error, and they can't build a model of what the system does. Silent defaults erode trust even when they're right, because the user feels the ground moving under them.
3. Is this reversible in one step? Reversibility is what makes an aggressive default safe. If a wrong default costs one click to undo, I'll ship it on. If undoing it means reconstructing state or apologizing to a customer, it ships off, no matter how good the model looks in testing.
Run any AI behavior through those three and the default sets itself. Cheap, visible, reversible: default on. Expensive, silent, or sticky: default off, and earn the "on" through a deliberate user choice.
The staged default
The best defaults aren't fixed. They move as trust is earned.
A new user gets the conservative default — the AI proposes, they approve. As the user accepts the AI's suggestions over and over, the product has evidence that the two are calibrated, and it can offer to promote the default: "You've approved 40 of these in a row. Want me to just handle them?" Now the autonomy is a graduation, not an assumption. The user opted in with full knowledge of what the AI does, because they watched it do the thing forty times first.
This is how I think about defaults at Sunbots and in the Xwits builds. High-stakes actions stay human-in-the-loop by default. The system runs observable and off-switchable. Autonomy is something a user grants after seeing the work, not something the product assumes on their behalf. The default isn't the fastest path to an impressive first run. It's the honest answer to "how much should this AI do before you've told it to?"
Configuration is not a substitute for a decision
The failure mode I watch for most: using a setting to dodge a hard call. When a team can't agree whether the AI should do something automatically, the compromise is often "make it configurable." That feels like maturity. It's usually avoidance.
Every toggle you add is a decision you pushed onto the user — someone who has less context than you, will spend less time on it than you did, and will mostly just keep whatever you set. If the right answer is knowable, ship it as the default and make the toggle the escape hatch. If it genuinely depends on the user, then the setting is real, and it deserves a clear explanation of the trade-off at the moment of choosing, not buried in a panel.
Defaults are the one part of the product every user experiences. Treat them like the decision they are.
FAQ
Should powerful AI features be on or off by default? It depends on the cost of a wrong action, whether the user can see it happened, and whether it's reversible in one step. Cheap, visible, and reversible can default on. Expensive, silent, or hard to undo should default off and be turned on deliberately.
Isn't making things configurable the safest choice? Not usually. Most users never change a setting, so the default is what they get. Adding a toggle often means avoiding a decision rather than making one. Ship the right behavior as the default and use settings for genuine trade-offs, not indecision.
What is a staged default? A default that starts conservative and increases autonomy as the user demonstrates trust — for example, the AI proposes actions until the user has approved enough of them, then offers to handle that action automatically. Autonomy becomes something earned rather than assumed.
Why are silent defaults risky even when the AI is right? Because the user can't see the system acting, they can't catch its mistakes or build an accurate mental model of it. Actions taken invisibly erode confidence over time, even when correct, because the user loses their sense of control.
I'm Ravi Jadav, Chief Product Officer and Co-Founder at Sunbots Innovations and Co-Founder at Xwits Developers. Get in touch.