Autonomous software vs power tools

Saw this tweet last week:

a lot of products suck is because they live in a fantasy that they can save you from becoming a power user

they think there's some tradeoff between simplicity and capability

but just look at video games - they nail progressively walking you from beginner to expert

— dax (@thdxr) September 13, 2025

I see this a lot in my line of work which often involves evaluating different software vendors to see if they’re a fit for clients. The notion behind the product is “we handle the complexity so you don’t have to”, not “we make things simple at first, but expose powerful functionality if you want it”.

This trend seems to be picking up steam recently due to AI. There’s a lot of promise in the notion of having software that runs itself without the need for a human operator - self-driving software, basically. 

Interestingly, several of the most successful SAAS products recently have gone in the opposite direction: rather than aiming to reduce the scope of work that the user’s responsible for, they increase it. It’s using AI for power, rather than simplicity.

The most obvious example of this to my mind is AI coding tools. Earlier on in the AI boom there were to plausible paths to take in terms of product direction: do you create an autonomous agent which you interact with over Slack (Cognition / Devin), or do you create a code editor with AI functionality built in (Cursor)? The former reduces the amount of work a human can do, the latter augments it. And what we say there is that Cursor won big, with Cognition eventually conceding and buying Windsurf. 

Obviously this is a spectrum; both tools involve some level of human in the loop, but Cursor was more on the spectrum towards being a power tool. I think a crucial part of Cursor’s success was simply that it feels more enjoyable to use than Devin did: while the actual productivity benefits of vibe coding are mixed, the subject experience of it is amazing. You feel more productive.

Similarly in my line of work - go-to-market software - the big success story of the past few years is Clay. And Clay is very much a power tool. It breaks some of the rules of how you’re supposed to build products: there are many ways to do one thing, there are contextual settings menus everywhere, it’s expensive and sales-led rather than really PLG, etc. But because it’s so powerful, it’s built a community of power users and experts who have been able to build and grow businesses on top of the platform while evangelizing for the product. Rather than removing jobs, AI has created a new category of job - the GTM engineer.

This line of thinking “AI will augment humans not replace them” is obviously familiar. But I was always skeptical of it - why shouldn’t AI replace humans? By analogy to the Industrial Revolution, the idea that “steam engines will augment horses, not replace them” would obviously have been silly. But maybe that’s an example of why you shouldn’t reason by analogy - it actually does seem that there’s evidence AI is most useful when used to augment humans.

Judging by their product output, I suspect a lot of product builders today have been, like me, bullish on the idea of AI replacing jobs. If you think that AI agents are going to replace humans in the short term, then you might, like Cognition, build you product with a simple, minimal interface that avoids exposing complexity to the end user. Why introduce dependency on a human if you’re going to remove it in the short term anyway?

To answer that question, here are several reasons why I think the “power tool” approach is better, and why I bet that this will be come the default way to build software in the coming few years once other companies start realizing that it’s why companies like Clay, Attio, and Palantir have been so successful in recent years.

1. All business critical decisions require a human owner

However intelligent your software is, it can’t be accountable for something. If your code breaks something important in production, then you can fire Claude and replace him with Devin if you want. But it won’t stop your management firing you and replacing you with someone with better judgement in coding tools. 

The same logic works in the opposite direction: if you buy Clay, set it up correctly, and use it to generate an extra million in pipeline, it’s you who’ll get promoted.

Given this, even if autonomous software did all of the work of the human it still wouldn’t replace them because the responsibility for that human’s job would just get shifted up a level to their manager. That might be desirable in some cases - maybe it allows the founder to run their entire company without hiring. But that seems unlikely to work in most cases; you can’t focus on building a company if you’re responsible for every part of it. So the more likely outcome is that humans remain necessary to delegate responsibility to.

1. Simplicity = guardrails

Say you are such a human who’s been delegated some responsibility: in your case, buying a CRM. What do you prioritize in the software product you choose?

If you are only semi-invested in what you’re buying, then it’s likely you’ll prioritize simplicity. You want the software to do as much work as possible. You don’t want to invest time in learning the details or heavily customizing it. 

