The Myth of Total Automation: Why your users don't want you to automate everything

There’s a widespread belief among product teams that automating is always good. Fewer clicks, less friction, more speed. The user should be grateful. Except in practice, many aren’t. They resist.

The typical reaction is to treat that resistance as ignorance or fear of change. But what if the resistance is rational? What if the user is picking up on something your product team missed?

What the user loses when you automate

Simon Willison, a developer known for his analysis of AI and digital tools, has consistently argued against the idea that automation is always desirable. The core point: automation removes control. And control has value.

When you automate a flow, you’re making a bet. The bet is that the user would rather not think about that step. But “not thinking” comes with an invisible cost: the user also doesn’t see, doesn’t understand, can’t adjust.

Take a simple example: auto-scheduling social media posts. For some users, it’s a godsend. For others, it’s a source of anxiety. They don’t know exactly what’s going out, when, in what context. They’ve lost control over their own communication.

The same applies to automation in CRMs, ERPs, e-commerce platforms. The more the system “decides on its own,” the less the user understands what’s happening. And when something breaks, they don’t even know where to start investigating.

The problem isn’t automation—it’s how automation is designed

The question isn’t whether automation is good or bad. It’s whether it was designed with what the user actually needs in mind.

A lot of automation starts from internal product logic: “this will cut support tickets,” “this will boost engagement metrics,” “this will look more modern.” None of those reasons have anything to do with the value the user perceives.

Product-centric automation

• Reduces support tickets
• Boosts engagement metrics
• Looks innovative
• Removes steps from the flow

User-centric automation

• Solves a problem the user actually named
• Keeps the user in control
• Is transparent about what it does
• Can be turned off or adjusted

The difference between these two columns is subtle, but it determines whether users adopt the automation with enthusiasm or with suspicion.

When automation actually adds real value

There are contexts where automating is clearly the right call. The key is identifying those contexts before you build.

• Is the task repetitive and has the user already expressed wanting to ditch it?
• Does human error at this step have real consequences?
• Can the user understand what the automation did and why?
• Is there an easy way to undo or adjust?
• Does the automation respect the user’s timing and context?

If you’re saying “no” to more than two of these, the automation will probably generate more friction than adoption.

The specific case of AI-powered automation

With the current wave of generative AI, the impulse to automate is stronger than ever. “The AI can just do this” has become a roadmap argument.

But the point that Willison and others have raised is that AI amplifies the opacity problem. When a traditional algorithm automates something, you can at least audit the logic. When generative AI automates, even your product team doesn’t know exactly why it did what it did.

For the user, this is even more uncomfortable. They’ve not only lost control—they’ve lost the ability to understand.

The practical result: AI features that seemed revolutionary in the pitch deck end up getting turned off by users. Or worse, the user abandons the product altogether because they can’t trust what it does anymore.

What this means for builders

The lesson here, as I see it, is about humility. Automation is a tool, not a value in itself.

Before you automate a flow, ask different questions:

1. Did the user ask for this? Not in generic research (“would you like less work?”), but in actual behavior.
2. What does the user lose by not doing this step manually? Sometimes the answer is “nothing.” Sometimes it’s “visibility, control, trust.”
3. How will they know what happened? If the automation runs silently, you’re building a black box.
4. What happens when it breaks? Because it will, at some point. Can the user identify and fix it?

The automation that works is the one the user chooses

The healthiest pattern I’ve observed is opt-in automation, not opt-out.

Instead of automating by default and making the user figure out how to turn it off, offer automation as a clear option. Explain what it does, what it doesn’t do, and how to reverse it.

This seems harder. And it is. But the result is a user who trusts your product because they understand what’s happening. And trust is the hardest asset to rebuild once you lose it.

Closing the loop

The pressure to automate everything comes from multiple places: competition, market trends, the pursuit of internal efficiency. But none of those places is the user.

When you treat user resistance to automation as data instead of an obstacle, patterns emerge. The user wants speed, but they want to understand. They want convenience, but they want control. They want modern, but not surprises.

Automation that works isn’t the kind that does the most. It’s the kind that does what matters, at the right moment, with enough transparency to keep the user trusting.