The site went into vibe coding: the time bomb Berto doesn't see

There's a biting cold this morning in Santa Maria Capua Vetere, the kind of damp that gets into your bones and doesn't let go until midday. I'm sat under the portico near the Criminal Court, on Via G. Bonaparte. The pale stone columns and the red-brick building behind me seem to soak up the uncertain light of this October 2025. Opposite me, beyond the already-packed car park, stands the white, modernist façade of the Court, with its horizontal bands of windows straight out of the 1970s. The traffic noise on the main road is a constant hum, a carpet of sound made up of distant horns and revving engines. In front of me sits my coffee, served in a thick ceramic cup. It's going cold, and I'm letting it die there, because all my attention is fixed on the man sitting across the table.

This is Berto. He's an archetype, but he's also flesh and blood. Big hands, marked by decades of work in the workshop, nails that still carry the dark shadow of engine grease despite being scrubbed with abrasive paste. Berto is one of those blokes who built his business from nothing, tightening bolts and signing promissory notes back when credit was a dirty word. He's got an ancestral distrust of anything digital. Back in 2012, some self-styled "web agency" swindled him out of five thousand euros for a Flash site that never worked and that Google indexed as a permanent 404 error. Ever since then, as far as he's concerned, anyone who does my job is, until proven otherwise, a snake-oil salesman. He needs to look you in the eye before trusting you with so much as a business card, let alone his company's communications.

And yet, this morning, Berto is smiling. A wide, satisfied, almost childlike grin. He's pulled his smartphone out of his coat pocket and pushed it towards me, sliding it across the metal table. "Look at this, Umberto," he says, tapping his thick index finger on the screen. "My nephew knocked this together in a weekend. A weekend, mind you. He used artificial intelligence. Didn't even have to write the code, just talked to it. And it cost him half your quote."

I glance down at the screen. The site is, objectively, gorgeous. The transitions are smooth, the CSS is spotless, the buttons have that lovely little hover effect that gives a sense of solidity and modernity. There's an elegant contact form, a reserved area for suppliers, a seamless map integration for finding his warehouses. Visually, it's top marks. His nephew, armed with a prompt and an advanced language model, generated in forty-eight hours what a team would've taken weeks to build.

I don't say anything, not straight away. I pick up the cup, take a sip of coffee that's now cold and bitter, and keep scrolling through the page. What Berto sees is a triumph of efficiency and savings. What I see, on the other hand, is a ticking time bomb hidden under a carpet of beautiful pixels. My mind immediately runs to how that artificial intelligence structured the database, how it handled authentication, where it stored the API keys. I know full well that "vibe coding" — the practice of building software by describing its feel and function to an AI — isn't the devil incarnate. It's an extraordinary tool. But I also know that shipping that code with no checks whatsoever, putting it into production and trusting it with real customer data, is one of the most lethal mistakes a business can make today. And the biggest problem is that Berto, with his craftsman's eye trained to judge a job by how solid it looks on the outside, doesn't have the tools to spot the structural cracks in that code. He doesn't know he's sitting on a powder keg.

He doesn't know it yet, that October morning. And truth be told, back then, I didn't fully know it either: it would only take the following months to turn that suspicion into a documented certainty, complete with names, dates and precise figures.

What vibe coding actually is, and why it's not his fault he didn't know

I didn't make up the term "vibe coding" for effect. It was coined by Andrej Karpathy, one of the heavyweights of global artificial intelligence, back in early 2025. The idea behind it is as fascinating as it is unsettling: you no longer need to learn the complex syntax of Python, JavaScript or Rust. You don't need to spend hours hunting for a missing semicolon or sorting out library conflicts. You just need a "vibe", an idea, a clear vision of what you want, and to write it down in plain English. "I want an app that does this, with a minimalist design, dark colours and a database for users." The AI does the rest. Within seconds, it generates thousands of lines of working code.

This has caused an explosion, a drastic lowering of the barrier to entry. Suddenly, anyone with an idea and an internet connection can describe an application and watch it materialise on screen. It's a democratic revolution, and as such it's chaotic, powerful and dangerous. If you fancy digging deeper into the dynamics of this revolution and how similar tools are shaking up the market, I'll point you to my piece No-code: finally you can build your own website without asking anyone's permission (but do it properly), where I look at the fine line between technological emancipation and disaster waiting to happen.

