I need to say something that might be unpopular: I genuinely admire what vibe coding has done.

The ability to describe a website in plain English and watch it materialise in front of you is extraordinary. Tools like Cursor, Bolt, Replit, and Lovable have made it possible for someone with no programming background to produce a working prototype in minutes. That's not hype — it's a genuine shift in what's possible.

A quarter of the startups in Y Combinator's Winter 2025 batch had codebases that were 95% AI-generated. Collins Dictionary named "vibe coding" its Word of the Year for 2025. By some estimates, 41% of all code written in 2025 was AI-generated. The barrier to getting something live has never been lower.

But here's where the story gets complicated. I've used vibe-coded websites myself. The initial experience was electric — a site that looked credible, functioned properly, and existed within an hour. Then I tried to do SEO work on it. I couldn't find where things lived. I couldn't control the heading hierarchy. I couldn't trace which files governed which sections. The architecture wasn't bad — it was absent. What looked like a building was actually a stage set.

And that's the distinction this post is about. Not whether AI can build websites — it obviously can. But whether AI-built websites can survive the things that come after launch: content updates, SEO, accessibility compliance, security requirements, stakeholder scrutiny, and the quiet accumulation of maintenance decisions that determine whether a site is infrastructure or disposable.

The cost moved — it didn't disappear

The promise of vibe coding is that it eliminates the cost of building. And for prototyping, that's largely true. But for anything that needs to be maintained, the cost hasn't disappeared. It's relocated.

Every content change on a vibe-coded site requires a prompt. Every prompt consumes tokens. Output tokens — the code the AI writes back to you — are typically three to five times more expensive than input tokens. AI-native application spending soared 108% in 2025, and the average organisation's OpenAI API bill now sits at around $384,500 per year. Even at the cheapest tier, a team making regular content updates through an AI coding tool is paying per interaction, indefinitely.

Compare that to a well-built Webflow site. Your Communications Director logs into the CMS Editor, changes a paragraph of text, and publishes. No prompt. No tokens. No risk of the AI rewriting your navigation whilst fixing a typo. The cost of that edit is zero — because the architecture was designed to make content updates a governed, independent action, not an AI transaction.

The barrier to entry for building hasn't lowered. It's shifted from build time to edit time. And the people bearing that edit cost are often the least technical members of the team — the ones who were told AI would make everything easier.

Using AI without prior knowledge is expensive

This is the part that rarely gets discussed. Vibe coding tools respond to the quality of the prompt. A developer with ten years of experience who prompts an AI to scaffold a component gets dramatically better output than someone who's never written a line of code.

The AI doesn't fill in the gaps in your knowledge. It amplifies whatever understanding you bring to the conversation. If you don't know what WCAG AA compliance requires, the AI won't build it in by default. If you don't understand what a heading hierarchy is, the AI will generate one — but it might be semantically meaningless. If you don't know what schema markup does, you won't think to ask for it.

The result is that people without prior technical knowledge burn through tokens at a much higher rate — prompting, getting wrong output, re-prompting, getting slightly less wrong output, and eventually accepting something that looks right but isn't. The AI is a brilliant tool in the hands of someone who already understands web architecture. For everyone else, it's a very expensive guessing game.

This is precisely why a consultant who understands your institutional context matters more, not less, in the age of AI. The value isn't writing the code. It's knowing what to ask for.

The security problem nobody warned you about

In May 2025, a security researcher scanned 1,645 web applications built using the vibe coding platform Lovable. Of those, 170 — roughly one in ten — had critical security vulnerabilities that exposed users' personal data. The leaked information included names, email addresses, phone numbers, payment details, and API keys. The vulnerability was severe enough to earn a formal CVE designation (CVE-2025-48757) and a critical severity score of 9.3 out of 10.

The root cause wasn't exotic. It was a database configuration that the AI had generated without proper security rules. The people who built those applications had no idea their users' data was exposed, because they'd never been taught to check. Lovable later introduced a security scanner — but it only checked whether a security policy existed, not whether it actually worked. By early 2026, a separate assessment of over 200 vibe-coded applications found that 91.5% contained at least one vulnerability traceable to AI-generated code.

These aren't edge cases. Research consistently shows that 40–62% of AI-generated code contains security vulnerabilities, and AI-written code produces flaws at 2.74 times the rate of human-written code.

For any organisation that handles donor data, beneficiary information, or payment processing — which is to say, every nonprofit with a website — this is an institutional risk that no amount of speed justifies. Security isn't a feature you bolt on after launch. It's an architectural decision that needs to be made before a single line of code is written.

