--- id: ins_evans-ai-adoption-tool-builder-gap operator: Benedict Evans operator_role: Independent tech analyst; former Andreessen Horowitz partner; newsletter author on AI and technology co_operators: [] source_url: https://www.ben-evans.com/benedictevans/2026/9/3/ai-tools-and-transformation source_type: post source_title: "AI tools and transformation" source_date: 2026-09-03 captured_date: 2026-09-07 domain: [ai-native] lifecycle: [ai-workflow] maturity: applied artifact_class: framework score: { originality: 3, specificity: 4, evidence: 3, transferability: 5, source: 4 } tier: B related: [ins_evans-token-pricing-commoditization, ins_mollick-twilight-factory-human-loop] raw_ref: "" --- # Most employees cannot self-identify automation opportunities, so AI adoption requires someone outside the workflow to design the tool ## Claim AI adoption in non-technical organizations stalls because the people best positioned to use AI tools are the same people least able to recognize that their work could be restructured. Transformation requires an external perspective to identify where tools are needed and what they should do. ## Mechanism Tool-builders have a distinct cognitive mode: they model tasks as systems, identify friction as restructurable, and naturally imagine software solutions. Most workers do not operate this way. They execute tasks as inherited practice and optimize within existing structure rather than questioning the structure itself. Evans identifies this as a gap in perception, not capability: > "most people are not tool builders, and most people don't instinctively think about how their job could be done in a different way" When organizations attempt bottom-up AI adoption by giving employees access to AI tools and asking them to find use cases, they rely on tool-builder cognition from people who do not have it. The people closest to the work cannot see it as a system to be redesigned. The implication is structural. Successful AI adoption requires someone with tool-builder cognition to observe existing workflows from outside, identify where restructuring is possible, and build the specific tool that workflow needs. This cannot be delegated to the workflow participants themselves: > "The hard part is knowing that you need a tool for this in the first place, and then knowing what the tool should do." ## Conditions Holds when: organizations deploy AI through employee self-service access without a designated workflow redesign function. Strongest in roles with high tacit knowledge and low prior digitization, where workers have internalized existing process as the natural way to do the job. Fails when: the workforce is already technically literate enough to model their own work as systems. Also fails when a single function is small enough that one embedded tool-builder can cover it directly. ## Evidence Evans grounds the observation in the Silicon Valley bubble: > "If you're a tool-builder, and everybody in Silicon Valley is a tool-builder, this is intoxicating." The trap is that tool-builder concentration in AI development circles creates a systematic blind spot about how most workforces actually operate. Analysts and founders project their own cognitive mode onto employees who do not share it, then mistake slow adoption for resistance rather than perception failure. ## Signals - AI tool pilots generate high engagement from the engineering and product teams but low uptake in operations, finance, or customer success. - Employees who try AI tools report they can't think of what to use them for, while analysts can list dozens of immediate applications. - Productivity gains from AI remain concentrated in already-technical roles two years after tool deployment. ## Counter-evidence The tool-builder gap assumes a clear separation between tool-builders and non-tool-builders that may be dissolving as conversational AI lowers the barrier to tool construction. Workers who previously lacked programming skills can now describe a task to an AI and have it produce a functional tool. Whether this changes the underlying perception problem or just lowers the cost of building what they already knew they needed remains untested at scale. ## Cross-references - ins_evans-token-pricing-commoditization - ins_mollick-twilight-factory-human-loop