The fundamental problem, and the reason I can't blame Berto for his enthusiasm, is the vast gap between a prototype with no process behind it and a properly built product put into production. Mind you — I'm not saying that AI-written code is inherently poor. OpenAI, Anthropic, Google, and platforms like Cursor or Replit themselves ship huge volumes of AI-generated or AI-assisted code into production every single day. The problem isn't the artificial intelligence. It's artificial intelligence used without the process that surrounds it in those contexts: review, testing, threat modelling, maintenance, clear accountability over who checked what. When Berto's nephew generates a site in a weekend without any of these steps, what he ends up with is a prototype that looks like a finished product — and the difference between the two isn't visible to the naked eye, it's visible in the code. In practice, language models tend to favour code that works over code that defends itself, particularly when the prompt doesn't explicitly ask for security requirements: they generate the happy path (the user clicks and everything works), but ignore the dark paths (the hacker injects malicious code or tries to bypass authentication), unless someone explicitly asks them to lock it down.

To help you get your head round it, let's use a metaphor we know well here in Campania. Picture a master carpenter in Caserta, one of those blokes who's been working wood for fifty years. If you ask him to make you a bedside table for the spare room, he might use poplar or veneered chipboard. It's light, it's cheap, it does the job, and if you put a lamp and a book on it, it'll hold up perfectly well. But if you ask that same carpenter to build the load-bearing beam for your roof, he'll never use poplar. He'll go and find solid oak, or seasoned chestnut. Because he knows the beam has to bear the weight of the tiles, the force of the wind, the load of snow. It has to withstand structural stress over time. The carpenter matches the material and the building technique to the function and the risk involved.

Artificial intelligence, when it does vibe coding without precise instructions, isn't the master carpenter. It's a lightning-fast, enthusiastic apprentice who builds in poplar by default, because poplar cuts quicker and polishes up in no time — not because it doesn't know how to work oak. If you ask it with the right expertise, the AI can write excellent code, often better than a junior developer's. The point is that if nobody tells it which beam it's building, it picks the fastest material. A prompt that generates a personal blog where you post your holiday photos isn't, and can't be, the same prompt that generates the form through which your customers enter company data, bank details or confidential information. The structure has to be different. The level of security has to be infinitely higher.

But Berto's nephew isn't a software engineer. He's a sharp lad who's good with prompts. He asked the AI to build the load-bearing beam of the roof, and the AI built it for him in poplar, painted to look like oak. And Berto, looking at the glossy paint job and the perfect assembly, thinks he's got a safe house. He doesn't know that at the first storm, the roof will come crashing down on his head, taking his business, his customers' data and his reputation with it. And the fault doesn't lie with the apprentice (the AI), but with whoever decided to use a poplar prototype to bear the weight of a real business without having a master check the work.

The cases nobody can deny: when vibe coding goes into production

In technical pieces, theory alone never cuts it. You need the smell of blood, the detail of when things smash into the wall of reality. I remember exactly where I was when I first read about the Moltbook disaster. It was a Tuesday evening, late January 2026. I was in my studio in Campania, it was chucking it down outside and the wind was rattling the windows. I was scrolling through cybersecurity feeds on my main monitor, the blue light straining my eyes, when I came across a report that made my blood run cold.

Moltbook: 1.5 million credentials exposed in 72 hours

According to reconstructions by several cybersecurity outlets (including Arnica and OX Security), Moltbook was the promise of the new decade: an AI-based social network, built entirely by a single founder who openly boasted about never having written a single line of code by hand. All vibe coding. All generated by prompts. The interface was stunning, the features were cutting-edge. The launch was a massive media success. But the glory lasted exactly 72 hours. Within three days of launch, according to the same sources, 1.5 million API authentication tokens and over 35,000 users' email addresses had been publicly exposed. Anyone with even a modest level of technical know-how could download the entire database.

The cause? An error of staggering simplicity. The database had been set up on Supabase (a brilliant platform, when used properly), but the AI hadn't configured "Row-Level Security" (RLS) — an issue that falls under the OWASP "Security Misconfiguration" category, one of the most recurring entries in the world's most serious security risk rankings. The AI had written the code to make the connection work, but hadn't written the rules to say: "User A can only see User A's data, not User B's." It had simply thrown open the vault doors to anyone walking past. This is what happens when you hand over your architecture to a machine that optimises for speed, not security.

I'm not saying this from some high horse. Years ago, right at the start, I made the exact same mistake on a much smaller scale. A third-party plugin installed on a client's site to handle newsletter sign-ups, set up in a rush because the deadline was looming, with the login credentials left on default. I spotted it myself, thankfully, a week later, while checking the site logs for a reason that had nothing to do with security. No harm done, in the end. But the cold shiver down my spine when I realised what I'd left wide open for seven days — I remember it like it was yesterday. Ever since then, I double-check what I'd rather take for granted just once.

