Does easier tool-building actually solve enterprise adoption problems?

Benedict Evans argues that AI's power to make tool-building trivial is being mistaken for a power to transform companies. He grants the premise — "now you can make that tool in five minutes, and you don't need to be an engineer" — but calls the conclusion a misunderstanding of "where software comes from and how people use it" and "how companies change." His reasoning: "most people are not tool builders, and most people don't instinctively think about how their job could be done in a different way," so the task worth automating "might be sitting in plain sight but the people with that task don't see it." Worse, even a tool-builder who spots the problem usually finds "it's not obvious that the problem exists" and the fix "often isn't clear either." He states the conclusion directly: "None of this is solved by making it easier to write code... The hard part is knowing that you need a tool for this in the first place, and then knowing what the tool should do."

His second mechanism is organizational: even a good fix for one person "has to be a purchase, and a decision, and an 18-month sales process" once it touches "50 or 500 people across five different departments." He frames all enterprise software as sitting on a spectrum from "institutionalized" (SAP, Workday — audited, maintained, uniform) to "improvised" (Excel, email, screenshots — fast, fuzzy, bottom-up), with tasks migrating toward institutionalization only once they become frequent, important, and carry revenue or risk. AI, in his account, "doesn't change the question: it creates new choices and moves the thresholds" on that spectrum — it does not dissolve the spectrum itself. He reads current enterprise rollouts through this lens: companies gave "everyone Copilot (or maybe ChatGPT or Claude)," a few people use it heavily, most don't, and he calls this "mostly the same problem" as handing everyone a PC and Lotus 1-2-3 in 1983 or a browser in 1997 — necessary but not sufficient for transforming a specific workflow like invoice processing or supply chain management.

This gives a structural reason for a pattern the library has already observed empirically at smaller scale. How are national lab staff actually using generative AI? finds one lab's staff mostly doing verifiable, low-stakes tasks (summarizing, drafting) and holding back from higher-value, higher-risk extraction work out of "fears of hallucinations and reliability" — exactly the gap between improvised, easily-reversed use and institutionalized, audited use that Evans's spectrum predicts. Does generative AI shift knowledge workers away from communication? finds a skewed, heavy-user-only effect in M365 trace data; Evans's essay supplies a candidate explanation for why adoption concentrates in a minority rather than spreading evenly — most employees aren't positioned to see the task worth redefining, so only some reshape their work at all.

Evans's essay is argument and historical analogy, not new data; he cites no company names, surveys, or figures for the "small number of people using this a lot" claim, so it does not establish how general that adoption pattern is beyond his own observation of "the last three years." It also does not say how long the PC/Lotus and browser analogies took to resolve into real transformation, which matters for how much patience the comparison implies. The strength the argument allows: current flat or shallow AI uptake inside companies should not be read as AI's ceiling, nor as imminent sweeping transformation — on this account it is the same slow, uneven, adoption-constrained process that every prior general-purpose tool went through, pending the harder organizational work of finding and institutionalizing specific workflows.