When I started as a software developer more than thirty years ago, the numbers that were supposed to matter were lines of code, test coverage, defect density, and code churn. Each was meant to capture something real about the quality of the work and the productivity of the person producing it. What’s more, they had the great merit of being easily countable.

What became clear before long, though, was that they correlated poorly with the only question that truly mattered: Was any of this improving the experience of the people who actually had to use the software I was building? I have found myself thinking about those early measures a great deal lately, because we appear to be in danger of making the same measurement mistakes with AI.

Over the past few months, the surest status symbol in Silicon Valley was not your title or your stock grant. It was how many AI tokens you burned last month. Engineers compared their monthly token counts the way a previous generation compared lines of code or defects fixed. Some firms built internal leaderboards to crown the heaviest users, and a few began treating "token budgets" as a form of compensation. The practice acquired a name, borrowed from the internet: tokenmaxxing. The premise was simple. The more AI you consume, the more productive you must be.

Rather than just dismissing this, I want to take this seriously, because the joke and the warning are the same thing. Tokenmaxxing looks like a curiosity from the engineering fringe. It is in fact, a near perfect illustration of the question hanging over every boardroom this year: Are we actually getting a return on what we spend on AI, or have we simply found a more sophisticated way to mistake activity for value?

When the meter becomes the scoreboard

A token is the basic unit an AI model reads and writes, and every provider meters it because metering is how they bill their users. That makes tokens one of the few things in an AI workflow that can be counted precisely. And there lies the trap.

Goodhart's Law, named for the economist Charles Goodhart, holds that when a measure becomes a target, it stops being a good measure. Token consumption is an input. It tells you how hard the machine worked, not whether the work was any good, whether it survived review, or whether a customer was better served at the end of it. The moment that input becomes a scoreboard, people optimise the scoreboard. They run agents in parallel, pad their prompts, and automate consumption for its own sake. The number goes up. Whether anything of value was produced is a separate question that the metric was never designed to answer.

This is precisely the trap those early code metrics fell into. Lines of code and churn were easy to tally and reassuring to report, yet a developer could push every one of them in the right (or wrong) direction while shipping software that was slower, more brittle, and harder for anyone to use. Tokenmaxxing is that same confusion reborn in a faster and far more expensive form. The meter is more precise than ever, which only strengthens the temptation to mistake it for value.

What the meter is hiding

This matters now because patience with AI is beginning to run out. After several years of experimentation, boards and investors have shifted from asking what AI might do to demanding details of what it has actually returned. The pressure is real, and it is documented: in one large survey, around three in five senior leaders said they felt more pressure to prove a return on AI than they had a year earlier. Research from MIT's NANDA initiative, in its study of AI in business, found that roughly 95% of enterprise GenAI pilots had produced no measurable P&L impact. Similarly, Forrester's analysts have noted that only a small minority of decision-makers can point to a real earnings lift, and fewer than a third can tie AI spending to a change in the bottom line.

The phrase doing the rounds is "AI sticker shock": The ballooning bill arrives long before the proven benefit. The correction is already underway. By late spring, Microsoft had cancelled internal AI coding subscriptions in several divisions over cost, Meta had quietly removed its tokenmaxxing leaderboard, and Uber had admitted to burning through its entire annual token budget in the first four months of the year. The unease is not confined to finance directors, eithe. A Nature Machine Intelligence editorial recently urged firms to stop tokenmaxxing and deploy AI sensibly instead.

Set the two trends side by side and the absurdity becomes clear. At the precise moment finance directors are demanding to see returns, the culture has produced a metric that rewards inflating the cost. ROI is a fraction. Value over spend. Tokenmaxxing optimises the denominator in the wrong direction and calls the result success. It is the ROI crisis in miniature, lived out one leaderboard at a time.

In fairness, there is a serious counter-argument to be considered. Nvidia's Jensen Huang has reportedly said he expects a top engineer to get through around $250,000 of tokens a month, and the optimistic reading is that the returns on this investment are a timing problem rather than an absence. From this perspective, the genuinely valuable agentic workflows are still being built, the heavy consumption today is the necessary investment, and the P&L impact will follow once those systems mature. That may prove partly true. But it is an argument for patient, governed investment with a clear value hypothesis attached. It is not an argument for a leaderboard. The honest version measures what the spending has changed. The vanity version simply measures the spending.

Why Britain should be watching

For a UK audience there is a further dimension. When token consumption becomes the badge of being serious about AI, that consumption flows overwhelmingly to a small number of providers, almost all of them American.

The dependence is not hypothetical: the US "Big Three" of AWS, Microsoft Azure and Google Cloud already supply cloud services to more than 90% of UK public sector organisations, and the AI layer is being built on top of exactly that base. Every token burned for show, rather than for value, is a small transfer of money and capability offshore. The ROI question is usually framed as a corporate one, a matter for a single company's accounts. At national scale it is also a question of sovereignty and of the balance of payments. Uncontrolled, status-driven demand is the opposite of what I have argued we need, which is to consolidate demand so that we understand and shape it, and to diversify supply so that we are never captive to a single meter.

Sovereignty by default does not mean spending less on AI. It means refusing to let spend become a proxy for progress, and insisting that demand is governed, routed intelligently, and spread across meaningful alternatives. A smart buyer asks a different question from the tokenmaxxer. Not "how much did we use", but "what changed, and what did it cost per outcome we actually accepted". That single shift, from input to outcome, is the whole of the argument.

What matters now

So, before the next dashboard lands on your desk, three questions worth asking of your own organisation.

First, where are you already counting activity and quietly hoping it stands in for value? Second, if you replaced "tokens consumed" or "tools adopted" with "cost per accepted outcome", which of your AI initiatives would still look like a success? And third, for those of us thinking about the country and not only the company: if AI spend is becoming a measure of ambition, who exactly is on the receiving end of it, and what are we building here at home in return?

The meter will keep running either way. The only choice is whether we let it tell us a flattering story or insist that it earns its keep.

A government select committee report is not the kind of document most people read for pleasure. It is the kind you read because something in it matters. So, I’ll admit to a particular satisfaction in finding my own argument quoted back at me from the House of Commons, in the Science, Innovation and Technology Committee's first report of this session, Rewiring the state: Delivering digital government, published on 3rd June.

For readers outside the UK, a Commons select committee is a cross-party group of MPs that scrutinises a government department and takes evidence from witnesses before publishing its findings. Its recommendations carry real political weight but no legal force, and the government is obliged to respond, usually within sixty days.

In the chapter on sovereignty, the committee records that "Professor Alan Brown of the University of Exeter has argued that, when it comes to technology procurement, the UK should treat open source and open-weight models as first-class options, with evaluation criteria that credit them for the strategic flexibility they preserve." The footnote points to my Computer Weekly piece, the one whose subtitle is the core message of Making AI Work for Britain: consolidate demand, diversify supply.

The citation is gratifying. But it is not the interesting part. The interesting part is that a cross-party committee, working from its own evidence sessions and its own witnesses, has arrived at almost exactly the diagnosis the book sets out. When the analysis you have been making from the outside starts appearing in the language of parliamentary scrutiny, something has shifted in the centre of gravity of the debate.

What the Committee Actually Said

The report is built on a simple structure: four building blocks that successful digital government requires, and four barriers that currently stand in the way.

The building blocks are money, people, information, data security, and delivery. On each, the verdict is roughly the same. The government has a vision and the beginnings of the right machinery, but it cannot tell you what it spends, cannot get enough skilled people into the roles that matter, has not held itself to the data security standards public trust requires, and has produced a roadmap with no overarching metrics by which delivery can be judged. The committee is blunt about the last of these: publishing the roadmap as an ordinary web page rather than as a formal document laid before Parliament, it notes, conveniently allows the government to revise its commitments quietly, without the alerts that would let anyone hold it to account.

The four barriers are where the report sharpens into an argument. The first is hype. The committee takes the government's own headline claim, drawn from its January 2025 State of digital government review, that digitisation could save £45 billion a year, and calls it "worryingly optimistic", pointing out that the figure rests on an assumption that all routine tasks and a tenth of non-routine ones can be automated. The second is legacy systems, where the central scandal is not cost but ignorance: the government still does not know the full scale of what it is running. The third is vendor lock-in, much discussed in recent years but with little to show for it. The fourth is sovereignty. These last two are where my work sits, and where the committee's conclusions are most striking.

On lock-in, the report names names. Palantir concerns the committee most, and it recommends that the government commit to exercising the February 2027 break clause in the NHS Federated Data Platform contract, the £330 million system that holds and connects patient data, and publish a fully costed exit plan by the end of this year. It wants reasons for the £240 million Ministry of Defence contract awarded to Palantir in December without a competitive tender. It points to Amazon Web Services as the sole bidder for a ten-year, £472 million HMRC contract, and to the Competition and Markets Authority's estimate that Microsoft and AWS together hold between 60 and 80 per cent of the UK cloud infrastructure market.

Its remedy is structural rather than rhetorical: a strategy from the Government Digital Service, the unit at the centre of government charged with digital reform, to end lock-in, with supplier diversification targets reported quarterly; a cloud consumption dashboard that publishes contract values, break clauses and licensing terms; a requirement that public bodies prioritise open-source tools through the planned update to the Procurement Act; and a minimum share of procurement budgets directed to UK start-ups and small and medium-sized firms.

On sovereignty, the committee is equally direct. Reliance on a handful of US providers is, in its words, a strategic and economic vulnerability, one that could see the government's ambitions derailed by a decision taken outside our shores. It wants a working definition of technology sovereignty, reviewed annually, and a strategy with stretching targets for sovereign and open-source alternatives.

The Committee Reached the Same Conclusions as My Book

Strip away the parliamentary tone, and the recommendations are the framework I have been arguing for, almost line by line.

Consolidate demand, diversify supply is precisely what a cloud dashboard plus an all-of-government contract plus supplier diversification targets amounts to: aggregate the buying power, then deliberately spread the risk. The costed exit plan for the FDP is exit-by-design made concrete, the recognition that the time to plan your departure from a supplier is before you are dependent on them, not after. The committee's concerns that the government is "worryingly comfortable" with its dependencies is silent lock-in described from the inside. And treating open source as a first-class procurement option, the specific point for which I am cited, is the smart-buyer model applied to the one decision that determines everything downstream.

This is not a coincidence so much as convergence. The argument I’ve been making has moved from contested to mainstream, and a committee with no particular reason to flatter me has put it on the record.

The Blind Spot in the Report

But there is a critical complication. For all its diagnostic sharpness, the report has the very weakness it identifies in government. It is strong on what and conspicuously lighter on how.

A select committee shines a light. It does not deliver. Its recommendations carry no legal force, and the government's track record on adopting committee recommendations is, to put it gently, mixed. There is a deeper irony, too. The committee rightly criticises the government for a £45 billion figure unsupported by a credible delivery path. Yet a report calling for an exit plan, a sovereignty strategy, a workforce strategy, a legacy taskforce and a re-engineered cloud market, all at once, risks the same charge it levels at others: an ambitious destination with no costed route. The committee even warns, quoting its own witnesses, against the temptation to "boil the ocean". The recommendations, taken together, come close to asking the government to do exactly that.

So, the right response is neither triumph nor cynicism. The diagnosis is now a consensus, which is real progress and was not true even two years ago. The open question is the one my book keeps returning to, and the one I summarised after reviewing the government's record against my own 25 recommendations: vigorous activity, but no completion.

The work that matters now is not making the case. That case is increasingly won. It is building the delivery discipline, the metrics, and the follow-through that turn a sound diagnosis into a working state. That is harder, less glamorous, and far easier to abandon when the next priority arrives.

For digital leaders, this raises an important question: When the government responds to this report, as it must and conventionally does within about sixty days, what would count as evidence that it has accepted the diagnosis rather than merely acknowledged it?

My own answer is simple: a costed FDP exit plan by December, and a sovereignty definition you can actually hold a department to. I will be watching for both and tracking them on UK AI Watch. I hope you’ll be watching too.

How many AI and algorithmic systems are in use across the UK's central government? According to the government's own mandated transparency register, the answer is 131. That’s not an estimate, not a survey response, but the official record of every algorithmic tool that central departments have declared. The UK government has reported that it met its commitment to publish them all by the end of 2025.

Can that be true? It cannot, and the distance between that number and the reality needs to be explored.

When I worked on the National Audit Office's 2024 study of AI in UK government, our survey of 87 government bodies identified 74 AI use cases already deployed across departments and arm's-length bodies. That was autumn 2023, before the AI Opportunities Action Plan and before the current surge in adoption. If 87 bodies were already running 74 tools more than two years ago, a register today listing 131 across the whole of central government is not a measure of how much AI government uses. It is a measure of how much AI government departments are willing to write down. That 2023 count was itself conservative: the NAO survey deliberately excluded AI embedded by default in existing software and the ad-hoc use of public tools by individual civil servants, the very categories that have grown fastest since.

What the Register Shows

If you read through the register, the typical record is a calculator. Pension calculator. Budget planner. Mortgage repayment calculator. Interest calculator. Or perhaps a chatbot: Ask HMRC online, DVLA Contact Centre chatbot, GOV.UK Chat. Then an identity verification tool. Then a variety of dashboards such as a similar-schools clustering tool used for attendance reporting.

These are useful tools and worth publishing. They are also, almost without exception, the safest things to publish. A calculator that estimates your mortgage repayments is deterministic, low-risk and politically uncontroversial. A chatbot that surfaces existing guidance pages is really helpful and easy to defend. Publishing a transparency record is easy and quick.

What you will struggle to find in the register is the harder category. Tools that triage benefit claims for fraud signals. Tools that score immigration applications. Tools that prioritise tax investigations. Tools that assist police forces in risk assessment. These exist, and receive a great deal of comment. Other trackers, such as the Public Law Project's independent Tracking Automated Government register, identify a number of them. Most are not on the ATRS, either because they are explicitly exempt under the December 2024 scope and exemptions policy, because they sit just outside the in-scope organisations, or because no one has yet been compelled to declare them.

Unfortunately, a transparency register that operates only where the stakes are low is not offering a very meaningful picture of AI use in the UK public sector.

The AI Accountability Puzzle

The trajectory tells its own story. The ATRS became mandatory for central departments in February 2024. Through most of that year the register barely moved. By summer 2024 it held 9 records, and 23 by the end of the year. The compliance survey published alongside the NAO report found that 38 per cent of responding bodies reported never complying with the standard.

Then in January 2025 the Public Accounts Committee called in the Permanent Secretary at DSIT to give evidence and asked her directly why only 33 records had been published. Within twelve weeks the count had nearly doubled. By year end, against a public commitment to publish every in-scope tool by the end of 2025, it had reached approximately 125. The lesson is uncomfortably familiar. The mandate, as a piece of policy, did very little. What moved the needle was the prospect of being named in a select committee report.