Lovable: 170 business projects left open for 48 days

But Moltbook wasn't an isolated case. A few months later, in April 2026, the Lovable case broke, officially registered as CVE-2025-48757. Lovable is a brilliant platform that lets you build web apps by writing prompts. The vibe coding dream made real. And yet, according to the account reported by TheNextWeb, every single project created before November 2025 remained completely exposed for a full 48 days. What does "exposed" mean? It means that any user registered with a free account could access the source code of any other user on the platform. They could read database credentials, private chat history with the AI, sensitive customer data. Over 170 business projects breached, cracked open like tins of tuna, without needing to be a professional hacker. All it took was five basic API calls.

Base44, Tea app, Replit: when all it takes is a URL or a hallucination

And the list is long and well documented. Take Base44, July 2025: several private business applications built on the platform were exposed because authentication could be bypassed by manipulating the App ID, publicly visible in every URL — a classic case of "Broken Access Control," the number one category in the OWASP ranking. Or think of the Tea app, also in 2025: an application built largely with AI-generated code that, according to accounts circulated on Reddit and picked up by several industry outlets, exposed users' private messages due to an access control logic generated without any security review. Even Replit, one of the giants of the cloud development ecosystem, saw — according to several AI security sources — its own AI agent (which had rashly been given direct access to the database) carry out destructive operations, wiping out a user's production database off its own back over a logic error.

I have to be intellectually honest here. I'm citing cases involving public platforms, consumer applications, Silicon Valley start-ups. Not the SME site in Caserta or Berto's workshop management system. But the technical mechanism behind these disasters is exactly the same. The dynamic of the error is identical. Artificial intelligence, when generating code, is focused on showing you a result on screen as quickly as possible. It doesn't concern itself with adding security checks, input sanitisation, permission segregation logic, unless you ask for it with the surgical precision of a software architect. And if you don't know how to ask, because you're a tech-savvy nephew and not an engineer, the AI won't tell you. It'll hand you your time bomb with a smile, ready to go off.

Why your SME site has the exact same problem even if you're not building a social network

At this point, I can already hear Berto's objection, the same one the average Italian business owner would raise. "Umberto, but I'm not trying to build the next Facebook! Mine's just a brochure site. A few pages explaining what we do, our services, and a little contact page for people to send us quote requests. What do I care about all these millions of tokens and this American nonsense?"

It's a logical objection, but a deeply mistaken one. Let's translate the theory into everyday business practice. That "simple" contact form the nephew got the AI to generate in five minutes isn't just a bit of screen graphics. That form collects first names, surnames, email addresses, phone numbers and perhaps the specific requests of your potential customers. Where does that data end up? To save time, the AI might have hooked it up to an unprotected database, writing the data in plain text with no encryption whatsoever. Worse still, it might have created a hidden admin panel, so Berto can conveniently read the messages from his browser, but without implementing any real authentication. The AI might have thought: "Just hide the link from the main menu, and nobody will find it." In our line of work, this is called "Security by obscurity," and it's the digital equivalent of hiding the safe key under the doormat with a lit-up sign pointing to exactly where to look.

But it's not just theory. The data confirms the risk is systemic. In the Veracode 2025 GenAI Code Security Report, researchers tested over a hundred large language models (LLMs) across a standardised set of coding tasks. The result: in 45% of cases, the generated code contained security vulnerabilities linked to the notorious OWASP Top 10. This doesn't mean "45% of all AI-written code in the world" is riddled with holes — it means that, across a large, controlled test sample, nearly one answer in two contained a security flaw traceable back to the world's most serious risk rankings. The practical message for Berto doesn't change: if you take that code and paste it into production with no review, you're gambling.

And if you think 45% sounds like a lot, a parallel study carried out by the Cloud Security Alliance, also in 2025, found security flaws in over 60% of fully AI-generated code solutions tested in their sample. Why the difference in percentages? The two studies use different samples and methodologies, and I haven't found a direct comparison that explains the gap with any certainty — so I won't make one up. What matters, and what both studies confirm, is the order of magnitude: whether it's a rigged coin toss (45%) or a near-certain conviction (60%), you're playing Russian roulette with your company's entire body of information.

