# Benedict Evans Argues AI Will Change Workflows More Than It Will Replace Software
Benedict Evans has published a long argument against one of the loudest assumptions in AI strategy: that if software can now be generated on demand, then traditional applications are headed for extinction. In his essay, AI, tools and transformation, Evans says that view misunderstands how companies actually use software, how people identify problems, and why institutional change is slower than tool creation.
The core of his case is that most organizations already live inside a dense software stack. Evans describes the typical large American company as carrying a mixture of major systems of record, vertical SaaS products, and a large number of spreadsheets, scripts, automations, and databases that sit around the edges of official systems. The existence of that stack does not mean the company is well automated. It often means the opposite: there are many repetitive tasks, many hidden workarounds, and many places where employees improvise because the formal tools do not quite fit the job.
Evans argues that AI does not remove the harder part of the problem. Making a small utility or assistant in minutes is useful, but it does not tell a company what should be automated in the first place. In his view, many people are not tool builders and do not naturally think in terms of rebuilding their own workflows. That gap is why the idea of the forward deployed engineer has become popular: someone who understands both the technology and the work can spot opportunities that domain experts overlook.
He also says many of the biggest software opportunities are not obvious even when the underlying problem exists. Some tasks are embedded inside other processes; others are not recognized as problems until someone reframes them. The implication is that AI may speed up solution building without simplifying the work of diagnosis. Evans is skeptical that better code generation alone solves that strategic layer.
Another theme in the essay is organizational scale. Even when an employee can imagine a better process, that person often cannot deploy it alone if the task touches many teams, systems, or regulatory environments. In that case, the fix has to move through procurement, governance, and accountability. Evans describes software as sitting on a spectrum from improvised and bottom-up to institutionalized and top-down. Spreadsheets and email help with edge cases; formal systems take over once a process becomes important enough to demand consistency and auditability.
That framing helps explain why software keeps multiplying instead of consolidating. As workflows harden, companies pave the desire path and turn a workaround into a product or platform. As conditions change, some work moves back into flexible tools. Evans links that pattern to the rise of SaaS, which increased the number of separate applications while changing how they were bought, deployed, and maintained.
His conclusion is less a rejection of AI than a warning against over-simplifying it. More software may become dynamic and more people may be able to create small tools for themselves, but the larger business challenge remains: identifying the right tasks, deciding which ones deserve institutional support, and persuading an organization to use the new system consistently. For Evans, that is where the real transformation will happen, and it is also where the easiest claims about AI are most likely to break down.
