The Chatbot Is Not a Strategy

Ask to see an organisation's AI strategy and you will, more often than you would hope, be shown a chat window. It sits in the corner of the product, it carries the brand colours, it launched with a press release, and nobody can tell you what problem it solves. The same organisation has usually made the matching move inward: developers were handed an AI assistant licence, told to “use AI”, and left to it. Neither of these is a strategy. Both are the appearance of one, and the appearance is expensive.

A provenance note: the research beneath this article began as a machine-assisted literature sweep - an AI agent gathered the sources and drafted the notes. I have since read it as an editor, verified every figure against its primary source, corrected the ones that did not hold up, and rewritten the argument as my own; where a claim rests on a single vendor blog, I say so inline.

The interface that asks the least

The chatbot ships first because it demands the least. It requires no workflow analysis, no rethinking of the product, no opinion about where a model actually helps — you wrap an API, dock a panel, and the roadmap slide gets to say “AI-powered”. The cost of that convenience lands on whoever has to use the thing.

For customers, a general-purpose chat window rarely solves the problem they arrived with. It relocates the work instead — from navigating your interface to composing the right prompt, and then to judging whether the answer can be trusted. A customer who wants to complete a specific task is better served by a purpose-built flow with a model working inside it than by an open text box and good luck. The chatbot does not remove cognitive burden; it transfers it — and it transfers it to the person you were supposed to be helping.

For developers, the identical mistake wears different clothes. A team is given an assistant and a mandate, with no shared view of where the tools help, which work they suit, or how their output gets reviewed. The result is scattered experimentation with wildly uneven outcomes, and the industry-scale numbers show it. The 2025 Stack Overflow Developer Survey found that roughly half of developers — 52% — reported a positive productivity effect from AI tools. Half. For the most heavily marketed capability shift in a generation, access alone is visibly failing to convert into value.

Intent is the missing ingredient

The alternative has a name and a growing literature. Insight Partners, in a blog article on 2026 adoption patterns, put it in a single sentence: “The defining advantage of 2026 is not access to AI, but the ability to deploy it with intent.” PwC's 2026 AI business predictions describe the same behaviour from the leadership end: the organisations getting results pick a small number of workflows where the payoff is measurable and concentrate their investment there, rather than spreading AI thinly across everything and hoping. And the broader commentary of that period — I am writing this well after the fact, so time-stamp it accordingly — converged on the view that AI was moving from a feature you bolt onto software to infrastructure you architect around. A feature can be bolted on. Infrastructure requires intent by definition.

The developer-side expression of the same philosophy is what KodeNerds calls intent-driven development, and their aphorism for it earns its quotation marks: “The bottleneck is no longer execution. It's clarity.” When a working implementation costs an afternoon instead of a sprint, the scarce skill stops being the ability to build and becomes the ability to say precisely what should exist and why. Every hour spent sharpening the problem statement now buys more than an hour spent typing.

Four stages, climbed on purpose

The most useful map I have found of the customer-facing journey comes from Sebastian Clavijo Correa at Wizeline, who describes adoption in four stages. In my paraphrase: an Explorer stage, where individuals use AI for personal productivity — real value, but private and unrepeatable; a Connector stage, where the organisation wires models into its own knowledge sources — building what Wizeline calls a “corporate brain” — so that answers become specific to the business instead of generic; a Specialist stage, where model behaviour is shaped to the organisation's brand, governance and compliance constraints, which is where anything competitively defensible starts to exist; and an Industrializer stage, where all of it runs at production scale with deliberate cost engineering. Wizeline's own claim is that this last discipline can reduce operating costs by up to 60% — a vendor figure, and I pass it on as exactly that.

What the staging gets right is the direction of travel. Each step upward replaces a generic capability with a purpose-built one, and each replacement demands that someone in the organisation knew precisely what they wanted from it. You cannot climb this ladder by accident, and you cannot climb it by buying licences.

Maturity is not adoption

Floyd Smith at Larridin draws the internal version of the same map: five maturity levels, running — in my summary, not their table — from AI Curious (scattered individual experimentation, no structure) through AI Exploring (a tool or two, unevenly used) and AI Scaling (a managed portfolio with genuine measurement) to AI Embedded (AI inside the daily workflows, governed) and finally AI-Native (AI as the organisation's default way of operating). Their aphorism deserves quoting verbatim: “Adoption without proficiency is activity without value.”

The gap those levels describe has been measured, and the measurement is uncomfortable. McKinsey's Superagency in the Workplace (January 2025) reported that 78% of organisations were using AI in at least one business function — and that only 1% of leaders described their deployments as mature. Sit with that pair for a moment. Nearly everyone has adopted; almost nobody has arrived. The gap between 78% and 1% is not a technology gap — it is an intent gap, and no procurement decision closes it.

Two more figures sharpen the picture, each carried with its handling instructions. Larridin, citing OpenAI, reports a sixfold productivity gap between AI power users and average employees — a reported, not independently verified, figure. And Larridin's framing of what maturity looks like day to day is instructive even without numbers: an organisation where most staff use a general-purpose chatbot for ad-hoc tasks has a fundamentally different profile from one where a smaller share of staff use a deliberately assembled portfolio of purpose-built tools embedded in their workflows. The first is adoption. The second is intent.

A provocation about team shape

One claim from this literature I will hand you only with tongs. The same KodeNerds article argues that intent-driven development inverts the traditional team ratio — from roughly 20% product thinking, 60% engineering execution and 20% design to 60% product judgement, 30% architecture and 10% design precision. Those numbers come from a single consultancy blog with no supporting data behind them, so treat them as a provocation, not a finding. But the provocation points somewhere real. If execution genuinely stops being the constraint, the centre of gravity in a team has to move towards deciding — towards the people who can define the problem, judge the trade-offs and hold the quality bar. That is not fewer engineers; it is engineers spending their hours differently.

What this means on Monday

If you own a product, the test is blunt: name the workflow your AI investment changes and the measurement that will show it changed. If the honest answer is “we added a chat window”, you have shipped an interface, not a capability — and your customers are already telling you, by ignoring it.

If you lead an engineering organisation, run the same test inward. Do your developers know which parts of their workflow the tools are for, what the review bar is for machine-drafted output, and what outcome you are tracking? If not, you have mandated activity, and Larridin's line will come for you: activity without value.

The distilled rule I now apply to every AI proposal, on either side of the build, fits in one sentence. Do not ask how many people are using AI; ask which outcomes changed because of it — and if nobody can name the outcome, the proposal is a chatbot wearing a strategy's clothes. Start with the problem, deploy with intent, measure what the intent said would move. Everything else is automation theatre.