AI tools don't transform work. Naming the problem does.

The gap between AI tools and transformation is not a model problem, and after a year of watching teams try to close it, I'm fairly sure it never was. Benedict Evans made this point sharply in AI, Tools and Transformation, and his framing is the most useful thing I've read on enterprise AI this month.

His core line is the one I keep coming back to: the hard part is knowing you need a tool for this in the first place, and then knowing what the tool should do. Everything else is downstream of that.

---

🔍 Most people are not tool builders, and that's fine

Evans's observation is that Silicon Valley assumes AI democratises automation, so anyone can now build the thing they need. But a matrimonial lawyer thinks about cases, not legal software. A salesperson thinks about clients, not sales enablement.

This is not a skills gap you fix with a prompt-engineering workshop. It's a framing gap. People who are good at their job have compressed their workflow into muscle memory, and muscle memory is invisible to the person using it.

Key takeaway: The scarce skill in 2026 is not building software with AI. It's noticing that a repeated piece of your week is actually a process, and then describing it precisely enough that anything, human or model, could execute it.

It's the real reason two teams with identical model access get wildly different results.

---

📊 Improvised vs institutionalised: where your team actually lives

The most portable idea in the piece is a spectrum. Some tasks are institutionalised: a dedicated system, a standard process, the same across every department. Evans names SAP and Workday. Other tasks are improvised, and he lists where they live: Excel, email, shared folders, Tableau, PowerPoint, CSVs, screenshots, PDFs and conference calls.

Read that list again. If you work at a Sri Lankan SME, an agency, or a 12-person product team, that list is not a description of the messy edges of your company. It is your company.

	Institutionalised	Improvised
Where it lives	SAP, Workday, a real SaaS product	Sheets, WhatsApp, email threads, CSVs
Cost to change	High (procurement, IT, training)	Near zero
Who owns it	A department	Whoever built the sheet
AI entry point	Vendor roadmap, months out	This afternoon
Failure mode	Rigid, so teams route around it	Undocumented, dies when one person leaves

Evans describes the transition as paving the desire path and paying someone to set it in stone. That's the whole lifecycle: a task gets improvised, becomes recurring and important, and then someone institutionalises it. He notes the cycle runs both ways: teams inside large companies fall back to spreadsheets whenever the enterprise system is too inflexible.

---

🇱🇰 Why small Sri Lankan teams are better positioned than they think

Here's my actual argument, and it's more optimistic than the source.

Evans points out that large companies have hundreds, and perhaps thousands of software systems, and frequently don't know how many they have, what's being used, or what they're paying for. Every AI change in that environment has to be negotiated against that estate.

A five-person team in Colombo has none of that. Which means:

1. Your desire paths are visible. You can see the whole workflow in one Google Sheet and one WhatsApp group.
2. Your cost of institutionalising is a weekend, not a procurement cycle. No vendor, no committee.
3. You are the domain expert and the builder. The framing gap that blocks large firms doesn't exist when the same person does both jobs.
4. Your constraint is honest. You can't afford to burn six months on a pilot, so you'll kill bad ideas faster.

The disadvantage is real too: no budget for failure. Evans notes that of the AI-enabled workflow pilots companies run, roughly half work, which he flags as a normal project success rate. A large firm running ten pilots can absorb five failures. You cannot. So run smaller experiments, more of them, and cap each one at a week.

If half of all attempts fail no matter who runs them, then the only variable you control is how cheap each attempt is.

---

🛠️ How to find the desire paths in your own week

This is the part the original article deliberately doesn't give you, because it's writing for strategists. Here's the version for builders.

For two weeks, keep one file. Every time you do something for at least the third time, write a line:

2026-09-06 | rebuilt the same invoice summary from 4 CSVs      | ~40 min | 3rd time this month
2026-09-06 | reformatted client JSON into a TS interface by hand | ~15 min | weekly
2026-09-06 | rewrote the same 6 status updates for the group chat | ~20 min | daily

Then sort by frequency × minutes. That ranking is your build queue, and it is worth more than any list of AI use cases a consultant will sell you.

Two rules I'd add:

• Automate the recurring, not the annoying. The most irritating task is often a once-a-quarter task. Leave it alone.
• Check whether it's already solved before you build. A surprising share of that log is generic file and text work. Converting spreadsheets, reshaping data, cleaning up formats. If a line in your log reads "turn this CSV into something usable," a free tool like our CSV to Excel converter or JSON formatter closes it in ten seconds, and the honest answer is that you don't need to build anything at all.

Roughly a third of my own log resolved that way. The remaining two-thirds were the real candidates.

---

🚀 The part everyone will get wrong

Evans closes on the historical pattern, and it's the line worth pinning above your desk. Giving everyone a PC and Lotus 123 in 1983 did not restructure invoice processing. Giving everyone a web browser in 1997 did not rebuild supply chains. He sees today's enterprise AI rollouts repeating the shape: a company hands Copilot to everybody, a small group uses it constantly, a larger group uses it a couple of times a week, and the org chart stays exactly the same.

His conclusion is that with every previous platform shift, what actually mattered was the stuff that wasn't possible before and that nobody had imagined.

I'd translate that into a warning for anyone building right now: if your AI project's pitch is "the same thing, but faster," you are building the 1983 spreadsheet. Useful. Not transformative. The interesting work is the thing you'd never have staffed a person to do because it was economically absurd, and which is now trivial.

---

💡 What this means for you

• Stop shopping for AI tools. Start logging repeated tasks. The bottleneck is problem recognition, not capability.
• Know which half of the spectrum you're on. If you're improvising, your advantage is speed. Use it before you institutionalise anything.
• Budget for a 50% failure rate, then make each attempt small enough that failing costs you a week.
• Ask the harder question once a quarter: what could we now do that was previously impossible? That's where the actual change comes from, and almost nobody is asking it.