Benedict Evans argues AI won't sweep away enterprise apps

A typical large American company runs hundreds, and perhaps thousands, of different pieces of software, from big horizontal systems like SAP and Workday down to hundreds of vertical SaaS apps and, at the smallest end, a 10 meg spreadsheet running one department, often without the company knowing quite what it has or what it costs. In an essay titled 'AI, Tools and Transformation', Benedict Evans starts from the temptation to think AI will sweep most of that software away: there is an old engineering joke about spending an hour building a tool to automate a 10 minute task, and with AI that same tool now takes five minutes to build, with no code required.

Evans argues this excitement misunderstands where software actually comes from. Most people are not tool builders and do not instinctively think about redesigning their own job: a great matrimonial lawyer thinks about cases and clients, not legal discovery software, and a great enterprise salesperson thinks about the product and the competition, not sales enablement tools. Products like Excel try to close that gap with onboarding flows, assistants and templates, and Evans places products like 'Claude for X' in the same category: helpful, but not the answer. This is also why the 'forward deployed engineer' role has emerged, someone who knows what AI can build and can walk through a law firm or an architecture office spotting automatable tasks that the people doing the work do not see themselves, the way a teenager on a summer internship might notice a shortcut their parents never considered.

The deeper problem, in Evans's telling, is that most of what has been automated over past decades was not obviously a problem even to a tool builder, and fixing it required redefining or unbundling the task, something that took several failed attempts for many now-successful software companies. Even after a good tool exists, getting everyone to use it is harder still: a workflow worth automating might touch 50 to 500 people across five departments, three systems of record and four regulatory regimes, which turns the fix into a purchase decision and an 18-month sales process, not something one employee can simply adopt.

Evans frames enterprise software as a spectrum running from 'institutionalised' tools such as SAP, Carta or Rippling, where a company has standardized on one correct way of doing a task, to 'improvised' ones such as Excel, email, shared folders, Tableau, PowerPoint, CSVs, screenshots, PDFs and conference calls, where users handle edge cases on their own. Once an improvised task becomes routine, important, and carries real revenue and risk, companies eventually institutionalize it, which is why they end up with hundreds of apps. He points to the shift to SaaS as the last such order of magnitude change, one that killed incumbents unable to adapt, and cites Carta, now a $4bn company that in essence manages one spreadsheet for a company's CFO, as an app built on a task Excel already did; a consultant he once spoke with said half of his work was moving Excel users onto a database and the other half was moving database users back to Excel.

AI, Evans argues, does not break this cycle of bundling and unbundling but rides it: existing apps gain AI features, new AI-native vertical apps appear, and the chatbot itself becomes a new freeform space alongside Excel and email, taking tasks from other tools while losing tasks back to them. A small firm hiring five or ten graduates a year might stay on Google Sheets longer because AI makes it scale further, right up until a new AI-native app appears aimed squarely at its problem.

Applying this to the last three years of enterprise AI rollouts, Evans says giving everyone Copilot, ChatGPT or Claude has produced a small group of heavy users who are genuinely more productive, a larger group using it a couple of times a week, and a lot of the rest who are barely using it at all. He compares this to giving every worker a PC and Lotus 123 in 1983, or an internet connection and a browser in 1997: necessary steps, but not themselves what rebuilt invoice processing or supply chain management. Companies typically respond by running pilots, of which roughly half work by his account, which he calls normal since that is the point of piloting, yet boards and CEOs still look at hundreds of workflows against five or ten completed pilots and conclude, in his hypothetical framing, that the approach does not scale, even though handing everyone a chatbot notionally should.

Evans closes by arguing every company facing a transformative technology has to answer three questions: how to buy, build and deploy it, whether from a vendor bundle, an internal build, an outside build or a startup's tool; how far it actually changes operations, an answer that differs by industry; and whether it creates new competitive or economic threats to the business itself. He notes this drives a wave of professional-services pitches, for example around deploying an LLM-based voice analytics tool in a call center, typically through a firm like Accenture, and that the big AI labs now run their own 'deploycos', updating an older joke that a machine learning scientist is a statistician who lives in San Francisco: now, he suggests, a forward deployed engineer might be anyone a lab like OpenAI hires for exactly this kind of work.