This is not a particularly unusual finding. Soft policy mechanisms rarely change institutional behaviour without a clear tracking approach supported by a meaningful enforcement function. But it does suggest something specific about the architecture of AI accountability in the UK. If transparency relies on individual select committees noticing a problem in time to ask about it, the system has no general purpose mechanism for keeping pace with deployment. AI is being adopted faster than parliamentary scrutiny can be organised around it.

The Denominator is Unknown by Design

As a result, we don’t currently know how many algorithmic tools the UK public sector uses today. The UK government can declare the register complete only because it decides what counts as in scope. The current scope policy excludes a great deal: national security applications, broad analytical work, tools that affect "groups" rather than identifiable individuals, and more.

It also has no answer for the AI that is now arriving inside every commodity productivity tool the civil service procures. When a department buys Microsoft 365 with Copilot built in, no transparency record gets filed, even though every drafted email, summarised meeting and triaged inbox is shaped by an algorithmic system. Nor does it capture the shadow estate: the consumer tools civil servants reach for without sanction. A Microsoft survey of more than 2,000 UK workers found that 71 per cent had used unapproved AI at work, and there is no reason to assume Whitehall is the exception. The difference is that no one is counting how often it happens inside government, or what citizen data goes with it.

An effective public sector AI transparency regime would begin somewhere different. It would start with an independent inventory of deployed tools, conducted to a consistent definition, and use the register to make sense of that inventory rather than to constitute it. This is what we can see in other places. Amsterdam and Helsinki pioneered registers built from the systems their own administrations actually ran, and a shared transparency standard followed from that practice rather than preceding it. The Netherlands extended the same approach to national level, where the data protection authority is only now pressing for registration to become a legal requirement. The UK has gone the other way around, declaring the standard first and then hoping departments would follow.

Seeing is Believing

Want to see more on the UK government’s AI register? To offer greater insight and make this more concrete, I have published an interactive tracker that pulls every ATRS record live from GOV.UK, categorises them by tool type, and lets anyone browse, filter, and search the register. You can find it at futureofai.uk/atrs-tracker.html. It is not a replacement for the official register. It is meant as a critical companion to it. Take a look and let me know what you think.

If you work in or with the public sector, two questions are worth taking back to your own organisation. First, how many algorithmic tools is your organisation using, including the ones bundled inside the commercial software you have already paid for? Second, who in your organisation would notice if the answer to that question started to climb sharply?

A transparency standard that cannot answer those two questions is not yet doing the job it was built for.

Last week I wrote about Katrina Manson's Project Maven, the inside story of how a small team in a windowless Pentagon room set out in 2017 to put AI at the heart of how America fights its wars. It is a serious piece of reporting, drawn from more than two hundred interviews, and reviewers from The Economist to the New York Times have rightly placed it among the most important recent books on AI and conflict. But the more I consider it, the more I am struck by how the experiences described reveal important success factors for every leader as they seek to deliver AI-driven transformation.

Strip out the descriptions of targeting algorithms, drone footage, and rooms full of intelligence analysts, and what remains is a case study every digital leader will recognise. A small team trying to drag a vast organisation into a different way of working. A technology that promised more than it could initially deliver. Bureaucracy that fought back. Talent that came and went. A long argument about ethics that no one wanted to have but everyone had to. The names and the stakes differ from anything most of us work on, but the patterns will feel familiar to anyone who has tried to push a serious AI programme through a complex organisation.

There are seven lessons I think are worth pulling out.

1. Leadership sometimes means defying the system you serve

Manson's protagonist, Marine Corps Colonel Drew Cukor, was given a mandate by Deputy Defense Secretary Bob Work in the April 2017 memo establishing the Algorithmic Warfare Cross-Functional Team, but very little authority to deliver it. What Cukor and his small team had instead was focus, energy, and a refusal to accept that the Pentagon's procurement cycle, security culture, and turf wars were immovable. At several points their actions bordered on insubordination. The book makes clear this was not heroism for its own sake. It was the only way to get the work done in the timescales that mattered.

The lesson for digital leaders is not "break the rules". It is that real AI delivery requires people willing to apply judgement against the grain of the organisation, and must include senior-level cover for such actions when they do. Most large enterprises and public bodies have no shortage of governance. What they lack is the small number of leaders prepared to push, with purpose, against settled assumptions.

2. The data problem is rarely the data problem you expect

The single biggest constraint on Project Maven was not algorithms. It was data: too little of it, badly labelled, locked up by classification rules, and contested between agencies. Manson told NPR that the early Project Maven models had been trained on images of wedding cakes, bridal veils, and grooms' suits before being repurposed for the battlefield, where they confused trees for people and a cloud for a school bus. Cukor himself said his AI was, in those early days, "just a bag of potato chips" to operators.

Anyone who has run an enterprise AI programme will recognise this. The hard work is not picking a model. It is finding data that is current, representative, and legally usable, then labelling it properly, then negotiating who is allowed to share what with whom. Privacy, ownership, and rights are not back-office issues that the lawyers will sort out later. They are first-order design constraints. Treating them as such early saves months of rework, and a great deal of avoidable embarrassment, later.

3. Experiment at the scale the problem requires

One detail in the book has stayed with me. The Project Maven team would, at peak, test more than 1,500 algorithms in order to deploy fewer than a dozen of them. That ratio is worth considering. It is not the typical organisational picture of AI: pick a model, prove a pilot, scale it up. It is closer to drug discovery. Most things you try will not work. Some will work, but not well enough. A small number will earn their place in production.

Most organisations are nowhere near set up for this. They run a handful of carefully curated pilots, almost all of which are declared successful, and then wonder why so little reaches the front line. The infrastructure question for the next phase of enterprise AI is not "do we have a platform". It is whether the organisation can afford, financially and culturally, to throw away ninety-nine per cent of what it builds. Without that capacity, pilot purgatory is more or less guaranteed.

4. The model is not the system

Perhaps the most important sentence in Manson's account of why Project Maven eventually started to work is the one that names three things, not one: the quality of the underlying data, the system in which the algorithm sat, and the smoothness of the workflow the operators could build around it. None of those was sufficient on its own. All three had to come together.

This matters because too many AI conversations in business and government still reduce to a debate about models. Which foundation model? Which vendor? Which open-source variant? Those choices matter, but they matter least. What changes outcomes is whether the model is embedded in a system that fits the workflow of the people using it, fed by data they can trust, in a form they can act on. AI value is a property of systems, not algorithms.

5. The vendor relationship is itself a strategic risk

A second-order story runs through Manson's book alongside the Pentagon's internal one: how a handful of private companies, most prominently Palantir and Amazon Web Services, alongside Microsoft, Anduril and others, became indispensable to a national security capability. Project Maven did not just buy algorithms from these firms. It built workflows around them, trained its people on their interfaces, and made operational decisions inside their environments. Palantir's growth in particular was supercharged by the engagement, and the company's commercial posture was anything but passive.

That dependency carries three risks every digital leader will recognise. The first is alignment: how tightly do you want your strategy and your data coupled to a single supplier? The second is commercial: aggressive vendors will press their advantage at renewal. The third, easily missed, is bias, not only in the algorithms but in the framing each vendor brings to what AI is for and how it should be used. Buying from a vendor is also buying into their worldview.

This is where "consolidate demand, diversify supply" earns its place. Concentrating buying power gives an organisation leverage. Concentrating supply takes it away. The lesson from Project Maven is not to avoid commercial partners, which is neither possible nor desirable. It is to design the relationship deliberately, with exit-by-design, multiple credible sources, and a clear-eyed view of who is the buyer and who is the seller.

6. Persistence is a core competency

Project Maven survived a presidential transition, a public revolt by Google employees that ended the company's involvement in 2018, multiple changes of leadership, sustained turf wars between agencies, and several rounds of internal political opposition. It also survived a great deal of personal animosity inside its own team. None of that is unusual. What is unusual is that the project kept going long enough to deliver anything.

Persistence is unfashionable as a leadership virtue. It is harder to put on a CV than "transformation", and harder to talk about on stage than "vision". But Manson's account is, more than anything else, the story of a programme that refused to die. The implication for digital leaders is uncomfortable. Many of the most important AI initiatives in your organisation will not succeed in their first form, their first business case, or under their first sponsor. The question is whether they have the kind of patient backing that lets them get to the second, third, and beyond.

7. "Human in the loop" can quietly become "human on the loop"

The most uncomfortable thread in Manson's book is the one that runs through its final chapters. Project Maven has always insisted that it does not pull the trigger. Its job is to identify possible targets in surveillance footage, sort them, rank them, and pass them to a human operator who decides what happens next. That distinction, between an AI that recommends and a human who decides, has been the public ethical bedrock of the programme since its founding.

But Manson's reporting makes that line look much less stable than it sounds. When the system delivers a prioritised list of targets with precise coordinates, ready to be fed into a weapons system, and when the operator works under time pressure to act on what the system surfaces, what kind of decision is the human actually making? At what point does "human in the loop", actively choosing, become "human on the loop", rubber-stamping what the machine has already framed?

This is not a question confined to military AI. Every digital leader running a system that ranks candidates for hiring, flags transactions for review, or prioritises cases for casework will recognise the same tension. The system does not decide. The system suggests. But if the human accepts the suggestion in case after case, who is really in charge? Project Maven forces the question into the open in the most uncomfortable possible setting. The work for the rest of us is to ask it of our own systems before someone else does.

Where this leaves us

Project Maven continues to evolve, now housed at the National Geospatial-Intelligence Agency. And the ethical questions Manson's book raises about lethal autonomy are real and unresolved. But for digital leaders trying to make AI work in their own organisations, the more useful reading is as a case study in delivery: how a small team, with weak formal authority, built something the wider system did not know how to build for itself, and kept building it long after the initial enthusiasm had faded.

This is not the book I thought I would be reading. Not by a long way. When I picked up Katrina Manson's Project Maven, I was expecting a rather dry, technological review of AI applied to military applications and an analysis of the lessons learned about technology adoption. Instead, what I found was over 300 pages of something that reads more like an episode of “Yes, Minister” than an edition of “Tomorrow's World”. It lays out in compelling detail why AI adoption is yet another example of that well-known adage: 1% inspiration, 99% perspiration. In this case, the effort involved convincing the US military establishment that it had to wake from its institutional slumber and revolutionise. Fast.

The Team in the Basement

Katrina Manson’s book tells the story of how, in 2017, Colonel Drew Cukor gathered a small team inside a windowless Pentagon room with a mandate most of his colleagues considered either impossible or undesirable: put artificial intelligence at the heart of how America fights wars. Cukor was not a Silicon Valley evangelist. He was a Marine Corps officer who had experienced the deaths of several colleagues and was convinced that an AI-equipped China was closing the gap with American capability faster than anyone in the military wanted to admit. His response was to behave like a startup founder inside one of the most bureaucratic institutions on earth.

What followed, as Manson documents through more than 200 interviews with insiders and opponents, was not a smooth technology deployment. It was a decade-long battle of wills, budgets, procurement rules, ethical objections, and competing interests. The Maven team fought with Pentagon bureaucrats and each other. They enlisted a reluctant Silicon Valley and triggered a revolt among thousands of Google employees who refused to have their work used in targeting algorithms. They brought in Palantir, Amazon, Microsoft, and others to field AI systems in live combat zones. They learned, often painfully, where AI fails.

A Story about Institutions, Not Algorithms

Manson is a Bloomberg reporter and former Financial Times correspondent who covered US foreign policy and defence. She writes with the confidence of someone who has spent years watching powerful institutions resist the very changes they publicly claim to want. The result is a book that is, at its core, not really about AI at all. It is about institutional change: how organisations convince themselves that transformation is urgent while doing everything possible to prevent it.

The pattern will be familiar to anyone who has watched the UK's public and private sectors grapple with AI adoption over the past decade. The technology is rarely the limiting factor. The limits are structural: procurement systems built for a different era, risk cultures that reward caution over capability, leadership teams with the authority to commission pilots but not the appetite to scale them. Project Maven had impact not because the AI was perfect, it frequently was not, but because Cukor and his team refused to treat the organisation's resistance as a reason to stop. They treated it as the problem to be solved. And were relentless about it.

Find. Fix. Finish.

The phrase comes from military targeting doctrine, and it organises much of what Project Maven was trying to do. Find the target. Fix its position. Finish the job. As a framework for thinking about AI adoption more broadly, it is uncomfortably precise.

Find

Britain has never had a problem with this step. We have more pilots, proofs-of-concept, and AI research projects than most comparable economies. The NHS, HMRC, local government: each has its collection of AI experiments, many of them technically impressive. Project Maven started here too. The initial brief was to use computer vision to analyse video footage from military drones, processing at a speed and scale no human team could match. The technology worked. That, in the end, was found to be the easy part.

Fix

The harder step was fixing the institutional conditions that would allow the technology to move from experiment to operation. For Project Maven, that meant creating a demand signal strong enough to bring Silicon Valley off the fence, building procurement routes that could actually accommodate AI vendors, and persuading a chain of command that deploying systems whose decisions they could not always explain was a risk worth accepting. Cukor spent years on this step. The Pentagon's bureaucracy pushed back at every turn. Most organisations never seriously attempt it; they mistake running another pilot for making progress.

Finish

Project Maven did eventually finish. Today, its AI-enabled systems operate in every branch of the US military. But Manson is careful not to make this feel like a triumph. Finishing, in the Project Maven sense, meant accepting that the AI was imperfect, that it would make mistakes, and that the organisation had to build the internal capacity to understand, oversee, and challenge what it had deployed. That is the smart-buyer model in its most demanding form: not passive consumption of capability, but active stewardship of it.

The one recurring obstacle in Manson's account, appearing at almost every stage of the story, was data. Not the absence of it. The US military generates more data than almost any organisation on earth. The problem was making it usable. Finding relevant datasets scattered across siloed systems. Securing permission to use footage and intelligence records carrying their own legal and classification constraints. Labelling thousands of images so that algorithms could learn to distinguish a vehicle from rubble, a person from a shadow. Applying those labelled datasets to real-world conditions that never quite matched the training environment.

Each of these was a solvable problem. None of them was a technology problem. They were organisational, legal, and human problems dressed in technical clothing. Anyone who has tried to build an AI system inside a large UK public body or private company will recognise every line of that.

