Digital Economy Dispatch #275 -- If Everyone's Vibe Coding, What Will It Mean For Britain's AI Future?

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.