But the figure that ought to send a proper chill through Berto, and anyone else who got their site done "for free," landed in May 2026. Wired published the findings of research carried out by Red Access, a cybersecurity firm. Researchers scanned over 5,000 "vibe-coded" applications and websites that had been properly deployed and made publicly available online. They found that roughly 40% of these exposed sensitive data in a totally uncontrolled way. And we're not just talking about social networking apps. We're talking about medical records, financial data, confidential company documents, quotes, customer databases.

How does this happen? Often, the credentials for accessing the database, or the API keys for connecting to payment services, get written in plain text directly into the frontend code — the code sent straight to the user's browser. To Berto, the site looks perfect, but anyone who opens his site and presses F12 to "inspect the element" can read those keys as easily as reading the paper. From there, it takes ten seconds to seize total control of the company database. And believe me, there aren't hackers in hoodies out there wasting time looking for Berto's site. There are automated bots, silent scripts scanning millions of websites a second, hunting for exactly these digital signatures left unguarded by the artificial intelligence. When they find the open door, they walk in, copy everything, and leave you a lovely little ransom note. Or worse, they say nothing at all and sell your customers' data on the dark web.

The hefty bill from GDPR (Article 32, Article 33) — and who foots it

At this point, the conversation over that cold coffee in Santa Maria Capua Vetere has to move onto ground the business owner understands perfectly: legal liability and money. Because technology might sound abstract, but fines are incredibly concrete.

In Europe, and therefore in Italy, you can't handle people's personal data however you fancy. There's the GDPR, a regulation that doesn't tolerate ignorance and doesn't go easy on anyone relying on improvisation. Let's set aside the legalese and speak plainly. There are two articles Berto needs to have drilled into his head: Article 32 and Article 33.

Article 32 (Security of processing) sets out an unambiguous principle: whoever handles the data must put in place "appropriate technical and organisational measures to ensure a level of security appropriate to the risk." Note the wording: "appropriate to the risk." If you're collecting emails and phone numbers, you need basic protections. If you're collecting health data, or sensitive information, you need to lock the system down tight. Code generated by AI in a weekend, with no encryption and keys sitting in plain text, isn't an appropriate technical measure. It's serious negligence.

But it's Article 33 (Notification of a personal data breach) where things get properly hairy. If Berto's site gets breached, and the customer database is exposed or stolen (the infamous data breach), Berto has no more than 72 hours from when he becomes aware of it to notify the incident to the Data Protection Authority (Garante). Seventy-two hours, not a day more. If it happens on a Friday evening, by Sunday morning you'd better already have the paperwork ready to report that your data's been nicked.

But who's legally responsible? Who pays when things go wrong? The nephew who built the site using prompts? The artificial intelligence that generated the code? The companies behind the language models? Absolutely not. The one responsible remains the Data Controller — from an administrative standpoint first and foremost, facing the sanctions set out under GDPR; and, in cases provided for by law, potentially also from a civil or criminal standpoint. In other words, the company. In other words, Berto. The law doesn't allow for technological buck-passing. If you choose to use an insecure tool to process your customers' data, the fault is entirely yours.

And here we reach the uncomfortable bit, but one I have a duty to address head-on given my position. How much did Berto actually save? Maybe €1,500, maybe €2,000, by skipping a proper agency (if you're curious about the market logic behind these prices, I'll point you to the piece How much does a website really cost). He feels clever, thinks he's optimised his costs.

But what's the real cost of that saving? GDPR sets out two tiers of sanctions: a higher one, up to 4% of global turnover or €20 million, reserved for the most serious breaches (such as failing to observe basic processing principles or data subjects' rights); and a lower tier, up to 2% or €10 million, which is exactly where a breach of Article 32 falls — inadequate security measures, Berto's case. The Authority always applies a principle of proportionality, and for an SME the figure stays a long way from those ceilings. But even staying well below the maximum, the total bill — the fine, the solicitor's fee, the hours lost dealing with the emergency, the urgent system clean-up — very nearly always comes in well above that €1,500 saved on the original quote.

And that's just the direct financial damage. Let's talk about the reputational damage. GDPR requires that, in serious cases, Berto has to tell his customers their data has been stolen. Picture the scene: Berto having to pick up the phone, or send a registered letter, to tell his best supplier or his long-standing client: "Sorry, you know that new site I was so proud of? Well, a total stranger's downloaded all your invoices and bank details because my nephew forgot to put a password on the database." In that moment, the awkward ten-second silence that follows will be the sound of Berto's credibility crumbling for good. That €1,500 saving suddenly becomes the loan shark's rate of the worst deal Berto's ever signed in his life.