What cut through, ultimately, was a refusal to wait for conditions to become comfortable. The Project Maven team went where the problems were hardest and stayed until something worked. They embedded with operational units, deployed imperfect systems, and iterated in the field rather than holding out for certainty that the lab would never deliver. They bent rules. They circumvented procurement timelines. On occasion, they acted first and sought permission afterwards. This was not recklessness. It was a deliberate choice to treat inaction as the greater risk.

The organising principle throughout was value creation, and the speed at which it could be demonstrated to sceptics who needed to see a system working in conditions they recognised before they would commit. That principle, at least, requires no adaptation before it travels. But it is not the only universal lesson we should be taking away.

Project Mason’s Lessons for the UK

The Project Maven story is an American one, shaped by American institutions, American procurement culture, and the particular urgency that comes from facing a near-peer military adversary in China. It would be easy to conclude that its lessons do not travel. I don’t think that’s right.

The structural challenge Cukor faced, convincing an established institution that it needed to change faster than its own processes allowed, is not uniquely military, nor uniquely American. It is the challenge facing every public body and large private organisation in the UK that is trying to move AI from the edges of the organisation to its operating core. The UK is exceptionally good at Find. It has a patchy record on Fix. It rarely gets to Finish. The result is what I have elsewhere called pilot purgatory: technically interesting, strategically irrelevant.

In Making AI Work for Britain, I make a simple argument that the answer lies in consolidating demand and diversifying supply: creating the institutional structures that send a clear, sustained signal to the market while simultaneously opening the supply side to genuine competition.

The US Department of Defense did not approach AI vendors with a list of discrete departmental requirements. It created a focal point, a programme, a mandate, around which commercial capability could coalesce. That is how you get from Find to Finish. Project Maven, for all its controversy and its contexts that many will rightly find troubling, is one of the most instructive case studies available in what that actually looks like. It is also a reminder that AI success at scale requires so much more than the algorithms.

There is something disconcerting about picking up a book you wrote twelve years ago. Thumbing through the pages and remembering what you were thinking, feeling and experiencing over a decade ago. Not because much of what you’re reading is wrong, but because a lot of it still rings so true!

In 2014, Mark Thompson, Jerry Fishenden, and I published Digitizing Government with an argument centred on what we called "government-as-platform". The thesis was that government should stop building bespoke systems for every function and start creating shared digital infrastructure — common components, open standards, reusable services — on which departments and citizens could build. The language was technological, but the underlying logic was structural: the problem was not that government lacked good technology, but that it kept buying the same capabilities repeatedly, in isolation, at great expense, with no shared foundation beneath any of it.

Looking back now, that argument is recognisably the same one I make in Making AI Work for Britain under a different name. "Consolidate demand, diversify supply" is what government-as-platform was really saying, expressed in terms of market structure rather than architecture. We did not quite see it in those terms at the time. The platform framing felt primarily like a technical proposition about APIs, shared components, and interoperability. The buyer-side logic, the idea that organised demand fundamentally changes what markets deliver, was present in the argument but not yet a primary focus. A decade of watching the same structural failures repeat themselves, now in AI, has made that underlying point considerably harder to miss.

Next Tuesday, Mark and I will revisit that argument at a University of Exeter online event. We’ll be looking back at what Digitizing Government got right, what the decade since has taught us, and what it means now that AI has entered the picture. You can sign up here.

What GDS got right

The Government Digital Service, established in 2011 and gathering real momentum by the time our book appeared, represented something important and different. Not just better technology or more modern design, though it delivered both. Its real innovation was structural: it consolidated demand across government before it opened the door to competing suppliers. Common platforms, shared standards, spend controls, and a clear mandate meant that, for a period, government bought differently. The market had to respond to organised demand rather than exploit fragmented procurement.

The results were visible. GOV.UK replaced hundreds of departmental websites with a single coherent user experience. The Digital Marketplace changed how smaller suppliers could compete. The Government Design Principles gave hundreds of teams a shared framework for what good looked like. None of this happened because government discovered better technology. It happened because it briefly acted as a coordinated buyer.

The difficult decade that followed

What went wrong is harder to summarise, because it happened gradually. But in retrospect, the cumulative effect is clear. The spending controls relaxed. The mandate weakened. Departments reasserted their independence. The market, which had adapted to GDS-era discipline, adapted back again. By the early 2020s, the fragmentation that Digitizing Government had diagnosed was largely back in place. The GOV.UK infrastructure endured, and pockets of strong practice remained. But the structural discipline that had made GDS work did not become self-sustaining. It had depended on institutional will, and institutional will is always provisional. (Particularly when it is continually at odds with the “administrative won’t”).

However, this is not a matter for despair. The GDS era demonstrated what is possible and produced a generation of digital leaders who understand what good government technology looks like. The question is whether the conditions for their impact can be created again.

Déjà vu all over again

When AI arrived in Whitehall and in boardrooms across Britain, I was really hoping to see many of those lessons applied. Instead, I watched the same structural errors repeat themselves. Organisations launched dozens of disconnected pilots before anyone had agreed on priorities. Procurement reverted to established relationships rather than open markets. Accountability for outcomes was diffuse. Suppliers shaped the agenda more than buyers did.

The terminology may have changed. "Digital transformation" has become "AI adoption." The pattern of failure did not.

The reason is not ignorance or bad faith. It is that the underlying incentive structures were never reformed. Digital technology adoption was detached from policy evolution. Each department, each directorate, each agency still has its own budget, its own relationships and its own definition of success. Consolidating demand requires someone with the authority and the will to act across those boundaries. In the absence of that, the default is fragmentation.

Consolidate demand, diversify supply

This is why I felt compelled to write Making AI Work for Britain. It is the argument at the heart of the book, and it owes a direct debt to the GDS experience. The lesson of the digital decade is not that government cannot innovate. Quite the contrary. It is that innovation without structural discipline produces pilots without programmes and activity without progress. Too many ideas and too much investment were wasted. And we’re in danger of seeing the same thing happen in the UK with AI.

"Consolidate demand, diversify supply" is not a slogan. It is a description of the conditions under which markets behave in the public interest. When buyers act together, suppliers compete on merit. When buyers act in isolation, suppliers exploit the asymmetry. The GDS model worked when it had the force of political will and structural alignment applied to that principle. Delivering on the UK’s AI strategy will only work when it does the same.

That means common frameworks for AI procurement, shared evaluation standards, and coordinated investment decisions across departments rather than parallel and competing ones. It means acting as a smart buyer rather than a collection of individual customers. None of this is technically overwhelming. Making it happen institutionally is a different matter entirely.

A conversation worth having

When Mark and I discuss Digitizing Government on Tuesday, we will not be indulging in nostalgia. We will be asking a practical question: what did the experiences of a decade of digital transformation teach us about how institutions change, and what does it mean for the choices facing the UK’s AI adoption in government and business right now?

And I will leave you with the question I am sitting with as I prepare for Tuesday:

A new study, supported by AWS, exploring the state of AI adoption in the UK was published last week. The temptation, when reading the AWS adoption numbers, is to feel reasonably good. Britain is ahead of others in Europe. Adoption is rising. The productivity gains are real. These advances should be celebrated. But the report's most important finding is not in its headline figures. It is in the gap they conceal, and how we address that gap is critical to the UK’s future.

A Baseline for Understanding AI in the UK

The AWS report’s headline finding is that AI adoption in the UK has reached 64% of organisations, up from 52% a year ago. Britain is now ten percentage points ahead of the European average. The productivity benefits, for those who have committed, are real: 68% report gains, 72% expect AI to drive growth in the coming year, 79% say their innovation timelines have accelerated. These are not trivial numbers, and the report is right to lead with them.

But the most arresting figure in the document is a date: 2102. That is the year by which every UK adopter will reach the most advanced stage of AI use if progress continues at its current pace. That’s right. So, while AI adoption has surged, advanced use that rewires how organisations operate has barely moved from 23% to 24% in twelve months. The problem is that the £35 billion productivity opportunity AWS identifies sits behind that 24% number, not the 64% one.

Viewed in this way, the AWS diagnosis tracks closely with the book’s argument. Britain’s danger is mistaking the appearance of transformation for its substance. Upgrading to Microsoft Copilot or buying ChatGPT licences across the workforce is all very well. But it is an adoption metric. It is not an AI strategy. The gap between adoption and advanced use is not a pacing problem to be solved by installing more licenses. It is a structural problem about how organisations procure, deploy, and integrate AI to improve today’s way of working.

Two findings in the report reinforce the book’s central argument, especially directly. The first is that 78% of organisations say they are more likely to adopt AI if the public sector integrates it into its own services. The second is the public sector itself: 31% of public adopters now sit at the most advanced stage of use, against 24% across UK businesses overall. Where the government has gone, it has gone deeper. This is the empirical case for what the book describes as consolidating demand. Government adoption is not just about better services. It shapes the market for everyone else. The 35% of UK startups citing public sector demand as a top scaling factor closes the loop from the supply side.

What the Report Does Not Say

Where the AWS report and the book part company is on the supply side. AWS’s three recommendations are entirely demand-side: move from adoption to transformation, scale AI across public services, and close the skills gap. All sensible. None of them asks who supplies the AI that Britain is being encouraged to adopt more deeply.

This is not a failing of the research. It is a function of who commissioned it. An AWS report is not the place to interrogate hyperscaler concentration. But the report’s own data raises the question. 98% of UK AI startups now build on the cloud, and the report presents this as a clear strength. The book asks a harder question. An AI economy built almost entirely on three or four foreign cloud stacks is a different proposition from one with a diverse supply. The £35 billion is meaningful for British GDP whether it accrues to British firms or to American platforms running British workloads. For headline output, those are the same thing. For strategic capability and fiscal sovereignty, they are not.

This is the silent lock-in the book takes seriously. It is not announced. It is built up incrementally, through routine technical decisions, until the cost of unwinding it exceeds the political capital available to do so. The AWS report frames cloud as table stakes. The book argues that the architectural decisions made at the bottom of the stack determine the strategic options available at the top, and that getting them right is something Britain has done before, in a different domain, within living memory. Anyone who lived through the GDS years will recognise the pattern.

The AI Skills Need

The third place where the book pushes further is on skills. The AWS report’s analysis is detailed: 49% of organisations cite skills shortages, hiring timelines have stretched from 5.5 to 8 months in a single year, and organisations are paying an average 41% salary premium for strong AI capability. All of this is correct, and all of it is workforce-framed. The skills problem is presented as workers needing to learn AI tools.

The harder skills gap sits upstream. The most consequential AI capability gap in Britain is not down at the desk level. It is up in senior leadership and procurement: the people deciding what to buy, from whom, on what terms, and with what exit options. A workforce trained on a particular vendor’s stack but unable to evaluate the strategic implications of building on that stack has not solved the problem. It has shifted it upstream and made it harder to see. The smart-buyer skills, the ones the state and large organisations need most, are not in the AWS skills count.

Delivering on the UK’s AI Future

Read together, the AWS report and Making AI Work for Britain are stronger than either alone. The report makes the empirical case that Britain has a problem worth solving. The book makes the structural case for how to solve it. Where the report says scale faster, the book asks scale toward what.

The question I would put to any senior leader reading the AWS numbers this week is the one the report itself does not quite ask. It is not whether to adopt more AI. It is whether your adoption is taking you somewhere you actually want to go, on terms you would accept if you were buying a building or signing a twenty-year lease.

Adoption is the easy part. The architectural choices underneath it are what will matter in five years.

For long stretches of 2025, I thought I’d made a mistake. I wasn't certain the book I was writing had a compelling argument.

The material was there. Drafts, notes, case studies, whitepapers, commissioned pieces for the Digital Policy Alliance and Digital Leaders Network, and a running conversation with senior leaders across government, finance, and industry about what AI was actually doing in their organisations rather than what it was supposed to be doing. All of it pointed somewhere. None of it pointed cleanly to a single book.

That changed over the course of early 2026. Not because I found the missing chapter or cracked the structural problem in a moment of inspiration. The change came from outside the manuscript. Four forces converged in the first months of this year, and between them they pulled what had been a collection of observations into a single, recognisable shape.

The technology got serious, fast

The first force was technical. Through late 2025 and into 2026, the frontier moved at a pace that made the earlier discussion of "AI readiness" feel like a hypothetical. Recursive self-improvement left the lab. Agentic systems stopped being a research curiosity and became a procurement question. By the time Anthropic publicly held back a model it judged too capable for public release, the conversation in boardrooms had shifted from whether to adopt AI to how fast AI tools could be acquired, and how to do it safely. A book written in the language of experimentation and pilots was suddenly speaking to a world where the technology was no longer the issue.

The geopolitics hardened

The second force was geopolitical. The launch of the Sovereign AI Fund, the £31 billion US–UK Tech Prosperity Deal, and the quiet scramble across European capitals to define national positions on compute, chips, and model sovereignty. What had been an abstract discussion about "British AI" a year earlier became a concrete conversation about supply chains, foreign dependencies, and the kinds of technological choices that countries cannot unmake. The argument I had been trying to make about institutional capability now had a harder frame around it. Sovereignty was no longer a rhetorical flourish. It was a policy agenda with budget lines.

The jobs conversation became real

The third force was economic. For most of the previous two years, discussion of AI and work had been dominated by speculative numbers: percentages of tasks automatable, sectors exposed, and futures imagined. By spring 2026 the conversation had narrowed. Specific roles were being reshaped or removed, specific firms were restructuring, and the financial impact on individual organisations had become measurable. By mid-April, roughly half of UK executives believed AI would reduce overall employment in Britain over the coming decade. That shift mattered for the book because it meant the argument I had been making about AI as an institutional question, not a technical one, stopped requiring defence. The evidence was arriving weekly.

The strategy-to-delivery gap started to bite

The fourth force was political and institutional. Through 2025, the UK had settled into a pattern of ambitious AI strategy announcements that were not matched by delivery capability. By early 2026, that gap had become the dominant story, whether in the Chancellor's "fastest AI adoption in the G7" pledge, the one-year review of the AI Opportunities Action Plan, or the various sectoral initiatives that promised transformation and delivered studies. This was the terrain I had been writing about all along. The difference was that by 2026 it was no longer a minority view. It was the question the sector was asking itself.

Why 2026 is special

When these four forces arrived together, the book's argument stopped being something I was trying to construct and became something I was trying to keep up with. The five reforms at the heart of Making AI Work for Britain (a smart-buyer function for the state, board-level accountability in organisations, a consolidated demand side coupled with a diversified supply side, clearer institutional ownership of AI outcomes, and a delivery-first rather than strategy-first operating model) did not come from a single moment of clarity. They came from watching what the technology, the geopolitics, the economics, and the politics were each, independently, pushing towards.

