The case for wasteful agents
Why trying everything is the new efficiency
In last week’s post, we talked about how Cursor had created an unfair UX advantage for itself by scoping the incremental unit of work to something users could easily accept or reject. The best UX for agents is one where you do small bits of work, get feedback, and iterate quickly. The agent in this loop can do the hands-on work, so the user can focus on the bigger picture and orchestration. As this vision increasingly becomes reality with Cursor, Cowork, and maybe OpenClaw, we’ve realized that this unlocks an abundance mindset about what you do: Try lots of things and throw many of them away.
This isn’t a totally net-new observation. Since the release of Claude Code and its subsequent jumps in capability last fall, there has been a consistent drumbeat on Twitter and Substack about how the cost of building new tools has effectively hit zero. This trend has only accelerated as non-engineering teams have adopted Claude Code and more recently with the release of Cowork. That doesn’t mean everything you try is going to be perfect (more on this later), but it does mean that the cost of trying something (or many things!) has dropped dramatically. The implications are far-reaching.
This pattern has repeated many times in history. Before the introduction of the modern software spreadsheet, the cost of updating a financial model was incredibly high, so you thought carefully about what projections you wanted to make and then built a model once. With Excel, updates automatically cascade, so you can build and update many models quickly and efficiently – a static projection turned into the ability to ask “What if?” at will. Notably, this didn’t remove the need for accountants; it raised the level of abstraction from someone doing literal calculations to someone doing strategic analysis.
This abundance mindset should change how you spend your time. When the cost of trying the nth possibility drops to zero, you should try many things quickly and in parallel. Most – perhaps almost all – of them will turn out to be useless, but that’s okay. By trying lots of things quickly, you’ve dramatically increased the chances that one of them will be right, and you’ve dramatically shortened the time it took you to get there. You no longer need to be judicious with your time – you need to be activity oriented. And when you change how you spend your time, what you expect from your tools changes in lockstep.
The New ROI of Your Time
Historically, the bar for automation was high. If you spend two to four hours a week on a repetitive task, you’d have to weigh that against the amount of time you’d invest into automating that task. If it took forty or eighty hours of time to build that automation, you had to perform that task almost every week for a year just to break even – and the task would likely change in that time, making your effort wasted. You had to be judicious with your time.
Today, it might cost thirty minutes and twenty dollars of tokens on Claude Code to automate that same task. The effort pays itself back within a single week. When the cost of trying something new drops by orders of magnitude, there are many more things that you can justifiably try.
In the enterprise setting, experience has historically been valuable because it allowed you to know exactly what paths to take to avoid expensive mistakes. Today, judicious planning matters less than a willingness to try many things. When executing on any one path becomes cheap, the mathematical probability of finding the right solution increases simply by running more experiments in parallel. And this isn’t just true with code – it applies to marketing plans, product specs, and business strategies. The end goal is no longer coming up with and executing on the right plan. Instead, experience is valuable because you need the taste to know what to build and what is good – that’s where you will create the most value.
We’re already seeing this change the way engineering and product teams operate. It no longer makes sense for designers or product managers to spend all their time making Figma mocks or writing static PRDs. You want the person defining the product to spend their time imagining possibilities and writing lots of cheap code without paying any attention to syntax, style, or long-term scalability. The goal is to get to a point where they can illustrate exactly what they want with something that looks and feels like a real product.
From there, it becomes dramatically easier for a talented, disciplined software engineer to take that prototype and apply the operational rigor required to make it scalable – without having to port over the specific vision of the product features. Both roles are still essential, but the interface between them has just become much higher bandwidth.
It’s worth noting briefly that despite the value of these prototypes – and despite recent concerns in the public markets – a DIY AI-generated prototype is not going to replace core SaaS products like Salesforce or Workday. The gap between something running on your laptop and a core pillar of your business is still large.
The Wasteful Agent
What’s even more interesting to us is that we think that this is a signal of where AI products should be headed too. A trend we’ve seen is that the AI application layer tends to adopt user behavior. The early days of GPT had users adding chain-of-thought style patterns into their prompts – that led to reasoning models that were trained natively to do chain-of-thought. As the abundance mindset spreads into more and more application usage, we believe that agents should be designed to embrace abundance.
From a user experience perspective, the cost of missing the right answer is almost always higher than the added token cost of doing an extra speculative task. Paradoxically, it very well might end up being cheaper to do many parallel attempts at a small unit of work, getting user feedback, and iterating on your plan. That is likely cheaper than making strong assumptions, going down the wrong path, and forcing a user to retry the task altogether or give up.
In previous posts, we’ve talked about AI slide generators as an example of a product category that has thus far failed to deliver high quality results, largely because they do not give users the opportunity to give incremental feedback. The ideal UX we’d want to see is one where the agent reads our input, comes up with a few possible designs for a single slide, and lets me pick one or prompt feedback before proceeding. That will lead to better results – and be cheaper! – than generating a whole slide deck riddled with assumptions that the user then struggles to unwind. Throwing one a handful of slide designs to make sure you satisfy the user seems like an obviously positive tradeoff.
Once you embody this mindset, it becomes obvious that your product should try lots of different things, with the knowledge that not all of them will yield useful results. If you maximize the quality of your agent by ensuring it always finds the right path — even if it takes a wasteful speculative path to get there — you will command a premium over any tool that is more judicious but often misses the mark.
The 2-Year Horizon
We believe this is going to be the standard for how most agents operate in the next 12 to 24 months. In the same way that no one ever prompts reasoning into a model anyway, we will come to expect that our agents try many possible paths and present possible next steps or pick the best option in cases where they’re positive – an agent level form of beam search.
To us, this is an obviously superior experience. If we’re scaffolding a new app with Claude Code, we would love if Claude presented us with a few UI design concepts – similar to what a good designer would do – and let us pick and tweak before proceeding. The same would be true with engineering designs, business strategies, and slide decks.
This loop of trying something with variance, seeing where it lands, and connecting it back to the user’s taste is the loop we think every agent should create. Humans are already doing this manually. Moving it down into the agent layer is inevitable. The only question for you as a builder is: Can you design the right interaction model to harness this abundance?