Blog 03 · Generative AI in business

Vibe Coding: What Happens to a Business When Nobody Reads the Code

• Posted · 4 Aug 2026

The story. In early 2026 a founder built an entire social network, Moltbook, without writing a line of code himself. He described what he wanted, an AI wrote it, and he shipped it. Researchers at Wiz soon found its production database open to anyone, exposing 1.5 million access tokens and 35,000 email addresses, because a basic access-control layer was never switched on (Nagli, 2026). The code worked. That was the problem.

This is “vibe coding”, the most seductive use of generative AI in business right now. Two weeks ago I argued a business rents its infrastructure. Last week, its ERP. This week, the twist: a small firm can finally stop renting and start building. The only question is who reads what the machine writes.

What is vibe coding?

The term comes from Andrej Karpathy, who in early 2025 described “fully giving in to the vibes”: letting an AI write the software while you steer in plain English. By year’s end Collins had made it their word of the year (Collins, 2025). The developer stops being a typist and becomes an editor, orchestrating and verifying rather than writing (Sarkar & Drosos, 2025). Or is meant to.

Why would a business do this?

The economics are extraordinary: in files where GitHub’s Copilot is switched on it now writes close to half the code (GitHub, 2023), and the barrier to building software has collapsed. For the takeaway I am advising, this is the good news the last two posts lacked. Peng no longer has to rent every tool; he can have a loyalty app or a rota dashboard built in an afternoon, cheaply, and keep the customer data in-house. A recent review places its real strength in exactly this kind of rapid prototyping (Sapkota et al., 2025). That shift, where technology changes what a firm can make, not just how fast, is what Vial (2019) calls digital transformation.

So what is the catch?

An AI optimises for code that runs, not code that is safe. Veracode’s tests of more than 100 models found 45% of the AI-generated code failed basic security checks (Veracode, 2025), and Georgia Tech now tracks flaws traced to AI coding tools: the count climbed from six in January 2026 to thirty-five by March (Georgia Tech, 2026). Moltbook was not a clever attack. It was a wall nobody built, because the machine was never told to, and nobody noticed it missing.

So can it be used ethically?

Yes, but on purpose. The answer is not to ban vibe coding, which wastes a real gift, but to move the human from typist to gatekeeper. That means three rules. Treat every line the AI writes as an untrusted first draft. Never let it near logins, payments or customer data without a human review first. And set a written policy on approved tools and data, so development never runs as unseen “shadow AI” (IBM, 2025). “It runs” is not the same as “it is safe”, and when data is exposed it is the business, not the AI, that is accountable.

Why it matters here

Peng’s transformation is about finally owning his customer data, and vibe coding is how a firm his size can afford the tools that hold it. But the moment code touches that data, someone has to read it. Blog one said do not blindly rent. Blog two said read the exit clause. This one is simpler still: if you are going to build, read the code.

Blog 02 · “What the paper says” critique

What the Paper Says: The Cloud ERP and the independence it trades away

• Posted · 19 Jul 2026

The paper. Alsharari, N. M., Al-Shboul, M. & Alteneiji, S. (2020). Implementation of cloud ERP in the SME: evidence from UAE. Journal of Small Business and Enterprise Development, 27(2), 299-327. Via the Salford library. doi.org/10.1108/JSBED-01-2019-0007

Last week I argued that switching cloud provider is easier to type than to do. This week I found a paper that shows what that dependence looks like from inside a small business. Alsharari and colleagues watched a firm in the UAE move its ERP into the cloud, and their quiet finding is the one that should worry any small owner: it works, and then it takes a little piece of you back.

What the paper says

The setup is one UAE firm, studied as a qualitative case: in-depth interviews, coded into themes, sorted into three familiar buckets, technological, management and environmental. The question is practical. Should a small business move its ERP off its own servers and into the cloud, and what happens when it does? Broadly, yes. Cloud ERP runs the place better and sharpens its decisions, without the upfront cost of a server room. Then the sentence that matters: effectiveness “is reliable on the provider’s professionalism”, and that reliance starts to “minimise organisational independence”. The tool bought for control quietly takes some back.

Is the question worth asking?

Very, and for the takeaway I am advising in my report, almost too neatly. Peng runs eight shops on paper and gut feel, and my recommendation is a cloud ERP. So a paper on exactly that move, in the region half my examples come from, lands right on target. The framing is the standard TOE lens. Fine, but notice it is used to describe one firm’s story, not to test a claim.

Is the method strong enough?

This is where it strains, and the authors are honest about it. They admit outright that the study “lacks rigor and generalisation”, and the design earns that. It is a single firm, and they concede they could not interview more people because the roles there were barely separated. You cannot count the interviews or trace how the themes were weighed, so you could not reproduce this if you tried. One company’s experience is a story worth hearing. It is not yet a pattern.

Are the conclusions supported?