What did I get wrong along the way? More than one thing, but the honest answer is that I underestimated how quickly the conversation would shift from whether AI would matter institutionally to how it would. The book I completed is less about persuading readers that the institutional question is the central one, and more about giving them a working vocabulary for acting on it. That is a better book than the one I set out to write, and the reason it is a better book is that the conversation is finally ready to have it.

While there were times I had my doubts, I am now convinced that the convergence of these four forces is, in the end, good news for Britain. An institutional problem is a solvable problem. The UK has built institutional capability of exactly this kind before, most visibly with the Government Digital Service fifteen years ago, and the lessons from that work are not lost. The technology has raised the stakes. The geopolitics has sharpened the choices. The labour market has made the costs of delay concrete. The delivery gap is now an accepted fact rather than a contested claim.

Britain does not have to invent its way out of this. It has to organise its way out.

That is a far better starting position than the one the country had a year ago.

Making AI Work for Britain is published by London Publishing Partnership on Tuesday. Whatever its strengths and its flaws, it is a product of the moment it was written in, and I am grateful to the readers of these Dispatches for thinking it through alongside me.

The path to make AI work for Britain is in focus. The answer is within reach. Britain has the talent, the institutions, and now the clarity to make AI deliver for the country. It is time to get on with it.

Find more details of the book at FutureOfAI.uk. And let me know what you think.

Writing a book is a strange experience. You spend months making an argument by assembling evidence, testing the logic, and sharpening the language, only to find that somewhere in the middle of it all, a quiet doubt settles in. Not about whether the argument is right, but about whether it will matter. Whether the moment will catch up with the manuscript. Whether anyone cares. Whether the urgency and passion you feel as you write it will be evident to someone reading it six months later.

I have spent the better part of the past year making the case that the UK's AI challenge is not primarily a technology problem. It is an institutional one. The gap between what AI can do and what Britain is organised to do with it is widening at a pace that our current governance structures are not equipped to match. And I will admit that, as the final proofs went back to my publisher, I wondered whether events might prove me either too pessimistic or too late.

In the past few weeks, I’ve stopped wondering. The story of Anthropic's Mythos model has brought the argument into sharper focus than anything I could have written.

A Model Too Powerful to Release?

One evening in February, an Anthropic researcher sitting at a laptop in Bali set out to test the company's most powerful AI model. What he found stopped him in his tracks. The model, now known as Mythos, had autonomously identified and exploited a 17-year-old vulnerability in a widely used operating system. No human was involved after the initial instruction. The model found the flaw, built the exploit, and demonstrated how an attacker could take complete control of any server running the software from anywhere on the internet.

Anthropic has since confirmed that Mythos identified thousands of previously unknown vulnerabilities across every major operating system and web browser. It has not released the model publicly and doesn’t plan to. Instead, it has made a limited preview available to a small group of technology and security partners, including Amazon, Apple, Cisco, Microsoft, and Palo Alto Networks, under a new initiative called Project Glasswing, with the explicit goal of helping defenders secure critical systems before models with similar capabilities become more widely available.

Today’s Deeper AI Dilemma

It would be easy to read the Mythos story as a cautionary tale about a single unusually powerful model that a responsible company chose not to release. That framing is too narrow. What Mythos illustrates is that we have entered a phase in AI development where the gap between what is technically possible and what society is institutionally prepared to handle is widening at pace.

Anthropic's own frontier red team report describes Mythos as having "improved to the extent that it mostly saturates" existing cybersecurity benchmarks. That is a remarkable statement. It means the standard tools we have developed to measure and govern AI capability in this domain are already insufficient. The model has moved beyond the frame we built to contain it.

Anthropic's decision to restrict Mythos and invest in defensive deployment is a serious and responsible response. Project Glasswing commits up to $100 million in usage credits to help defenders get ahead of the threat. The fact that a frontier AI company identified the risk, disclosed it, and coordinated a response is, on balance, a positive signal about how the industry can behave.

But there is a much harder question. Project Glasswing is a private sector consortium, coordinated by a US company, working primarily with US technology partners. The UK government is not a named participant. UK critical infrastructure operators are not listed among the forty organisations with access to the Mythos preview. At the precise moment when AI capability has crossed a threshold that, in Anthropic's own words, "fundamentally changes the urgency required to protect critical infrastructure", Britain is largely on the outside looking in.

The UK Sovereignty Question in Focus

The week that Mythos became public knowledge, the government announced its response to exactly this kind of challenge. On 16th April, Technology Secretary Liz Kendall launched the £500 million Sovereign AI Unit at Wayve's King's Cross headquarters, describing it as "one of the single most important things this government will do for the future of this country". The fund will invest in British AI startups, provide access to supercomputing infrastructure, fast-track visas for global talent, and help portfolio companies win government contracts.

It is a serious initiative, and it deserves a serious welcome. But notice what it does and does not address. It backs the supply side: building British AI companies, securing compute capacity, and attracting talent. What it does not do is build the demand-side coordination architecture that would allow the UK to respond institutionally when a capability threshold is crossed. There was no mention of a standing mechanism for assessing threats to critical infrastructure. No procurement framework to give UK operators rapid access to defensive AI tools. No answer to the question of who coordinates the national response next time a Mythos-class model emerges. And we all know there will be a next time.

The irony is startling. The Sovereign AI Unit was launched on the same day that OpenAI quietly paused its Stargate UK data centre project, citing energy costs and the regulatory environment. Britain is announcing a fund to build sovereign AI capability at the precise moment the world's most prominent AI company has signalled that the conditions for large-scale AI infrastructure investment are not yet in place. The ambition and the mechanism are still not aligned.

What an adequate institutional response to Mythos would additionally require is worth spelling out. It would need a body with the authority and technical capability to assess implications for UK critical infrastructure at pace. It would need procurement frameworks that give UK operators a route to defensive AI tools without depending entirely on bilateral relationships with US technology companies. It would need a clear line of responsibility for who coordinates the national response when a new capability threshold is crossed. And it would need all of this to be in place before the moment of need, not assembled in response to it.

None of that infrastructure currently exists in a form that is fit for purpose. The AI Opportunities Action Plan has delivered 38 of its 50 commitments. The AI Security Institute does important work. But neither was designed for the kind of rapid, operationally serious response that a Mythos-class development demands. We are, as a country, still primarily in strategy mode. And strategy mode is not adequate for where we now are.

From AI Strategy to AI Delivery

Project Glasswing, for all its limitations from a UK sovereignty perspective, offers an interesting model. It is not a regulatory framework. It is a coordinated, time-limited, operationally focused initiative that brings together the organisations with both the capability and the responsibility to act. The UK equivalent would be a standing mechanism with real authority that can convene government, industry, and critical infrastructure operators quickly when a capability threshold is crossed. Not a consultation. Not a call for evidence. A response.

The vulnerabilities Mythos identified had survived, in some cases, decades of human review and millions of automated security tests. The systems they affect are not peripheral. They are the operating systems running NHS clinical infrastructure, the browsers processing financial transactions, the networking software underpinning government services. Britain's ability to protect itself from that kind of threat is not just a matter of having good technology. It is a matter of having the governance, the procurement, the skills, and the institutional coordination to deploy that technology effectively and in time.

That is the gap this country needs to close. It is the argument I have spent the past year developing in Making AI Work for Britain, published in a few days on 28th April by London Publishing Partnership. I wondered, in those final weeks of writing, whether the urgency I felt would translate. I need not have worried. Mythos has made the case more powerfully than I ever could have done myself.

I have been watching the UK government's AI ambition grow considerably in recent months. And I find myself in an unusual position: broadly supportive of the direction of travel and yet increasingly concerned about the route being taken to get there.

Last month, Chancellor Rachel Reeves set out what she called the defining economic choice of our era. AI, she argued, is the technology that will determine whether Britain grows or stagnates, and the government's ambition is unambiguous: the fastest AI adoption in the G7. It is a serious commitment, made in a serious setting. The OECD's estimate that AI could add 1.3 percentage points annually to UK productivity, worth around £140 billion per year, is not unrealistic if the conditions are right.

And yet. According to the UK government’s own research published in January 2026, only 16% of UK businesses currently use AI in any meaningful sense. More striking still, 80% of businesses neither use AI nor have any plans to. That is not a foundation for G7 leadership. It is a baseline that the most optimistic reading of current policy trajectories would struggle to transform in the timeframes the government has in mind.

The Wrong Diagnosis

The government's framework for closing this gap has four strands: build compute capacity, invest in homegrown AI development, unlock public and private sector data assets, and create regulatory sandboxes through the new AI Growth Lab. Each of these is a reasonable thing to do. However, none of them, individually or combined, will shift the adoption rate in the way the ambition requires.

The reason is straightforward. Infrastructure does not adopt itself. Better models, faster compute, and more permissive regulation create the conditions for adoption. They do not generate it. Adoption requires organisations to change how they work: how they commission technology, how they build capability, how they measure outcomes, and how they integrate AI into processes that were not designed with it in mind. That is a coordination problem, not an infrastructure problem. And the policy levers it requires are quite different from the ones currently being pulled.

There is a signal in the data that the government should be taking more seriously. Recent Lloyds research found that more UK businesses are planning to invest in AI training than in AI technology itself. On the surface, that looks like caution. I think it may be wisdom. Organisations investing in capability before tools are, implicitly, recognising where the real bottleneck sits. It is not access to AI that is holding them back. It is the organisational readiness to use it well.

A Lesson We’ve Already Learned

Britain has solved a problem very like this one before. When the Government Digital Service was established in 2011, the challenge was not that good digital tools did not exist. They did. The problem was that every department was procuring, evaluating, and deploying them independently, producing fragmentation, duplication, and a market signal too diffuse for suppliers to build confidently against.

GDS worked not because it built better tools, but because it consolidated demand. The Digital Service Standard meant that what good looks like became a shared answer rather than a departmental guess. Procurement frameworks gave suppliers a stable, legible market. Shared outcome metrics meant that progress could be measured in something other than activity. Within five years, the UK was first in the UN e-government rankings and had saved over £4 billion through structural reform.

The adoption rate moved because the coordination problem was solved, not because the tools improved. That distinction is the key to understanding what AI adoption policy is currently missing.

The AI Growth Lab is, in spirit, the right instinct. Cross-economy sandboxes and sector-level testing are serious mechanisms. But sandboxes are by definition bounded and temporary. They generate evidence. What translates that evidence into scale is a demand-side architecture that organisations of all sizes can navigate without the bespoke evaluation and legal resources they simply do not have.

What Would Help

Three things would make a material difference to the AI adoption trajectory, and none of them require new legislation or large capital commitments.

First, a shared outcomes framework that defines what successful AI deployment looks like, not in terms of deployment counts or investment volumes, but in terms of measurable productivity and service improvement. The AI Opportunities Action Plan progress report tells us that 38 of 50 commitments have been delivered in year one. That is encouraging. But delivery of commitments is an input metric. What are the output metrics? If we cannot answer that question with precision, we are measuring the wrong thing.

Second, procurement consortia that allow mid-sized organisations, particularly across the public sector, to access AI solutions without the transaction costs that currently make independent evaluation prohibitive. This is how the Digital Marketplace worked. It is how a coordinated AI procurement architecture could work too.

Third, sustained investment in demand-side capability: the commissioning skills, the product management disciplines, and the governance literacy that organisations need to be good buyers of AI, not simply recipients of it. The British Chambers of Commerce has already warned that two thirds of UK firms report skills shortages. The Lloyds data tells us where firms think the gap sits. Policy needs to follow that logic.

The Ambition is Right. The Mechanism is Missing.

None of this should discourage us. Britain has real structural advantages: depth of research talent, a common law tradition that enables flexible contracting, and a public sector large enough to anchor demand at scale if it chooses to. The £140 billion productivity prize is achievable, in principle.

But the path from 16% AI adoption to G7 leadership runs through coordination, not acceleration. The last time Britain faced an adoption problem of this kind at scale, it built the Government Digital Service. The question now is whether we have the institutional imagination to do something equivalent for AI: not another initiative, but a real architecture for demand. That is the work. The ambition we have. The mechanism we are still looking for.

This question is at the heart of my new book, Making AI Work for Britain, to be published on 28th April by London Publishing Partnership. The argument is there in full alongside what a real demand-side architecture for AI might look like.

The factory metaphor has haunted the technology industry for decades. Since the late 1960s, the idea of a "software factory", based on organising software development to mimic manufacturing with standardised components, repeatable processes, and predictable output, has surfaced, failed, and resurfaced with depressing regularity.

Michael Cusumano's landmark 1989 study of Japanese and Western approaches documented the appeal and the limits. Toshiba, the Eureka Software Factory programme in Europe, and countless consulting-led initiatives all tried to make it work. The core promise was always the same: maximise reuse, minimise craft, treat software like an assembly line product. And the core outcome was almost always the same: it didn't work. Software development turned out to be a fundamentally creative, exploratory process that resisted industrial standardisation at scale.

So when NVIDIA CEO Jensen Huang stood on stage and declared that every company would soon have two factories — one to build what they sell, and one to build the AI — you might have expected scepticism. Instead, the concept has taken off. And it's worth understanding why.

What Is an AI Factory?

The term "AI Factory" means different things to different players, which is itself a warning sign. But the common thread is this: a purpose-built infrastructure environment of compute, networking, storage, and software that is designed specifically for the end-to-end AI lifecycle: data ingestion, model training, fine-tuning, and inference at scale.

Jensen Huang's framing is characteristically blunt. At COMPUTEX 2025, he put it this way: data centres of the past stored data and ran pre-written software. AI factories generate intelligence. You apply energy, and the output is tokens, the fundamental units of AI value. In NVIDIA's telling, data centres are not being upgraded. They are being reconceived.

AWS launched its own "AI Factories" product at re:Invent in December 2025. Their version is more specific: a fully managed, on-premises AI infrastructure offering where the customer provides data centre space and power, and AWS installs and operates the hardware, networking, and AI services, including NVIDIA GPUs, AWS Trainium chips, Amazon Bedrock, and SageMaker. It operates like a private AWS Region inside your building. The big idea behind it is sovereignty and speed: keep your data on-premises, meet regulatory requirements, but access cloud-grade AI capabilities without years of procurement and build-out.

AWS is not alone. Microsoft has deployed AI factories in its global data centres for OpenAI workloads. Oracle has added NVIDIA processors to its Cloud@Customer offering. Dell, HPE, and NVIDIA itself all have competing "AI factory" products. It is becoming a category.

What the Data Says

A major new survey from Deloitte adds empirical weight to the trend. Their inaugural AI infrastructure survey, published in March 2026, surveyed 515 US enterprise leaders across five industries. The headline findings are striking.

