Why AI Won't Reinvent Software Overnight: Benedict Evans on the Limits of Generative Tools

Benedict Evans' latest essay, "AI, Tools and Transformation", pushes back on the Silicon Valley fantasy that AI will let users spontaneously generate the software they need, eliminating the need for traditional enterprise suites. His core argument: the bottleneck isn't building tools, it's knowing which tools to build and getting hundreds of people to adopt them.

The "Engineer's Joke" Reversed

Evans opens with the classic joke: an engineer will spend an hour automating a task that takes 10 minutes. But with AI, "you can make that tool in five minutes, and you don't need to be an engineer." The intoxicating idea is that software becomes dynamic, generative, free-form—massively more tasks automated with massively less code. Yet he cautions this misunderstands how software gets adopted inside real companies.

Why Most Users Aren't Tool-Builders

Drawing on the reality of a typical large enterprise—hundreds of SaaS apps, scripts, and spreadsheets—Evans notes that most people aren't like Silicon Valley engineers. "If you're a really great matrimonial lawyer, you spend all your day thinking about your cases and your clients, not about what great legal discovery software would do." This is why spreadsheet templates and 'File/New' suggestions exist: they try to bridge the gap for non-builders, but they remain partial answers.

The missed opportunities are often invisible to the people who have them. Evans cites the emerging role of the 'forward-deployed engineer'—someone who can walk through a law firm or architecture office and spot automation potential that the expert doesn't see, the way a tech-savvy teen might say, "Daddy, did you realise you could just do it like this?"

Seeing the Problem Is the Hard Part

Beyond individual perception, many transformative automations weren't obvious even to engineers. "We can all think of examples of stuff we use every day where our first reaction was 'Why would I want that?'" The problem may be embedded in another workflow, and finding the right solution often requires redefining the problem itself—something that took half a dozen failed attempts for many successful software companies.

Automation Touches Departments, Not Just Individuals

Scaling a workflow change beyond a single user is what Evans calls the "institutionalised to improvised" spectrum. A bottom-up spreadsheet can handle a department, but a new accounts payable process touches five departments, three systems of record, and four regulatory regimes. That change "has to be a purchase, and a decision, and an 18-month sales process," not just a quick AI prompt.

None of this is solved by making it easier to write code. The hard parts—recognizing the need, defining the tool, and driving adoption—remain stubbornly human and organizational. That's a sobering counterpoint to the 'democratizing software creation' narrative we hear so much.