Key facts

A typical big American company runs hundreds, and perhaps thousands, of different pieces of software, from SAP and Workday down to a 10 meg departmental spreadsheet, per Evans.
AI has cut the time to build a small automation tool from an hour to five minutes with no code, but Evans argues most employees are not tool builders and cannot see what in their own job could be automated, which is why the 'forward deployed engineer' role has emerged.
A single automatable workflow can touch 50 to 500 people, five departments, three systems of record and four regulatory regimes, which Evans says turns fixing it into an 18-month sales process rather than a quick build.
Evans cites Carta, now a $4bn company built on managing one spreadsheet for a CFO, and a consultant who said half his work moved clients from Excel to a database and half moved them back, as evidence of a continuous cycle of bundling and unbundling that AI now rides rather than breaks.
Evans says roughly half of enterprise AI pilots work, which he calls normal, and that giving everyone Copilot, ChatGPT or Claude has, so far, mostly repeated the pattern of giving every worker a PC and Lotus 123 in 1983 or a browser in 1997: necessary, but not by itself transformative.

Why it matters

The essay pushes back on a common assumption that letting anyone generate a tool in minutes will sweep away the mass of software inside big companies. Evans argues the real bottleneck was never how long a tool takes to build: it is that most employees cannot see what in their own job needs automating, and that even a well-built tool still has to survive an institutional buying process before it changes how a whole company works. That reframes the debate around AI and enterprise productivity away from whether a model can do a task and toward whether anyone with that task will ever think to ask it.

Who it affects

Enterprise software vendors and systems of record such as SAP, Workday, Carta and Rippling, whose business rests on institutionalizing work that started out improvised; consultancies like Accenture and PwC, which sell change management and deployment help and are themselves being asked new questions by AI; CIOs and boards running AI pilots; the emerging 'forward deployed engineer' role at AI labs and elsewhere; and the ordinary employees inside big companies who were handed Copilot, ChatGPT or Claude, a lot of whom barely use them.

How to use it

Evans offers a three-question framework rather than a product to buy. First, decide how to buy, build and deploy: take a vendor's bundled AI feature, build internally, pay someone to build it, or buy a startup's dedicated tool. Second, work out how far AI actually changes core operations, since the answer differs by industry, say for an insurance company versus a law firm. Third, assess whether it opens new competitive or economic threats to the business itself. He stresses none of this is answered by simply distributing a chatbot company-wide; it needs the same forward-deployed legwork of spotting real workflows and the same institutional buy-in any past technology shift required.

How solid is it

This is an opinion essay by an established technology commentator, not a study, built on illustrative anecdotes rather than a dataset: a remembered conversation with an unnamed consultant, a hypothetical comparison between PwC and a small firm, and a roughly half pilot success rate the piece attributes only to unspecified existing data without naming a source or study. The historical analogies to PCs and Lotus 123 in 1983 and browsers in 1997 argue by parallel rather than measurement. The underlying pattern of institutionalizing improvised tools tracks well-documented behavior from the SaaS era, but the piece itself is reasoned commentary, not primary research.

Risks and caveats

Evans's own numbers cut both ways: if roughly half of enterprise AI pilots work, half do not, and his framework offers no shortcut past that split. A company that reads 'AI will not replace this all at once' as license to skip change management risks repeating the mistake he describes with PCs and browsers, handing out a tool without ever mapping it to a specific task. A company that over-invests in one-off pilots without institutionalizing what works risks the opposite failure he attributes to frustrated boards, running five or ten pilots against hundreds of workflows and concluding, wrongly, that AI adoption cannot scale.

“The hard part is knowing that you need a tool for this in the first place, and then knowing what the tool should do.”

— Benedict Evans, "AI, Tools and Transformation"