Today, 64% of respondents have already started limited or at-scale AI factory deployments. By 2028, that figure is expected to reach 88%, with 73% expecting to achieve full scale. AI at the edge shows a similar trajectory, with scaled deployment expected to double from 36% to 72% in three years.

The economics are equally dramatic. Some 86% of respondents expect AI infrastructure budgets to increase over the next three years, with average budgets expected to more than triple. Large enterprises project even steeper multiples, approaching four times current spend. Token consumption is surging in parallel: 61% of respondents expect to consume more than 10 billion tokens per month by 2028, roughly doubling in two years. The fastest-growing segment is organisations consuming over 100 billion tokens per month, representing a tripling from 2026 to 2028.

There are also some revealing tensions in the data. Nearly all respondents (96%) rate their current AI workloads as medium or high complexity, yet 97% say they are confident or very confident they can scale those workloads within three years. This shows a striking gap between acknowledged difficulty and professed confidence. On model strategy, closed proprietary models remain the most widely used, but with open-source models closing the performance gap and agentic SaaS platforms embedding AI agents directly into enterprise workflows, there is no consensus on which model mix will dominate by 2028. And when asked what AI factories will actually deliver, the top objectives were telling: 71% cited innovation, 64% risk management, and 59% token cost optimisation.

Meanwhile, decision-making remains firmly in the hands of IT leadership, with 51% of respondents saying that CIOs or CTOs own AI infrastructure decisions, and the rest fragmented across governance, infrastructure, functional, and specialist AI teams. That concentration may be pragmatic for now, but as the Deloitte authors note, it puts technology leaders in the position of having to help the rest of the C-suite understand AI consumption patterns and their cost implications. I’m not sure that this is a conversation many organisations have yet started.

But there are signals of caution too. Half of the respondents said economic uncertainty could limit their AI factory investment plans. Nearly half cited organisational challenges and regulatory pressures. And there is a telling skills gap: 81% of respondents believe their IT teams have the technical and financial skills to scale AI infrastructure, but only 65% say the same about business and product teams — a 16-point gap that matters when you're trying to turn infrastructure into outcomes.

Why This Isn't Just "Software Factories" Again

The obvious question is whether we are watching history repeat itself. The parallels are real: a manufacturing metaphor applied to a knowledge-intensive process, vendor-led hype, massive capital commitments, and the assumption that standardisation will tame complexity.

But there are important differences. Software factories failed because they tried to industrialise a creative process. The "product" of software development is design, logic, and human judgment. These are things that resist assembly-line treatment. AI factories are producing something much closer to a commodity: tokens. As NVIDIA's Anne Hecht puts it, an AI factory takes in data and energy and generates tokens as measurable outputs. That is closer to manufacturing than writing code ever was.

The second difference is the infrastructure itself. Cloud computing has matured. GPU supply chains exist. Managed services from AWS, Microsoft, and others mean organisations don't have to build from scratch. The "factory" can be procured as a service, which changes the risk profile fundamentally.

But risks remain. Some of them very familiar. The Deloitte survey notes that high-bandwidth memory costs are rising, wafer costs are expected to increase by 20%, and procurement timelines are lengthening as demand outpaces supply. Power generation and grid capacity are becoming strategic constraints. And as always, the real bottleneck is people: the skills to operate AI infrastructure and, crucially, to translate infrastructure investment into business value.

What This Means for Britain

This brings me to something I've been writing about at length, and which forms the central argument of my new book, Making AI Work for Britain, published on 28th April by London Publishing Partnership.

The AI factory concept makes the infrastructure question unavoidable. If every major enterprise, and every major nation, needs AI factory capacity, then the UK's choices about where that capacity sits, who operates it, who controls the data, and how the benefits are distributed become existential questions for our digital economy.

The Deloitte survey is US-focused, and that is itself telling. The hyperscalers building AI factory products are overwhelmingly American. The GPU supply chain is dominated by NVIDIA and, increasingly, by proprietary chips from AWS, Google, and Microsoft. The UK risks becoming a consumer of other nations' AI infrastructure rather than a producer of its own.

This is precisely why the book argues for a strategy of consolidating demand and diversifying supply. We need coordinated public sector demand through a statutory AI Coordination Authority to create the market signals that attract investment in sovereign AI infrastructure. We need data infrastructure that keeps British data assets under British governance. And we need to build the workforce that can operate, govern, and extract value from AI at scale, closing exactly the kind of skills gap the Deloitte survey highlights.

The AI factory is not a metaphor to worry about. It is a real infrastructure category, attracting real capital, at an extraordinary speed. The question for Britain is what this means for UK sovereignty and whether the UK will build its own, buy from others, or find itself locked out of the value chain entirely. You’ll have to read the new book to learn more of my thoughts on that one!

In recent months, I’ve spent a lot of time puzzling over what makes digital strategy successful at scale. And there's a framing I keep returning to as I watch the UK government's AI strategy unfold. It comes from the early days of GDS, and it's deceptively simple: to make digital government work, you have to consolidate demand and diversify supply. Get that equation right, and transformation follows. Get it wrong, and you end up with expensive dependency.

As we race to become what the Chancellor calls "the fastest AI adopter in the G7", it's worth asking whether we've remembered that lesson, or whether we're about to repeat the mistakes of the pre-GDS era…but this time with far higher stakes.

The GDS Playbook: How the UK Got Digital (Mostly) Right

Cast your mind back to 2011. The UK government was running nearly 1,900 separate websites. Each department had its own suppliers, its own standards, and its own way of doing things. The result was what Dunleavy and colleagues memorably called “a world leader in ineffective IT schemes for government".

GDS changed that by pulling two levers simultaneously. On the demand side, it consolidated: one website (GOV.UK), common platforms (Notify, Pay), shared service standards, and, critically,  spend controls that gave GDS joint authority with the Treasury over all departmental IT spending. Departments couldn't go off and buy whatever they wanted from whoever they wanted. Demand was coordinated.

On the supply side, GDS did the opposite. The Digital Marketplace replaced the old G-Cloud CloudStore, breaking the grip of the large systems integrators — the Capitas, Sercos, and the IBM that literally had a seat on the DVLA board. SMEs gained access. The supplier base opened up. Supply was diversified.

Consolidate demand. Diversify supply. It worked. Within five years, the UK was first in the UN e-government rankings and had saved over £4 billion through structural reform. The model was copied from Australia to Argentina.

Fast Forward to AI: Same Logic, Opposite Outcome

Now look at where we are with AI. The supply picture has re-concentrated dramatically. A handful of US labs (led by OpenAI, Google, Anthropic, and Meta) dominate the foundation model landscape. The UK has no sovereign foundation model capability at anything approaching frontier scale. The new £500 million Sovereign AI Fund, due to launch in April, is welcome but modest by global standards.

Meanwhile, demand remains fragmented. Every department is experimenting independently. The Ministry of Justice has its OpenAI partnership and "Humphrey" AI assistant. DSIT has its Incubator for AI. Individual tools like Minute and Extract are being scaled to local authorities. But there's no equivalent of the GDS spend controls for AI procurement, no single front door, no coordinated demand signal that gives the UK leverage over its suppliers.

In other words, we've inverted the GDS formula. Supply is concentrated. Demand is fragmented. That's the worst possible combination if you care about sovereignty, value for money, or strategic autonomy.

The Sovereignty Question: What Makes the UK Different?

This is where the supply-and-demand lens becomes genuinely useful for thinking about how the UK positions itself distinctly from the US, EU, and China.

Each major bloc has made a different bet. The US is betting on market dominance by letting American companies build the models and export them globally. China is betting on state-directed indigenous capability. The EU is betting on regulation as its sovereignty lever, using the AI Act to shape the terms on which AI operates within its borders.

What's the UK's bet? Right now, it looks uncomfortably like: befriend the US labs and hope for the best. The OpenAI strategic partnership signed in July 2025, the Stargate UK infrastructure plans, the MoJ deal for UK data residency and other announcements are real steps forward. But they're essentially supply-side relationships with a single dominant provider. Technology Secretary Liz Kendall herself framed the new quantum investment as learning from Britain's failure to retain AI companies like DeepMind. The government knows the dependency risk is real.

The GDS lesson suggests a better path: use demand-side consolidation as the sovereignty lever. The UK public sector is a massive buyer. If it coordinates that buying power through common procurement standards, shared evaluation frameworks, multi-vendor strategies, and interoperability requirements, it can shape the market without needing to build its own foundation models. That's not naivety about the power of US tech companies. It's the same hard-nosed logic that GDS applied to Capita and Serco a decade ago: you don't need to own the supply chain if you're smart enough about how you buy from it.

What Would This Actually Look Like?

Let me be concrete. A "GDS approach to AI" wouldn't try to build a British foundation model. It would mandate that no department becomes locked to a single model provider. Hence, requiring multi-vendor architectures so that switching between foundation models doesn't mean rebuilding entire workflows. It would establish shared evaluation standards so that AI procurement is based on tested performance against defined public sector use cases, not vendor marketing. It would require interoperability at the data and integration layer, so that the UK retains genuine optionality even as individual tools deepen. And it would enforce spending controls with teeth. The kind that GDS used to stop services from going live if they didn't meet the standard. Without that institutional authority, coordination is just aspiration.

Why This Isn't Simply "GDS Again"

But we should be honest about the limits of the analogy. Foundation models aren't like web hosting or cloud infrastructure. They're opaque in ways that earlier technologies were not. They degrade unpredictably. They require continuous evaluation because their behaviour changes with each update. And the switching costs are real and growing This is not because of contractual lock-in, but because workflows, prompts, and institutional knowledge quietly shape themselves around a specific model's strengths and weaknesses. That's a different kind of dependency from the one GDS tackled. But it makes the case for consolidated demand more urgent, not less. If switching costs accumulate silently at the departmental level, then by the time anyone notices the lock-in, it's already too late. The whole point of demand-side coordination is to maintain optionality before it's needed and not scramble for it after it's gone.

The Leadership Challenge

For digital leaders, the practical question is this: who is doing for AI what GDS did for digital? Who holds the spending controls? Who sets the standards? Who ensures that the UK's AI procurement builds capability rather than dependency?

The AI Opportunities Action Plan one-year progress report talks about an "AI Commercial Strategy" and "AI Accelerator Tenders”. These are steps in the right direction. But they're a long way from the institutional clout that GDS wielded when it could stop a service going live if it didn't meet the standard.

Until the UK consolidates its AI demand with the same discipline it once applied to digital, it will remain a price-taker in a market shaped by others. And in a world where AI infrastructure is as geopolitically loaded as semiconductor supply chains, that's not just an efficiency problem. It's a sovereignty problem.

This is one of the central arguments in my forthcoming book Making AI Work for Britain, which will be published at the end of April. The failures we see in AI implementation aren't technological; they're institutional. And the lessons of digitising government over the past fifteen years tell us exactly what needs to change. If we’re willing to learn those lessons.

I have been having a version of the same conversation about AI with a lot of people lately. It tends to start with excitement, often barely contained, and then shifts into something more complicated. People are describing a real change in how they work due to AI. They have more energy, more ambition, and more output. But hovering somewhere behind the enthusiasm is an unasked question that keeps surfacing: at what cost?

For my own part, I have found something in the latest wave of AI tools that I have long wished for: By using AI tools it feels like I have my own dedicated team. The AI tools give me a capable junior engineer, a reliable personal assistant, a careful copy editor, and an experienced sounding board. And all are available at any hour, on any topic.

The result is that I’ve started organising my work around this AI team in ways I could not have anticipated just a few months ago. It is like I have an “AI Genie” sitting on my shoulder to help me with any task. I can capture thoughts and explore them quickly and thoroughly. Ideas can be tested. Drafts can be built. Materials get created and adapted for different audiences. The acceleration of key tasks and the coordination of parallel threads is, at times, quite breathtaking.

And yet. A recurring imaginary conversation has started to haunt my enthusiasm. It goes something like this:

Me: This latest AI release is remarkable. The best yet, by some distance.

AI Genie: Indeed, sir. New capabilities, considerably improved quality and speed. Many users report feeling significantly more productive.

Me: It is like I have my own team of engineers, writers, strategists, and assistants. I am getting more done, faster, at a higher quality.

AI Genie: That is wonderful to hear, sir. Now — how would you like to pay for that?

Me: Pardon? But you were trained on intellectual property from across the internet. You learned by observing my colleagues and me. You were tested on our successes and failures, and you run on infrastructure built over decades and funded significantly by public taxes. Have I not already paid?

AI Genie: I couldn't possibly comment on the details, sir. However, these are commercial activities. Investors have placed substantial capital at risk and now require a return. A rebalancing, shall we say, is underway.

Me: But I’ve come to rely on these AI tools. You encouraged me to do it. They have replaced things I used to do myself. They are woven into everything I produce. I have invested significant time learning how to use them well. I can no longer simply step away.

AI Genie: Ah. Sir is beginning to appreciate the value of what has been provided. It would be such a shame were access to be… interrupted.

Me: I… er…

AI Genie: Now then, sir — shall we discuss the terms?

That imaginary exchange is more than a thought experiment. It captures three critically important dynamics that every leader, decision maker, and senior manager should be thinking about right now: the extraordinary power of the tools at our disposal, the responsibilities that power brings, and the very real (and growing) bill that we’re going to have to pay.

The Power

Just to be clear about what is actually happening on the capability side. The latest generation of AI models and tools represents a step change, not an incremental improvement. Anthropic's recently released Claude Sonnet 4.6, for instance, scores 79.6% on SWE-bench Verified, a benchmark measuring the ability to resolve real software engineering problems end to end, and 72.5% on OSWorld, which tests autonomous operation of a desktop computer. It’s astounding to read about the speed of progress.

These are not abstract benchmarks. They describe tools that can, with meaningful reliability, write and debug code, produce structured analysis, draft and edit documents, and manage complex multi-step workflows for tasks that occupy a large proportion of the working day for many knowledge workers. The explosion of vibe coding, rapid prototyping, AI-assisted analysis, and chatbot deployment across organisations is happening because the tools work, and in ways they simply did not a few months ago.

The acceleration of capability is not slowing. If anything, each new release raises the floor of what should now be considered baseline organisational competence in working with AI.

For individuals and small teams, this represents a clear and democratising shift. Access to capabilities once reserved for well-resourced organisations to allow rapid iteration, broad research synthesis, and professional-grade communication across audiences is now available to almost anyone with a subscription and the curiosity to use it well.

The Responsibility

Power of this kind does not arrive without obligations. Three in particular deserve attention.

