The Toolbuilder's Fallacy: Why AI Can Make Any Tool But Can't Find the Problems

There is an old joke that an engineer is someone who will spend an hour building a tool to automate a task that would take ten minutes. The punchline used to be about engineers and their tendency to over-engineer. But in 2026, the joke has a new punchline: now you can build that tool in five minutes, you do not need to be an engineer, and you do not need to write code. You just ask the model.

This is the starting point of Benedict Evans's recent essay AI, Tools and Transformation, which has been generating significant discussion in tech circles after hitting the front page of Hacker News with over 350 points. His argument is both simple and quietly devastating for the AI maximalist position: making tools easier to build does not solve the actual bottleneck in enterprise software.

The Fortune 500 Has Thousands of Apps and Still Can't Automate Its Inbox

Consider the typical large American company. It has hundreds, possibly thousands, of different pieces of software. There are giant horizontal systems of record like SAP and Workday. There are hundreds of vertical SaaS applications for every department. Then there are the workflows, scripts, automations, and databases that nobody officially sanctioned, right down to the ten-megabyte spreadsheet quietly running an entire department.

And yet, with all this software, the company is still full of boring, repetitive tasks. This is the paradox that AI evangelists keep running into: more software has not meant less drudgery. The assumption is that AI will finally bridge that gap, sweeping away the complexity and replacing it with dynamic, generative, on-demand automation.

Evans thinks this misunderstands something fundamental.

Most People Are Not Tool Builders

The first problem is human, not technical. Most people are not tool builders, and most people do not instinctively think about how their job could be done differently. If you spend all your time in the Silicon Valley bubble, this is easy to forget. Your entire world is about creating tools that change how things are done.

But if you are a great matrimonial lawyer, you spend your day thinking about cases and clients, not about what great legal discovery software would look like. If you are a great enterprise salesperson, you think about your product and your competitors, not about how sales enablement software could make you more productive.

This is why the idea of the forward-deployed engineer has gained traction. You take someone who is a builder and who knows what AI can build, and you send them walking around a law firm or an architecture office to spot the opportunities that the lawyer or architect does not see. It is the tech equivalent of a teenager wandering through their parents' office and realizing that a spreadsheet could replace three hours of manual data entry.

The Hard Part Is Knowing You Need a Tool at All

But even this only addresses part of the problem. Evans points out that most of what we have automated in the last few decades was not obvious, even to tool builders. We can all think of products we use every day where our first reaction was, "Why would I want that?"

Very often, the problem does not obviously exist. It is embedded or bundled or hidden inside something else. Even if you can see the problem, the right way to fix it is rarely clear. For many successful software companies, there were half a dozen failed attempts that came before, each one not quite finding the right approach or the right problem to solve.

Making it easier to write code does not solve this. The hard part is not building the tool. The hard part is knowing you need a tool in the first place, and then knowing what the tool should do.

The Organizational Layer: Getting 500 People to Change How They Work

Even if you identify the problem and build the perfect tool, you face a second wall: adoption. Many of the workflows that need automating touch 50 or 500 people across five departments, three systems of record, and four regulatory regimes. You might have a brilliant idea for doing accounts payable differently, but you alone cannot change how everyone in the company does it.

That has to be a purchase, and a decision, and an eighteen-month sales process. Software lives on a spectrum from top-down to bottom-up, from institutionalized to improvised. The SAP installation is institutionalized. The spreadsheet someone made on their lunch break is improvised. Both have their place, and AI does not magically collapse the distance between them.

What This Means for the AI Industry

Evans's argument has uncomfortable implications for the current wave of AI startups betting on enterprise transformation:

• If the bottleneck is not building tools but finding problems, then AI coding agents that make tool creation faster are solving the easy part, not the hard part.
• The forward-deployed engineer model works, but it does not scale. You cannot send a builder to every office in the world. The question is whether AI can help people see problems they do not know they have.
• Enterprise sales cycles are not going away. Even the most impressive AI demo still has to survive the organizational gauntlet of procurement, compliance, and change management.
• The biggest opportunities may be in AI that helps people discover what to automate, not just in AI that automates what people already know about.

The Real Transformation

Evans is not arguing that AI will not transform enterprise software. He is arguing that the transformation will look less like a sudden sweep of existing tools and more like the long, messy process that has always characterized enterprise software adoption. Problems will be discovered slowly. Tools will be built quickly but adopted slowly. The companies that win will be the ones that figure out how to help people see the problems they are sitting on, not just the ones that build the fastest tools.

The toolbuilder's fallacy is believing that if you make building tools trivially easy, everything else follows. But everything else — the discovery, the design, the organizational change — is the actual hard part. AI makes the easy part free. It does not make the hard part easy.

That is the real lesson from Evans's essay, and it is one that every AI startup pitching enterprise transformation should write on a sticky note and put on their mirror. The future of enterprise AI is not about who can build the most tools the fastest. It is about who can help the most people figure out which tools they actually need.