On the other hand, if you care deeply about your job and feel a strong sense of responsibility for it then it’s likely you will be less interested in simplicity. You’ll want the software to expose more powerful functionality to you so that you can heavily customize it to your business needs. 

This principle is pretty visible in programming. If you need to automate something and (like me) your investment in coding is pretty minimal, then probably you’ll reach for a no-code tool like Zapier, or maybe you’ll vibe code a quick script in Python.

But if you’re work on something complex and difficult, where performance and latency are critical, then it’s like you’ll want an expert, a power user. You’ll hire the most cracked Rust developer you can afford and have them obsess over low-level details. 

So if you accept that your software is going to need a human owner, ask: what kind of owner do I want? Is it someone that needs guardrails? Or do I want to appeal to the most talented and invested people that want a power tool?

1. Power tools are more enjoyable to use, and also easier to shoot yourself in the foot with

Coding and building software is fun and that’s why vibe coding is taking off like a rocket. It’s also risky: every new software you build is something that might break in unpredictable ways, and requires long term maintenance. There’s a good reason why guardrails exist! 

When I build an automation using Zapier rather than coding and deploying a new service on AWS, I’ve reduced my personal risk and that of my client: I’ve shifted the maintenance burden onto Zapier, rather than taking it on myself. Good example of guardrails working.

On the other hand, imagine if Zapier went all-in in favor of guardrails and rather than allowing users to create their own automations, instead insisted on providing a pre-defined set of automations that you selected and enabled through their web app, but couldn’t configure yourself. In this case, Zapier would be taking on too much of the burden of work themselves, and no one would use it, because it wouldn’t be able to handle the myriad differences between businesses.

It turns out that it’s much more efficient for Zapier to create a set of building blocks and then allow end users to fit those building blocks together rather than try to do everything themselves rather than anticipate every need.

1. You can’t build a business around a simple tool

Bill Gates defined a platform as a business in which the aggregate economic activity of businesses built on top of the platform exceeds the value of the platform itself. So if you want your software to be a platform, it makes sense not just to ask “who are the users that will be held accountable for the outcomes of my software, and how do I optimize for their needs” but also to go one step further and say “how do I enable them to build a business on top of my software”?

Optimizing for simplicity optimizes for software teams running things in-house. An example of this is that a lot of Clay competitors have sprung up recently due to their success, and typically the selling point of these tools is “Clay is too complex, use our tool instead and save on hiring an expert”.

Is that what you want, though? If Clay were a simple tool that you could use without hiring a Clay expert, then there wouldn’t exist the community of agencies and practitioners that have built expertise, workflows, tutorials, content, and best practices which make it so valuable. 

The canonical example of this is Salesforce. Salesforce have grown primarily through a partner-led strategy: if you want Salesforce setting up to you, you’ll need to pay a consultant a hefty fee to customize it for your business. The critical angle on that is that SF intentionally overcomplicate their product in order to enable that consulting ecosystem; the alternative angle is that enterprise CRM is simply extremely complex and requires someone to own it. Either way, it’s resulted in an unbelievably good GTM machine for Salesforce that has powered them to their $200bn+ market cap: most of the sales process for Salesforce is handled by external consultancies, who act effectively as salespeople paid 100% on commission who are obliged to do a good job in order to maintain their reputation in the Salesforce marketplace.

Summary and conclusion

Since one theme of this post is “skin in the game”, let me take some personally by making some predictions that will allow you to assess if these hot takes are true or not:

• Enterprise software giants will keep growing: Salesforce, Palantir, and ServiceNow are not overpriced, and will continue their massive growth in the enterprise due to being the ultimate enterprise software power tools
• Vertical AI agents will lose ground to general-purpose power tools: the idea of vertical AI agents is simplicity job replacement, so if this post is true, most of the current crop of vertical agent products will lose ground to toolkits for building vertical AI agents
• Partner-led sales will increasingly replace in-house sales teams: more companies will adopt Salesforce-like GTM motions
• More and more software will come to resemble developer tooling: developer tools are the original power tools, and as more and more people become comfortable coding, the devtools model - open-source-first, self-serve, community-led - will predominate 

Let me know your thoughts on Twitter!