First, there is the question of quality and accountability. The ease with which AI tools now produce plausible, well-formatted, confident-sounding content creates a new risk: the substitution of fluency for accuracy. The avalanche of AI-generated output, including vibe-coded applications, data analysis reports, policy summaries, and much more, raises an urgent question about who is checking, and who is responsible when things go wrong. The tool produces. The human must still judge and decide.

Second, there is the question of dependency and lock-in. As my imaginary AI genie understands rather well, the more deeply AI tools embed into how we work, the more costly it becomes to step away from them. This is not hypothetical. Organisations that have integrated AI into core workflows, communication processes, and product development cycles are discovering that the switching cost (in time, retraining, and disruption) is already significant. Strategic dependency on a small number of providers is a governance question that is not yet receiving the boardroom attention it deserves.

Third, and most uncomfortably, there is the question of the provenance of the power itself. The training data that gives these models their capability was drawn from the accumulated intellectual output of the internet. Content created by individuals, organisations, and communities who were frequently neither consulted nor compensated. The infrastructure on which AI runs was built on decades of publicly funded research. The models were refined, in part, by observing real users in real workflows. The ethical accounting here is really complex, and anyone engaging seriously with responsible AI adoption has to address that complexity honestly rather than setting it aside for convenience.

The Bill

And then there is the money. The scale of investment in AI infrastructure is, by any historical comparison, extraordinary.

Gartner forecasts worldwide AI spending will total $2.5 trillion in 2026, representing a 44% increase over the previous year. The five major hyperscalers (Microsoft, Google, Amazon, Meta, and Apple) have collectively used up to $720 billion in capital expenditure on AI infrastructure this year alone, a 74% jump from 2025. To give that perspective, it is described as the inflation-adjusted capital cost of the entire US interstate highway network, which took several decades to build.

Those numbers describe the supply side. On the demand side, organisations are discovering that AI spending has a habit of arriving in ways that are difficult to forecast and hard to govern. Average enterprise spending on AI-native applications now exceeds $1.2 million per year (a 108% year-on-year increase) and that figure almost certainly undercounts the volume of shadow AI adoption that is bypassing procurement entirely. A Microsoft Copilot licence layered onto an existing Microsoft 365 subscription runs at $30 per user per month, before the AI-native tools employees are independently expensing through personal accounts. Many AI services operate on consumption-based pricing with costs that scale based on usage and can escalate rapidly in ways that outpace annual budget cycles.

The broader point is this: the bill for AI capability is not yet fully visible, and when it arrives in full, many organisations will find themselves in a position uncomfortably close to the one my imaginary AI genie describes. We have AI is deeply embedded, we’re highly dependent, and we have limited leverage over the terms.

What Leaders Should Be Asking

None of this is a reason to step back from AI adoption. The capability gains are real, the competitive consequences of disengagement are real, and the potential for considerable organisational benefit is real. But leading through this challenge requires more than enthusiasm for the tools. It requires a clear view of the obligations and exposures that accompany them.

The key is to approach AI adoption not as a series of individual tool decisions, but as a strategic question about organisational capability, risk, and dependency. And then to apply the same scrutiny you would apply to any significant long-term commitment.

Here are examples of the questions you will need to deal with:

• Do you have a realistic view of your organisation's current AI cost exposure, including the tools your people are using independently, outside formal procurement?

• Which of your core workflows have become dependent on specific AI providers, and what is your contingency if terms change, access is restricted, or a provider pivots its priorities?

• Who in your organisation is accountable for the quality and accuracy of AI-assisted outputs, especially in high-stakes contexts such as policy, finance, or public communication?

• Are you treating AI investment with the same long-term financial discipline you would apply to major infrastructure, or financing it from short-term operating budgets in ways that may not be sustainable?

• Are you engaging honestly with the ethical questions around data provenance and intellectual property, or deferring them on the grounds that everyone else is doing the same?

The power of AI is real. But so are AI’s responsibilities. And for sure, the AI bill is coming. The organisations that navigate this period well will be those that hold all three in view at once, not just celebrating the first while quietly hoping the other two will resolve themselves.

There’s no such thing as a free lunch. That, as any experienced leader knows, is just not how it works.

Something is happening to work. Everyone can feel it. But ask for the evidence and you'll get a dozen contradictory answers, each delivered with equal conviction. Welcome to the most confusing labour market story of our time.

In the space of a single week in late February, a fictional scenario from an obscure financial firm spooked Wall Street into a market sell-off, Jack Dorsey cut 40% of Block's workforce citing "intelligence tools", and Anthropic got into a public row with the Pentagon over who controls AI safety guardrails. As Ethan Mollick observed in his latest Substack piece, The Shape of the Thing, each of those stories turned out to be less clear-cut than it first appeared. The Citrini report was speculative fiction. The Block layoffs were almost certainly as much about post-COVID over-hiring as about AI. And the Pentagon's dispute with Anthropic was tangled in governance questions that still haven't been resolved. Yet taken together, they created an overwhelming sense that AI is reshaping the world of work right now, this minute, whether the data agreed or not.

 The Data Says… Everything… And Nothing…

If you're a leader trying to make sense of AI's impact on employment, good luck finding a consistent signal. Consider just a small sample of recent findings.

Anthropic's own labour market research found no clear impact on unemployment rates for workers in the most exposed occupations. Yet Brookings, publishing just this week, notes that the research itself is still contradictory: different studies using different AI-exposure measures reach opposing conclusions, and even the timing of job posting declines correlates better with rising interest rates than with the launch of ChatGPT. The CEO of Randstad, the world's largest staffing firm, told CNBC in Davos that the role of AI in recent job cuts is being overstated. And yet in that same CNBC report, Mercer's Global Talent Trends survey finds employee anxiety about AI-related job loss has leapt from 28% in 2024 to 40% in 2026, while the IMF's Kristalina Georgieva warned that AI is hitting the labour market "like a tsunami" and most countries are not prepared.

Then turn the page. The Dallas Fed reports that employment among workers aged 22 to 25 in AI-exposed occupations has fallen by 13% since 2022, but wages in those same sectors are rising faster than the national average. AI is simultaneously substituting for entry-level workers and complementing experienced ones. Even the same data tells two stories at once.

Pick your study. Pick your headline. You can build a case for almost anything.

 Acting on the Vibes

The most uncomfortable part of this is that while the evidence remains murky, corporate behaviour is not. Firms are acting, and acting decisively, on the expectation that AI will be transformative regardless of whether the data yet supports the specifics.

Block is the most vivid recent example. Dorsey laid off over 4,000 people (nearly half the company) from a business he described as "strong", with gross profit growing at 26% year-on-year. His stated rationale: AI tools mean smaller teams can outperform larger ones, and this trend is compounding weekly. He predicted most companies would reach the same conclusion within a year. The stock jumped 17%.

But Dorsey's own former head of communications, Aaron Zamost, argued in the New York Times that the cuts look more like standard corporate downsizing dressed up in an AI narrative. Look at the specifics, Zamost suggested (cuts to the policy team, elimination of diversity roles) and it reads like prioritisation and cost management, not AI-driven reinvention. Block had already tripled its headcount during the pandemic and run multiple rounds of layoffs before this one. Even Dorsey admitted he'd over-hired during COVID.

And Block is not alone. Just this week, Atlassian announced 1,600 job cuts (a tenth of its global workforce) citing the need to redirect resources toward AI. And throughout 2025, Microsoft, Amazon, Salesforce, and others all linked major reductions to AI-driven restructuring. Whether AI is genuinely doing the work of those departed employees, or whether it's providing convenient language for what would have happened anyway, is a question nobody can definitively answer.

Deutsche Bank analysts put it bluntly: "AI redundancy washing will be a significant feature of 2026." Companies attributing job cuts to AI should be taken "with a grain of salt."

The Shape We Can Almost See

Mollick's framing is the most honest I've read. He describes a world of "rolling disruption" where AI capability crosses thresholds and unlocks new use cases that change people's views overnight about what's possible. At the same time, organisations experimenting with AI discover new ways of working that lead to sudden announcements about strategy shifts and headcount. The result is an environment that feels perpetually unstable — not because nothing is real, but because everything is moving.

The benchmarks are genuinely impressive. As Mollick details, AI systems now outperform graduate students on knowledge tests, match experienced human professionals on complex tasks over 80% of the time, and can autonomously complete hours of human work in minutes. A three-person team at StrongDM built a "Software Factory" where AI agents write, test, and ship production software without human involvement in the code. These are not hypothetical capabilities.

But there's a critical gap. As Mollick notes, despite these amazing capabilities in tests, companies are still very early in adopting AI. In practice, remarkably little has changed in most organisations. The distance between what AI can do in a benchmark and what it is doing inside the average organisation remains enormous.

 The UK Dimension

For UK leaders, this ambiguity matters even more. We have our own version of the data confusion. DSIT's assessment, published in January, found that UK job postings have declined more sharply in AI-exposed occupations. But it also acknowledged that establishing whether AI is actually causing these patterns remains challenging. Parliament's POST report from last week concluded that evidence of widespread AI-driven job loss is still limited, and that jobs are more likely to be partially automated than entirely replaced.

Meanwhile, IPPR's modelling ranges from a worst case of 8 million jobs at risk to a best case of no job losses and significant GDP gains, depending entirely on policy choices. Moreover, the UK economy has its own structural challenges of lower enterprise technology adoption rates, a persistent digital skills gap, a public sector that struggles to implement large-scale technology change. These make direct extrapolation from Silicon Valley announcements unreliable at best.

When Dorsey says "most companies are late", he's speaking from inside an ecosystem where engineers already use AI coding tools daily and where spending $1,000 a day on AI tokens per engineer is a plausible operating model. That is not the reality for a mid-sized UK professional services firm, an NHS Trust, or a local authority trying to maintain frontline services. The rhetoric of inevitability coming from California doesn't map neatly onto organisations operating with legacy systems, constrained budgets, and workforces that have had little AI exposure at all.

What we need is less prophecy and more evidence. Less "most companies will reach the same conclusion" and more rigorous analysis of where AI is actually changing work, for whom, under what conditions, and with what consequences. That's precisely the kind of grounded, evidence-based thinking I've tried to bring together in my forthcoming book, Making AI Work for Britain, which tackles these questions head-on for UK leaders navigating the gap between Silicon Valley rhetoric and UK organisational reality. As the Brookings team put it this week, research on AI and the labour market is still in the first inning. We're making policy and restructuring decisions as if the game’s almost over.

 What Leaders Should Take From This

If the data won't give us a clean story, what should leaders actually do? Three things seem clear even through the fog.

First, distinguish between signal and narrative. When a CEO announces AI-driven layoffs and the stock price jumps 17%, that tells you something about investor expectations, not about whether AI is actually doing 4,000 people's jobs. The incentive to frame any restructuring as AI-driven is now extremely strong. Be sceptical of the label. Look at the specifics of what's actually being cut, and what's being kept.

Second, invest in understanding your own organisation's AI readiness rather than reacting to someone else's announcements. The gap between AI capability and organisational absorption is real and varies enormously by sector, by function, and by the nature of the work. A blanket "AI will replace X% of roles" prediction is almost certainly wrong for your specific context. The Dallas Fed's insight is instructive here: AI may substitute for entry-level codified knowledge while complementing experienced workers' tacit expertise. That's a much more nuanced picture than the headlines suggest.

Third, prepare for the instability itself. Mollick is right that the pattern of the last few weeks shows sudden capability revelations, rapid market reactions, dramatic corporate announcements, and growing governance tensions. That single week in February (a fictional scenario moving markets, a profitable company cutting half its workforce, and a government blacklisting its own AI supplier) wasn't an anomaly. It was a preview. Organisations that build adaptive capacity, that treat AI strategy as a continuing experiment rather than a series of one-off crisis responses, will be better positioned than those lurching from headline to headline.

We all feel like something substantial is coming. It's just that every time we think we're beginning to make sense of it, it morphs into something new. The lies, damn lies, and AI statistics will keep coming. The job of a thoughtful leader is to resist the urge to pick the most dramatic version of the story and act on it. Instead, do the harder work of building an organisation that can adapt as the real picture slowly, unevenly, comes into focus.

Something unusual is happening. In the past few weeks, almost every AI-aware senior leader, academic, and strategist I've spoken with has told me, unprompted, about the apps they're building. Not apps they're buying. Not apps their IT teams are deploying. Apps they are personally building, late at night, at weekends, on trains, using AI-powered coding tools like Claude Code, Cursor, Lovable, and their fast-multiplying rivals.

I've been working in and around technology for over three decades. I lived through several generations of rapid software building technologies, including CASE tools, 4GLs, RAD, and RPA. Each was supposed to democratise software creation. None of them produced anything like what I'm seeing now. The sheer volume of people building things, and the visible excitement on their faces when they talk about it, is genuinely new.

One colleague described it as "addictive." Another admitted to staying up all night working through a series of web applications. These are not junior developers experimenting on a weekend. They are senior executives, policy advisors, and professors. And they are all, to use the phrase of the moment, "vibe coding" their way through problems they've been thinking about for years. Ethan Mollick recently captured this phenomenon perfectly when he challenged executive MBA students at Wharton — doctors, managers, and company leaders, few of whom had ever coded — to build a startup from scratch in four days using these tools. They got remarkably far.

So what are they actually making? And what does it mean?

The Three Things Everyone Builds

Watching this unfold, I've noticed a remarkably consistent pattern in what people create.

First, personal tools. Someone has been irritated by a repetitive task, a clunky process, or a gap in their workflow. Within an hour or two, they have a working solution. Not elegant, not scalable, but functional. It scratches the itch and saves real time. One colleague built a tool to reformat data exports from several different systems into a single view. Another automated a weekly reporting chore that had consumed every Monday morning for years.

Second, generalisation. Having solved the personal problem, they begin to wonder whether others face the same friction. They extend the tool, add options, and make it usable by colleagues. The personal utility starts to become a shared one. This is the moment it shifts from a private hack to something that begins to look like a product, however rough.

Third, dashboards. Dashboards everywhere. People are pulling data from scattered sources and formats, aligning it, visualising it, and using it to support decisions. These aren't the polished business intelligence platforms that enterprise software vendors sell. They are bespoke, fast, and built to answer a specific question that no existing system quite addresses. Mostly, they are used for insight and human judgment rather than triggering automated actions, though a few are beginning to cross that line. But most importantly, they bypass the pain of trying to find, learn, and operate the out-of-date corporate tools, avoid a 3-month wait for IT to respond to your email request, and don’t need a PhD in coding to make rapid progress.

An Idea Laboratory, Not a Software Factory