A managed platform like Webflow handles SSL certificates automatically, runs on AWS infrastructure with Fastly CDN, requires no plugins, and maintains the hosting environment without any action from the site owner. There is no database to misconfigure, no server to patch, no security policy to forget. The attack surface is fundamentally smaller — not because Webflow is magic, but because the architecture eliminates entire categories of risk that vibe-coded applications inherit by default.

Nobody owns the architecture

One of the most revealing accounts of vibe coding came from a Stack Overflow writer who built an app using Bolt. It took about ten minutes to create. It looked great. It also didn't work — error messages appeared immediately. When experienced developer friends reviewed the code, their main feedback was that it was messy and nearly impossible to understand.

This is a pattern I see consistently. The AI generates something that functions in demo conditions, but the underlying structure was never designed — it was assembled. There's no consistent naming convention. No documented component system. No logical separation between layout, content, and behaviour. The code works, but it can't be maintained by anyone who didn't prompt it into existence — and often not even by them.

Simon Willison, the creator of Datasette and one of the most thoughtful voices on AI in development, put it plainly: vibe coding may work for throwaway weekend projects, but most of what we do as engineers involves evolving existing systems, where the quality and understandability of the underlying code is crucial.

For a nonprofit website that needs to serve multiple stakeholder groups — institutional funders checking governance credentials, donors completing donation flows, beneficiaries accessing service information, regulators verifying compliance — the architecture isn't a technical detail. It's the mechanism that makes all of those journeys possible simultaneously. When nobody owns that architecture, nobody can guarantee any of those journeys work.

Award-winning sites are still built by humans

If AI-built websites were genuinely competitive with human-designed ones, we'd expect to see them winning awards. We don't.

The Awwwards Site of the Year 2025 went to the Lando Norris website, built by the agency OFF+BRAND. The Developer Site of the Year went to Messenger, a WebGL experience hand-crafted with custom physics and lighting. Bruno Simon's portfolio — a browser-based 3D environment where visitors drive a vehicle to navigate — earned Site of the Month in January 2026. Every one of these sites was built by humans who made deliberate architectural, creative, and technical decisions that no AI could have prompted into existence.

This isn't about gatekeeping. It's about recognising what "building a website" actually means for an organisation that needs its site to hold up under real scrutiny. A vibe-coded prototype and a governance-grade institutional website aren't the same category of thing. One is a sketch. The other is infrastructure.

What a well-built platform actually gives you

I choose Webflow because it solves the problems that vibe coding creates — not by being anti-AI, but by providing a governed platform where AI's strengths can be used without its weaknesses becoming institutional liabilities.

A well-built Webflow site, implemented on the Lumos accessibility framework, gives you a CMS where your team can update content independently without writing a prompt or spending a token. It gives you a documented class system where every component has a name, a purpose, and a predictable behaviour. It gives you WCAG AA accessibility as a structural foundation, not an afterthought. It gives you managed hosting — AWS, Fastly CDN, automatic SSL, zero server maintenance. It gives you a governance framework where roles, permissions, and editorial workflows are explicit.

And critically, it gives you a site that doesn't degrade every time someone makes an edit. The architecture is stable because it was designed to be stable. The CMS is editable because editability was a design requirement. The site is accessible because accessibility was built into the framework from the start.

When I run a technical SEO audit on a Webflow site built properly, the heading hierarchy is clean, the meta data is controllable, the URL structure is predictable, and the CMS fields map to the content strategy. When I tried to do the same on a vibe-coded site, I spent more time understanding what the AI had generated than it would have taken to build the thing properly from scratch.

The honest position

AI is excellent technology. I use it daily. I use it for first-draft copy, for prototyping layout ideas, for generating schema markup, for research. It's a genuine force multiplier when used within a governed system by someone who understands what they're asking for.

The problem is AI as architect — as the thing that determines the structure, the security model, the accessibility foundation, and the maintenance workflow for a website that an organisation depends on. That's not what AI is good at, and pretending otherwise creates institutional risk that compounds silently until something breaks publicly.

If you're a Communications Director at an NGO with £500K to £10M in annual income, your website isn't a side project. It's institutional infrastructure that donors scrutinise, funders audit, regulators check, and your Board is accountable for. The question isn't whether you can build it with AI. The question is whether you can govern it.

The first step in rehab is admitting that a website isn't a product you build once. It's infrastructure you maintain. And maintenance requires architecture, ownership, and a platform that was designed to support it — not one that was prompted into existence and hoped for the best.

If your organisation's website is approaching a period of scrutiny — leadership transition, funding growth, regulatory attention — and you're not confident in what donors and funders see when they visit, the Blueprint Audit is designed to give you that clarity. It's a structured diagnostic that identifies what's actually failing, maps your stakeholder priorities, and produces a Board-ready report with specific findings. It costs £2,500, it stands alone, and the report is yours regardless of what comes next.