Partly. The benefits are plausible, but they rest on the impressions of a few insiders, not on anything measured. And the most interesting result, the dependence on the provider, is named in a single line and then dropped. It is vendor lock-in wearing a new coat, the exact risk last week’s paper was built around, yet the two never meet. That is an under-emphasised idea doing far more work than the authors notice.

Does it still hold in 2026?

Yes. In 2020, “dependence on the provider” reads like a footnote about service quality. In 2025 it stopped being abstract. When AWS lost a single region in October and Cloudflare misfired in November, the McDonald’s app and, closer to this paper’s home, Talabat and Careem simply stopped taking orders. That is “reliance on the provider’s professionalism” with the lights off. Layer on the AI now bolted onto every ERP, learning from the data you hand across, and the independence this paper worried about in one sentence has become the whole conversation.

Why it matters here

So I still recommend cloud ERP for Peng. I just recommend the open-source kind he can export and walk away from, not a suite that owns him back. Read the paper, then read the exit clause. That is where a small firm’s independence actually lives.

Blog 01

When the Cloud Goes Down, Dinner Stops: Cloud Dependency in Last-Mile Delivery

• Posted · 12 Jul 2026

In July 2026, the Bank of England, the Prudential Regulation Authority and the Financial Conduct Authority started policing Amazon, Microsoft, Google and Oracle directly, naming them critical third parties to the UK financial system. Read that again: the guardians of British financial stability have formally admitted the backbone is rented from four American firms, and that if one falls over, so does a chunk of the economy. Food delivery did not need a regulator to work this out. This was found out three months earlier, on an ordinary evening, when the apps simply stopped taking orders.

The system behind the app

Here is the thing people miss. When a takeaway or a delivery platform "goes digital", it does not build software. It rents it, by the second, from a hyperscaler. Cloud computing is on-demand, network-delivered computing that a business scales up and down without ever touching the hardware (Mell & Grance, 2011). What a delivery operation actually rents is a whole stack:

• an ordering front end, the app or site the customer taps;
• an API and message queue that takes the order and must never lose it;
• a managed database of menus, baskets and historical orders;
• a CRM housing customer information and preferences;
• an identity service that knows who is logged in;
• a dispatch engine that picks the kitchen and the rider;
• a CDN and DNS layer sitting in front, routing every request.

The customer sees none of it. But all of it, together, is the information system the business runs on.

Why a business rents it

Because the numbers are hard to argue with. Cloud turns the capital cost of servers into an operating cost that rises and falls with demand, which drops the barrier to entry for small firms and lets them pay for serious capacity only when they need it, on the Friday-night rush (Armbrust et al., 2010; Marston et al., 2011). It also cuts the time to ship a new feature from months to an afternoon. And it quietly decides who owns the customer. Every order placed on your own channel hands you first-party data, the basket size, the reorder gap, the moment someone stops coming back, that an aggregator would otherwise keep for itself, along with a double-digit slice of every order (Rivera, 2019). Own the channel and you keep the customer. Rent it from an aggregator and you are renting your own customers back. That shift, where technology changes how value is created rather than just speeding up the old way, is what Vial (2019) means by digital transformation.

When it goes down: McDonald's

Now the catch. The same architecture that makes all this cheap and fast also stacks the risk in one place.

On 20 October 2025, one AWS (Amazon Web Services) region, us-east-1, ran into trouble and took more than a thousand services down for about fifteen hours. Across Britain, people opened the McDonald's app, tapped order, and got nothing. The restaurants were fine. The grills were on and the staff were in. The failure was in a data centre in Northern Virginia that none of them had ever seen. And here is the uncomfortable part: it was not a cyberattack, just a routine change moving through a tightly coupled system. Plenty of the firms that went down believed they were safe because they ran in more than one region, yet their databases and logins still quietly resolved through the region that had failed.

And in the UAE: Cloudflare and Talabat

A month later it happened again, from a different direction. On 18 November 2025, a bad configuration file inside Cloudflare, which carries roughly a fifth of the world's web traffic, knocked services offline around the world. In the UAE, where almost everyone orders dinner on a phone, that meant people simply could not place orders on Talabat, Careem or Noon. Same shape of failure: not an attack, just a tiny internal change with an enormous blast radius. And once your data, identity and services are wound around one provider, leaving is slow and expensive, so the dependency only deepens (Opara-Martins et al., 2016). Multiply that across a whole market and it becomes systemic: when everyone leans on a handful of providers, a single outage can take the sector with it (Financial Stability Board, 2019). Which is exactly what the Bank of England decided it could no longer ignore.

So what?

The cloud is not the villain here. The tight coupling that makes it cheap and quick is the same coupling that makes it fragile; they are two sides of one coin. No serious food business is going back to its own servers, and it should not. The move is not to opt out but to manage the dependency: know which of your "multi-region" systems secretly lean on a single region, hold a real exit in your contract, and keep a degraded mode so the kitchen can still take money when the platform blinks. Because when the cloud goes down, dinner stops. Unless you planned for the night it does.