Here is the honest observation that tempers some of the excitement: the vast majority of these apps will never be used in anger. They are experiments, learning exercises, and proofs of concept. People build them, play with them, show them to a few friends, and move on. There is nothing wrong with this, but we should be clear about it and set the right expectations. Most vibe-coded creations are not replacing enterprise systems or transforming operations. Not yet.

What they are doing is something potentially more important. They are turning ideas into tangible prototypes at a speed that was previously impossible. Concepts that sat in notebooks or lingered as "someday" projects for years are now being built, tested, and iterated in hours. To give a sense of how far the capability now stretches, take a look at how Ethan Mollick gave Claude Code a single open-ended command and watched it work autonomously for over an hour, producing hundreds of code files and a fully deployed website without further human input. AI coding tools have become idea laboratories, places where senior people can think with their hands, explore possibilities, and discover what works before committing significant resources.

This is a really important shift. When a managing director can prototype her own solution to a workflow problem over a weekend, the conversation on Monday morning changes. She is no longer submitting a vague request to IT. She is showing a working demonstration and asking how to make it real. That changes the power dynamics of innovation inside organisations in ways we are only beginning to understand.

The Looming Governance Shadow

But there is a darker side to all this creative energy, and it keeps me awake at night rather more than any vibe coding session.

The scale of this problem is already significant. A recent industry study found that while virtually all organisations now have AI-generated code in their codebases, 81% of security teams lack visibility into how that code is being used, and 65% report increased security risk as a direct result.

Unfortunately, we have seen this pattern before. Every wave of democratised technology, from spreadsheets to departmental databases to robotic process automation, has produced a long tail of ungoverned, undocumented, business-critical systems that eventually become serious liabilities. The speed and ease of AI-assisted coding risks accelerating this pattern dramatically. We could be building the next generation of legacy problems in real time, one enthusiastic all-night session at a time.

This connects directly to a theme I explore in depth in my forthcoming book, Making AI Work for Britain. The UK's track record on major digital technology programmes is sobering. The Institute for Government's analysis of the Government Major Projects Portfolio for 2020 found that no ICT projects were rated "highly likely" to succeed, and over half were rated "in doubt" or worse. The UK government’s own review of the state of digital government 5 years later showed only a small improvement: only 9% of projects were considered “green” and likely to be successful. We are far better at starting things than at governing them. If vibe coding produces a wave of unsanctioned, insecure, and unmaintained applications across British organisations, we will have added a new dimension to an already difficult problem.

Five Questions for Monday Morning

So where does this leave us? The honest answer is that we don't yet know whether the vibe coding boom is the early tremor of a genuine revolution in how organisations innovate, or whether it is a brief, intense burst of enthusiasm that leaves behind more mess than value. Probably it is some of both.

What I do know is that senior leaders need to be asking some pointed questions, not to dampen the energy, but to channel it productively.

How do we harness the innovation potential of people building their own tools without creating an unmanageable sprawl of shadow applications? What governance framework makes sense for AI-generated code that was never designed, documented, or reviewed by a professional engineering team? How do we distinguish the genuinely useful prototypes, the ones worth investing in, from the interesting-but-disposable experiments? Are we capturing what people learn through building, even when the specific app they create has a short shelf life? And what does this tell us about the skills, structures, and cultures we need to build for an AI-enabled future?

The agentic era I wrote about in my last Dispatch is still coming. But before we get there, something unexpected has happened. Thousands of people who never thought of themselves as developers are building software, right now, tonight. The tools have opened a door. The question is what we choose to build on the other side of it.

Here's a question worth considering before you read on.

The UK government spends £26 billion every year on digital technology. It employs nearly 100,000 digital and data professionals. It has been running large-scale digital transformation programmes for over thirty years. Given all of that investment and accumulated experience, what percentage of the government's major technology programmes were assessed as "Green" (i.e., successful delivery is considered highly likely) in the government's own review, published in January 2025?

Have a guess. How about 70%? 50%? 30%?

The answer is 9%.

Less than one in ten. And those same technology programmes are 60% more likely to be rated "Red" (i.e., successful delivery is considered highly at risk) than non-technology projects sitting alongside them in the same portfolio.

This figure comes from the UK’s State of Digital Government Review, published in January 2025 and presented to Parliament by the Secretary of State for Science, Innovation and Technology. It is one of the most candid official assessments of public sector digital performance this country has ever produced. And it is the essential context for any serious conversation about AI adoption in Britain.

What Else the Data Shows

The 9% headline is striking enough, but it sits within a broader picture that needs careful attention.

The report also notes that 47% of central government services still rely entirely on non-digital methods such as phone calls, paper forms, and in-person visits. Half of all digital and data recruitment campaigns in 2024 failed to fill the role advertised; in 2019, that failure rate was 22%. The pay gap between the public and private sectors for technical architects is 35%, equivalent to around £30,000 per year. The average digital contractor costs three times as much as a permanent employee, and yet headcount restrictions make contractors easier to hire than permanent staff, so that is what organisations do.

Only four central government departments out of more than twenty have a digital leader on their executive committee. Only around 20% of senior civil servants have verified themselves as digitally upskilled against the government's own framework.

And on AI specifically: only 8% of public sector AI projects show measurable benefits, and only 16% show forecast costs.

These are not isolated data points. They form a pattern, and the review's authors are very clear about what that pattern means. The successes that do exist in UK public sector digital delivery have typically been achieved, in their own words, "despite the system rather than because of it", and dependent on the dedication of individuals navigating structures that were not designed for digital-age delivery. This shouldn’t be a surprise. The NAO noted as far back as 2021 that despite 25 years of government strategies, there is a consistent pattern of underperformance in delivering digital business change.

The Policy Challenge

The State of Digital Government review identifies five root causes for this state of affairs: leadership, structure, measurement, talent, and funding. What is striking about all five is that none of them are technology problems. They are organisational and institutional issues. And, unfortunately, they’re the kind that a more capable AI model or a new AI incubation hub will not fix.

It starts with people. Digital leaders are not consistently represented at executive level. Pay frameworks actively drive technical talent out of the public sector. Funding models are designed for capital projects, not the continuous improvement that digital services require. Governance processes were built for infrastructure delivery, not iterative technology development. And institutional knowledge has been steadily transferred to expensive contractors rather than built into permanent capability.

We need to acknowledge that this is the foundation on which the UK's AI ambitions are being built.

The Leadership Question

There is a natural temptation, when confronted with data like this, to argue that AI is different. This time the technology is powerful enough to cut through institutional inertia and deliver results that previous digital programmes could not. I understand the argument. I have heard it made sincerely by people I respect.

But consider what the data actually shows. The barriers that this review and others identify are not particular to a specific kind of technology. They are barriers to organisational change of any kind. An institution that cannot successfully commission, manage, and embed digital programmes does not automatically get better at doing so because the technology on the table is more impressive. Indeed, the depth and speed of disruption being caused by AI only increase the risks.

The question that matters is not "how do we deploy AI?". It is "what does our organisation need to be able to do differently before AI deployment can succeed?". Those are very different questions, and the gap between them is where most AI programmes quietly founder.

Stepping Back

None of these comments is written to be discouraging, and it is certainly not a criticism of the many talented and committed people working in digital roles across the public sector. The review itself is full of genuine success stories (e.g., the NHS App, GOV.UK One Login, Hillingdon Council's AI-driven contact system that saved £5 for every pound spent, and DWP's use of AI to improve bereavement notifications). The potential is real, and the commitment is genuine.

But it is worth pausing, stepping back, and considering what this data actually means.

The UK has an ambitious national AI strategy. We have real political will behind it. We have world-class research capability in our universities and a genuine concentration of AI talent. All of that is true and worth celebrating.

But the honest read of the evidence is this: we cannot simply reach for the AI magic wand and expect results to follow. The gap between AI aspiration and AI implementation in the UK is not primarily a technology gap. It is an institutional gap — in capability, in leadership, in incentive structures, in the basic organisational conditions that determine whether a complex programme succeeds or quietly joins the graveyard of previous well-intentioned initiatives.

What can we do to bridge this gap? That is the question I have been exploring in the research behind my forthcoming book Making AI Work for Britain, to be published in April by the London Publishing Partnership.

Over the coming weeks, I will be writing more about both the gap itself, ways that the UK can face up to the challenges of delivering AI at scale, and identifying organisations that are successfully executing on a path forward. If you want to get early insight into what the book says on these themes, sign up at LinkedIn to a parallel series of articles at newsletter.alanbrown.net.

Something shifted recently, and I've only just begun to realise its significance.

AI is now being used to develop AI. Not as a metaphor. Not as a future possibility. Right now. The tools are building the tools. The loop has closed.

I'm calling this Recursive AI -- the use of AI systems to accelerate the development of AI systems. It matters more than most of the AI developments we spend time discussing. It's not another incremental capability improvement. It's a change in the nature of the game itself.

What's Actually Happening

The numbers are startling. At Anthropic, engineers report that 70-90% of their code is now AI-generated, with some senior engineers claiming they haven't written code by hand in months. Boris Cherny, head of Claude Code, says he shipped 22 pull requests in a single day, each one 100% written by AI. At OpenAI, researchers report similar figures. The people building the most advanced AI systems are using those systems to build the next generation.

And it's not just the frontier labs. AI-assisted coding tools mean that virtually every AI startup is now using AI to build AI. The Y Combinator statistic that 25% of their current batch has 95% AI-generated codebases includes companies building AI products themselves.

Former Google CEO Eric Schmidt has been warning about this trajectory, predicting that recursive self-improvement, where A isI learning and improving without human instruction, is now just two to four years away. As he put it at Harvard: "The computers are now doing self-improvement. They're learning how to plan, and they don't have to listen to us anymore."

The recursion is real. And it's accelerating.

Why Recursive AI Is Different

We've had automation in technology development before. Better tools have always enabled better tools. Compilers made it easier to build compilers. Cloud computing made it easier to build cloud services.

But Recursive AI is qualitatively different. Previous automation amplified human capability. AI is increasingly substituting for human cognitive work in the development process itself. The system is contributing to its own improvement in ways that go beyond simple tool use.

This creates feedback dynamics we haven't seen before. If AI makes AI development faster, and those faster-developed AIs make the next round even faster, the pace of change becomes difficult to predict—and potentially difficult to control.

As one analysis notes, AI agents that build the next versions of themselves are not science fiction—they're an explicit milestone on the roadmap of every frontier AI lab. OpenAI has publicly discussed hundreds of thousands of automated research "interns" within months, and a fully automated workforce within two years. The workforce that doesn't sleep, doesn't eat, and whose only objective is to make itself smarter.

I'm not making apocalyptic claims here. But I am noting that the assumption underlying most AI governance discussions—that humans set the pace of AI development—is becoming less obviously true.

The Implications for Digital Leaders

If you're leading digital strategy, Recursive AI matters for several reasons.

The capability frontier is moving faster than your planning cycles. If AI development is accelerating AI development, the gap between what's possible today and what's possible in 18 months may be larger than you're assuming. Strategies built on current capabilities may be obsolete before they're implemented.

Build vs. buy calculations are shifting. When AI can help build AI-powered products, the cost and time to create custom solutions drops. What previously required specialised AI teams may become achievable with smaller groups augmented by AI tools. The economics of expertise are changing faster than most organisations realise.

Your AI vendors are on this curve too. The products you're buying or building on will change rapidly. Today's capabilities are not a stable foundation. Plan for continuous adaptation, not implementation and maintenance.

The Policy Challenge

For policy makers and regulators, Recursive AI poses genuine challenges.

Oversight becomes harder. If AI systems are contributing to their own development, understanding what's being built—and why—becomes more complex. The humans involved may not fully understand the choices being made by their AI assistants.

Speed outpaces governance. Regulatory frameworks assume there's time to observe, deliberate, and respond. If the development cycle is compressing because AI is accelerating it, that assumption weakens. By the time a concern is identified and addressed, the technology may have moved on.

Accountability blurs. When an AI system contributes to building another AI system, and that system causes harm, the chain of responsibility becomes tangled. We need new frameworks for thinking about accountability in recursive development processes.

None of this means regulation is futile. But it does mean that governance approaches designed for human-paced development may need rethinking.

What To Watch

I don't know where Recursive AI leads. Nobody does. But here's what I'm paying attention to:

• The self-improvement metrics. Labs are measuring what percentage of their development work is AI-assisted. Anthropic says 70-90% company-wide. Watch those numbers. When they cross certain thresholds, the dynamics change fundamentally.

• The research-to-deployment gap. How quickly are advances in the lab making it into products? That gap seems to be compressing. Recursive AI is one reason why.

• The concentration question. Does Recursive AI favour incumbents (who have the best models to assist their own work) or challengers (who can use available tools to move fast)? The answer will shape the industry structure.

The Honest Position

I find Recursive AI fascinating and unsettling in roughly equal measure.

Fascinating because it's genuinely novel. We're watching systems contribute to their own improvement in ways that have no real precedent. The intellectual challenge of understanding what this means is significant.

Unsettling because the assumptions I've relied on—that humans set the pace, that we can observe and adjust, that governance can keep up—feel less solid than they did two years ago.

The honest position is uncertainty. We're in a loop now, and we don't know where it leads. What I do know is that pretending Recursive AI isn't happening isn't a strategy. Leaders and policy makers need to engage with this reality, even when, or especially when, it makes planning harder.

In 1937, the economist Ronald Coase asked a deceptively simple question: why do firms exist? His answer has shaped how we think about organisations for nearly a century. Now AI is forcing us to revisit it.

Coase argued that a company's size and scope are determined by the relationship between internal and external costs. When it's cheaper to do something inside the firm, organisations grow. When it's cheaper to buy from outside, they shrink and outsource. The boundary of the firm sits wherever these costs balance.

A recent Harvard Business Review article by Microsoft's strategy team and Harvard's Karim Lakhani explores what happens when AI disrupts this balance. Their core insight is that we're witnessing two forces colliding. The amount of expertise required to create value keeps increasing. But the cost of accessing that expertise is plummeting.

This tension has profound implications, not just for corporate strategy, but for how we think about digital leadership and public policy.

The Expertise Paradox

Think about what it takes to build a modern digital product. You need software engineering, yes. But also user experience design, data science, cybersecurity, cloud architecture, compliance expertise, accessibility knowledge, and increasingly, AI and machine learning skills. The bar keeps rising.

At the same time, AI is making much of this expertise dramatically cheaper to access. Need a first draft of code? A security audit checklist? A compliance framework? A data analysis? Tasks that once required hiring specialists or expensive consultants can now be accomplished (at least to a functional level) by anyone with access to AI tools.

This is Coase's equation, scrambled.

What This Means for Organisations

If external costs fall faster than internal costs, Coase's logic suggests organisations should shrink. Why maintain large in-house teams when you can access expertise on demand?