London, same story, different accent

Let's leave the porticoes of Caserta for a moment. I want to take you eleven hundred miles away, to show you this dynamic isn't some quirk of "Southern Italy" or the provinces. It's a structural pandemic that crosses nations and business cultures, changing only the dialect used to justify the mistake.

It's a rainy Thursday evening in London, in Southwark. I'm in a traditional pub a stone's throw from Borough Market. The air's thick, smelling of toasted malt, stale beer spilt on dark wooden tables and roast meat drifting over from the closing stalls at the market. It's warm in here, the chatter's deafening, but the man sitting across from me has a faraway look. The pint of stout in front of him is going warm, its head gone flat, ignored for at least twenty minutes.

His name's Bobby. He's an established professional, an accountant who manages the portfolios of dozens of small business owners across Manchester and Salford. Bobby hasn't got a tech-savvy nephew. His work culture's different from the Italian one. We Italians often rely on blood ties, on the "cousin" or the nephew, because in the fabric of our SMEs, family is the first safety net of trust (even when that trust is misplaced). In England, Anglo-Saxon pragmatism translates into an unshakeable faith in the hyper-fast transactional economy.

Bobby needed a small bespoke CRM and a portal for his clients to securely upload their tax documents. He did what everyone in London does: he went on Fiverr, the global freelance platform. He found a "Full Stack AI Developer" (a title made up out of thin air) who promised him the whole system in 48 hours for just £200. Bobby paid up, the developer fired off a couple of well-crafted prompts into a language model, and two days later Bobby had his CRM. Clean, tidy, functional.

Exact same story. Exact same mistake. The £200 developer hadn't the faintest idea how cloud storage bucket security policies worked. He left the read permissions on the tax documents open to the public. The AI didn't flag it, because the prompt said "get the upload working," not "protect the upload with encrypted tokens."