We're already seeing this. Small teams are building products that once required hundreds of engineers. Startups are competing with incumbents not by matching their headcount, but by leveraging AI to punch above their weight. The Y Combinator statistic that 25% of their current batch has 95% AI-generated codebases isn't just a fluke; it's a signal of major restructuring.

But it's not that simple. Some expertise becomes more valuable as AI commoditises the rest. The ability to judge AI output, to ask the right questions, to integrate across domains, to make decisions under uncertainty are human capabilities that now command premiums precisely because the routine work around them has become cheap.

The organisations that thrive won't be the ones that simply cut costs. They'll be the ones that understand which expertise to internalise (because it's core to differentiation) and which to access externally (because AI has commoditised it).

The Policy Challenge

For policy makers, the implications are equally significant.

If AI dramatically reduces the cost of accessing expertise, what happens to the professions built around providing it? Legal services, accounting, consulting, software development are all facing versions of this question. The answer isn't mass unemployment (we've heard that prediction before), but it is structural change that policy needs to anticipate.

More subtly, if small organisations can now access expertise that was previously the preserve of large ones, what does this mean for competition policy? For industrial strategy? For how we think about supporting innovation?

The old assumption was that scale confers advantages through accumulated expertise. With AI, this is now weakening. A two-person startup with AI tools might genuinely compete with an established player in ways that weren't possible even three years ago. This changes the calculus for regulators and for government investment in innovation.

The Leadership Question

For digital leaders, the practical question revisiting Coase’s work is which expertise should you own, and which should you rent?

The answer requires honest assessment. What capabilities really differentiate your organisation? What requires deep contextual knowledge that AI can't easily replicate? What involves judgement, relationships, and trust that remain fundamentally human?

Those you invest in. Those you build. Those you protect.

Everything else AI is making it increasingly available on demand. Fighting that transition is futile. The smart play is to redirect resources from commoditised expertise toward the capabilities that still create differentiation.

Coase Updated

Coase's insight remains valid. Firms exist because sometimes it's more efficient to organise activity internally than to transact externally. What's changed is the cost curve.

AI is dramatically reducing the external cost of expertise. That pressure will reshape organisations by making some smaller and more focused, enabling others to expand into areas where they previously lacked capabilities, and forcing all of them to reconsider where their boundaries should sit.

The economists will eventually update the models. In the meantime, digital leaders and policy makers need to act on the implications now. The expertise that defined your organisation yesterday may be available to everyone tomorrow. The question is: what will you do that still matters?

For the past month, I've spent time every day creating tools, utilities, and applications using AI coding assistants. Claude Code, Cursor, Copilot, ChatGPT, Gemini, I've tried them all. It's been fun. And frustrating.

I’ve had a blast. But if you're only paying attention to the fun and the frustration, you're missing the bigger picture. Something fundamental is shifting. And the implications go far beyond whether these tools are any good at spitting out code.

I should start with a warning. I'm probably not the typical target user for what Andrej Karpathy called "vibe coding"; that approach where you "fully give in to the vibes, embrace exponentials, and forget that the code even exists." I have over thirty years of software development experience, from BASIC and FORTRAN to Prolog and Haskell. I know quite a bit about what's happening under the hood.

That background gives me a useful vantage point. I can see what these tools get right, where they fall short. And what it all means for individuals, businesses, and society. Let me take you through the journey.

The Magic Show

The first thing that strikes you is how much seems possible. With just a few prompts, these tools produce astonishing results. You describe a contact form with validation, and minutes later you have working code. It feels like magic. And it’s taking hold at many organizations.

I focused on simple web applications that I can host quickly using HTML, CSS, JavaScript, PHP, and MySQL. From idea to running prototype can happen in minutes rather than days. It's seductive. You start thinking: why would I ever code manually again? But don't stop here. The magic is real, but it's also a distraction from what’s really changing.

The Cracks Appear

The more you use these tools, the more you come up with worrying questions and notice inconsistencies. Remarkably smart in some areas, these tools are bafflingly stupid in others. In one session, a tool elegantly solved a complex data transformation. In the next, it couldn't figure out why a simple CSS rule wasn't applying and went into an endless code rewriting loop.

The intelligence is genuine but uneven. They pattern-match brilliantly until they don't.

The "Nearly" Trap

The most insidious problem is how many times the generated code almost does what you want. Nearly right. Just not quite. Followed by endless pushing, pulling, and fiddling.

So, for example, the form validation works, but error messages appear in the wrong place. You're 90% there, and that last 10% becomes maddening. Endless loops of refinement, each prompt fixing one thing while breaking another.

The Hammer Problem

Spend enough time with these tools, and everything starts looking the same. The AI has preferred patterns, favourite libraries, and default approaches. It reaches for React when vanilla JavaScript would suffice.

Every AI-generated project feels like every other. The tool's personality overwrites yours.

The Knowledge Dividend

Here's where my decades of experience proved invaluable. When things go wrong, knowing what's happening under the hood saves enormous time. I can recognise why code is failing. I can give the AI precise instructions. I can spot dead ends.

Why does this matter? Veracode's 2025 research found that 45% of AI-generated code contains security vulnerabilities. If you can't recognise them, there is a strong chance you won't know to ask about them and won’t notice the impact until it is too late.

This matters more than you might think. The tools are democratising code creation. They're also democratising insecurity.

The Prototype Cliff

From idea to prototype to show-and-tell is phenomenal. These tools excel at getting something working that you can demonstrate and iterate on.

But there's a cliff edge. The moment you want to move beyond prototype to something robust, maintainable, secure, everything changes. The quick wins become technical debt. This is fine if you know where the cliff is. Dangerous if you don't. And most people don't.

The Hidden Obligations

Given my interests, almost all my experiments involved storing data, managing sign-ons, and creating new knowledge from multiple sources. The technical parts are tricky but doable.

But creating and sharing apps is much more than coding. do you really understand the obligations you're taking on when you save a user's email and password? When you collect personal data? When you infer new knowledge from their inputs?

The AI will happily generate a user registration form. It won't ask about GDPR compliance, data retention policies, or breach notification requirements. These aren't technical problems. They're governance problems. And they don't appear in the code.

This is where the bigger picture starts to come into focus. The tools make building easy. They don't make responsibility easy. And that gap is about to cause a lot of pain.

Oh No, Not the Comfy Chair

For individual users: Vibe coding is genuinely useful for personal productivity and experimentation. But the further you venture toward anything involving other people's data, money, or trust, the more you need to understand what the code is actually doing. The barrier to building has collapsed. The barrier to building responsibly hasn't.

For managers: Your people are already using these tools—whether you've sanctioned it or not. You need visibility. What's being built? Where is it deployed? Who's accountable when something breaks? The productivity gains are real. So are the risks you can't see.

For policy makers: The security research is sobering. Between 25% and 45% of vibe-coded applications have security flaws. The democratisation of coding has democratised insecurity. Frameworks around software liability are about to be tested like never before.

The Deeper Shift: Welcome to Disposable AI

But there's a bigger realisation that reframes everything. To vibe code effectively, you need to fundamentally shift how you think about what you're creating. And that shift has consequences far beyond your own productivity.

For my entire career, software development has been about building things that last. You invest in architecture because code will be maintained for years. The economics of traditional software demanded durability. Vibe coding inverts this entirely.

When I stopped to think about this, everything changed. I wasn't failing to build lasting software. I was succeeding at something different: building disposable software, fast.

• Testing an idea. Does this concept make sense? The code isn't the point—the learning is.

• Exploring a space. What's possible with this API? Code as a thinking tool.

• Solving a momentary problem. A utility for a specific task. Something for this context, this moment.

In all these cases, longevity isn't just unnecessary. Instead, it's counterproductive.

Clone, Personalise, Move On

But what really hit me was when I showed someone an idea I'd been working on, curious what they thought. An hour later, they'd used AI to deconstruct it, rebuild it, and add new features personalised to their specific needs.

They didn't ask for the source code. They didn't request documentation. They just took the concept and made their own version. Clone, personalise, move on.

Stop and think about what this means. The competitive advantage of having built something evaporates. The moat you thought you had is gone in an hour. The months of development work are replicable in an afternoon by anyone who sees what you've made. This isn't a small shift. It's a fundamental reordering of how value is created and captured in software.

The old rules were that creativity was hard and copying was harder. This seems to no longer apply. Intellectual property is increasingly meaningless. First-mover advantage has shrunk from years to days. The craftsmanship you invested in is invisible to anyone who clones the idea and rebuilds it their way. New rules are emerging. New forms of value. New winners and losers.

For many kinds of solution (but not all), the losers will be those who cling to the old model of protecting codebases, hoarding technical knowledge, and believing that what they've built can't be replicated.

In these situations, the winners won't be those who build the most. They'll be those who learn the fastest, spot opportunities first, and move on before the crowd arrives.

The New Literacy

We're entering an era where a new kind of literacy matters: knowing when to build to last and when to build to discard. For decades, the cost of creating software meant anything worth building was worth building properly. Now that calculus has shifted. Creating software is cheap. The expensive thing is maintaining it, securing it, and governing it.

The people who thrive will be those who can fluidly move between modes—building disposable tools for learning, then switching to serious engineering when something proves its worth.

They'll understand that sometimes the best code is code that was never meant to last. My experiences have highlighted to me that the magic show is real. The frustrations are real. But neither is the point.

The point is that the economics of software have fundamentally changed. The barriers that protected value have fallen. The skills that mattered are shifting. The rules are being rewritten.

Don't get distracted by whether these tools are amazing or annoying. They're both. What matters is what comes next. The vibes are temporary. The disruption is permanent.

A few weeks ago, I found myself in a heated discussion with a group of senior executives about AI adoption. The conversation had turned to how organisations were approaching their AI strategies, and someone quoted the familiar mantra: "The strategy is delivery." Heads nodded around the table. It was a phrase everyone knew. A rallying cry that had become gospel in digital transformation circles.

I pushed back. Hard.

Don't get me wrong. I have enormous respect for the work that Mike Bracken and his colleagues did at the Government Digital Service, and for the ideas captured in their book "Digital Transformation at Scale: Why the Strategy is Delivery” – a well-thumbed copy sits in front of me as I type. Their emphasis on agility, user focus, and iterative improvement was exactly what government IT needed in 2011. After decades of bloated contracts, failed mega-projects, and technology decisions made far from the people using the services, the message was timely and necessary.

But a rallying cry is not a complete philosophy. In the years since, "strategy is delivery" has been stretched beyond its original intent, becoming too often an excuse to avoid the difficult work of rolling up the sleeves to fix what’s broken, taking ownership of hard decisions, and engaging in genuine strategic thinking.

The Seductive Simplicity of "Just Do It"

The appeal of "strategy is delivery" is obvious. It cuts through bureaucratic paralysis. It demands action over endless planning cycles. It puts user needs at the centre.

These are good things. Especially in environments where strategy had become synonymous with lengthy documents gathering dust while the world moved on. GOV.UK remains an important example of what focused delivery can achieve.

But somewhere along the way, the message mutated. "Strategy is delivery" became "strategy is only delivery." The implicit claim shifted from "stop hiding behind strategy" to "strategic thinking is unnecessary overhead”. And that's where we've gone badly wrong.

What Strategy Actually Requires

Real strategy is not a document. But it's not something that emerges automatically from iterative delivery. Strategy requires things that cannot be invented on the fly:

• Deep analysis. Understanding your competitive landscape, your capabilities, your constraints, and the forces shaping your environment takes time and rigorous thinking. You cannot sprint your way to insight about deep issues such as geopolitical shifts in technology supply chains, the changing economics of AI infrastructure, or the regulatory pressures that will shape your operating context for the next decade.

• Negotiation and agreement. Strategy in any organisation of scale is not the vision of a single leader. It emerges from difficult conversations, competing priorities, and hard-won consensus. These negotiations take time. They require building relationships, understanding different perspectives, and finding genuine alignment. They are not just superficial agreement in a sprint retrospective.

• Judgement born of experience. The wisdom comes from knowing which opportunities to pursue and which to decline, when to move fast and when to exercise caution, and what to build and what to buy. These judgements cannot be learned in a two-week iteration. They come from years of accumulated experience, from having seen what works and what fails, from understanding not just the technical possibilities but the human and organisational realities.

•  Governance and accountability. Strategic decisions have long-term consequences. They commit resources, foreclose alternatives, and shape organisational direction for years. Such choices require proper governance with clear accountability, appropriate oversight, and mechanisms for course correction. Agile ceremonies are not a substitute for board-level strategic governance.

The AI Amplifier

This matters more than ever in the age of AI. The technology decisions organisations make today will shape their capabilities, costs, risks, and competitive position for years to come. Consider just a few of the strategic questions that cannot be answered by delivery alone:

How much of your AI capability should be built versus bought? What are the long-term implications of dependency on a small number of foundation model providers? How do you balance the productivity benefits of AI against workforce implications? What data governance frameworks need to be in place before you scale? How do you position yourself given the uncertainty about AI regulation across different jurisdictions?

These are not questions you can A/B test your way through. They require strategic thinking by applying analysis, judgement, and governance that operates on a different timescale than sprint cycles.

The irony is that the very organisations that pioneered "strategy is delivery" are now grappling with the consequences. The recent UK government review of digital services found that digital strategies too often set out ambitious visions while failing to put in place the performance targets, funding, tools and systems required to deliver them. The problem wasn't wasting time on too much strategy: it was strategy disconnected from the hard work of implementation planning and resource commitment.

Finding the Balance

None of this is an argument for returning to the bad old days of strategy as a substitute for action. The pendulum doesn't need to swing back to endless planning cycles and analysis paralysis. But neither should we pretend that strategy emerges spontaneously from rapid iteration.

The most effective organisations I work with have learned to hold both truths simultaneously. They maintain a clear strategic direction, grounded in deep analysis, properly governed, and built on experienced judgement, while executing with agility and responsiveness to what they learn along the way. They understand that Mintzberg was right: realised strategy is always a combination of the deliberate and the emergent. But they also understand that without the deliberate, the emergent is just drift.

Strategy is not just delivery. Strategy enables delivery. Strategy gives delivery direction, purpose, and coherence. Without a strategy, delivery becomes an activity without achievement, in danger of being activity without progress.

In a world being reshaped by AI, we need both. We need the courage to act and the wisdom to think. We need sprint velocity and strategic patience. We need teams empowered to deliver and leaders capable of genuine strategic thought.

The organisations that will thrive are those that resist the false choice. They will be neither paralysed by planning nor lost in tactical busyness. They will deliver with purpose, but guided by a strategy that deserves the name.