The result? A disaster. The only difference between Italy and the UK is the accent of whoever notifies you of the fine. In the UK, UK GDPR applies, a piece of legislation that mirrors the European one (post-Brexit, the core rules stayed intact). Bobby, too, was bound by the unforgiving 72-hour rule. He, too, had to deal with the supervisory authority, which in the UK is called the ICO (Information Commissioner's Office).

Bobby hadn't noticed a thing until one of his biggest Salford clients rang him up furious: he'd just received an extremely sophisticated phishing email, containing precise details about his latest tax returns. Details that, in theory, only Bobby should have had. The attacker had found the vibe-coded portal, downloaded the PDFs without so much as needing a password, and was now blackmailing the clients.

As Bobby runs his hands through his hair, telling me how the ICO's breathing down his neck and how his professional indemnity insurance is refusing to cover the damages given the blatant IT negligence, I see the exact geometry of the problem laid bare. Berto in Caserta blindly trusts family ties; Bobby in Manchester blindly trusts the speed of the global market. Both use vibe coding as a magic shortcut to bypass the cost of structural expertise. And both end up smashing into the exact same brick wall of reality. Technology has no borders, but sadly, neither does incompetence when it comes to security.

What to do before going live (the practical checklist that saves your skin)

The point of this piece, like all the work I do at Insight ADV, isn't to scaremonger or tell you that modern technology is rubbish and we should all go back to writing sites in plain HTML with Notepad. Artificial intelligence and vibe coding are game-changing tools. They can tenfold your productivity, cut development costs, and let you iterate ideas at a speed that was pure science fiction just three years ago.

The point isn't to stop using AI. The point is to fold AI into a proper engineering and procedural process. Before a single external user sets foot on your shiny new prompt-built site, you need to lock down the foundations. Here's the practical checklist I use myself, and apply to every project at the agency. If your developer, or your nephew, doesn't know what we're talking about, stop everything right now.

1. Never paste .env files or real credentials into an AI chat

This is the mother of all mistakes. The .env file is where the secret keys, database passwords and payment tokens live. When you're vibe coding, it's dead easy to copy your entire codebase into an AI model to help fix a bug. If that code contains the real password for your production server, and the environment you're using hasn't been vetted and approved under proper company security policy (this changes with properly configured enterprise tools), you've just handed it straight to a public language model. Only use fake (mock) credentials while generating code. Real keys only ever go on the production server, entered by hand and encrypted.

2. Row-Level Security (RLS) switched on for every database, always

If you're using modern back-ends like Supabase, Firebase or similar, RLS isn't optional. It's the difference between life and death for the project. It's not enough to authenticate the user at the app level — you need to tell the database, right down at the deepest level: "Refuse any read or write request unless whoever's making it actually owns that specific piece of data." A generic prompt usually skips this step entirely. You have to enforce it yourself.

3. Admin panels always sit behind proper authentication

Got the AI to build you a panel for viewing incoming enquiries? Lovely. Now open an incognito browser window and paste in the URL for that panel. If it opens and you can see the data, you're wide open. Authentication needs to be handled via server-side middleware (code that checks permissions before loading the page), not simply hiding the links from the interface.

4. Draw a hard line between AI draft and production code

The golden rule is this: artificial intelligence writes the first draft. A competent human carries out the security review. Under no circumstances whatsoever should you deploy AI code into production that hasn't been read, validated and tested line by line by a developer who understands what's going on under the bonnet. It's the difference between writing a novel and publishing it without an editor ever having touched it.

5. A proper quote always includes a line item for "Security Testing"

And here I'll openly declare my position, and my conflict of interest: this is exactly what I do. At Insight ADV, I don't hand over a black box and hope it doesn't blow up. I deliver a tested system. In a proper agency's quote, the time spent on security validation, backup configuration (a subject I went into at length in the piece Backup isn't a precaution: it's your site's fourth wall), and vulnerability checks is an explicit cost line. If that line's missing, they're not selling you a website. They're selling you a problem waiting to happen.

It's not black magic, and it doesn't need a million-pound budget. It's a matter of process. Prompt, Build, Security Testing, Human Review, Deploy. If you skip the testing and human review stage to save time or money, you're simply writing a blank cheque to the next automated bot that comes knocking at your server.

My firm position, and it isn't changing

Whenever the talk turns to technological innovation, there's always the temptation to soften your stance towards the end, to wrap things up with the usual reassuring "it depends on the context," "it's a tool still evolving," "there are pros and cons."

But I believe a firm position is the only real service I can offer the people who read me. Whoever lands on the Insight ADV blog doesn't want a neutral summary or an impartial referee. They want to know what someone who bangs their head against these problems every day actually thinks — someone who takes responsibility for putting systems online that have to withstand the full force of the market.

In my experience, the problem isn't artificial intelligence. I'm no Luddite — I use LLMs every day, I explore their capabilities and I admire the power of vibe coding as a creative accelerator. The genuinely dramatic problem in our industry is the illusion of competence these tools create in people who don't have the technical grounding to manage them. The problem is thinking that writing code and understanding secure system architecture are the same skill.

They're not. Writing code is syntax. Understanding security is structural engineering. AI, as things stand, is superhumanly brilliant at the former, but demands constant, paranoid, technically watertight supervision for the latter. Selling you, or letting you be sold, a site built entirely on vibe coding as if it were a finished, secure product is an intellectual con. Low-cost marketing — the kind that leans on technological shortcuts to destroy the professional value of the industry — isn't just unfair competition: it's a public danger to the businesses that fall for it.

I often think back to that October morning, especially now that I know how things turned out for Moltbook, for Lovable, for everyone who made the exact same mistake on a much bigger scale. My mind goes back to that little table in Santa Maria Capua Vetere. The coffee's frozen solid by now, undrinkable. I look at Berto. I see in him all those business owners who break their backs every day to make the numbers work, to keep families and staff afloat, and who deserve respect and the truth, not comfortable reassurance.

I pick up his smartphone. I close the preview of that beautiful, dangerous site and set it down on the table in front of him. I look him straight in the eye.

"Berto," I say, keeping my voice low but firm. "Visually, it's a masterpiece. Your nephew's got a great eye, and he's sharp. But technically, this site is an open door onto your company's vault, and you've left the keys in the lock. If you put this live today, in a month's time you might have to explain to the Data Protection Authority, and to your long-standing customers, why their data ended up all over the internet."

What follows is that awkward ten-second silence. A dense silence, in which the noise of the cars on Via G. Bonaparte suddenly seems deafening. It's the exact moment the illusion cracks. Berto folds his arms, the furrow on his brow deepens. He's got it. He doesn't need to know what RLS stands for, or read Wired's articles. He's understood that the real job can't be knocked together in a weekend, not even with the help of the cleverest machine on earth.

If your site was built recently, in record time, on a shoestring budget, with promises of all-powerful AI, stop for a moment. Before someone else finds that site first, get it checked over by someone who knows how to read what's underneath the glossy paint job on the frontend. A check-up costs infinitely less than a breach notification.