Claude, Lovable, and Gemini Can Build a Website. Here’s the Part They Can’t.

Type a prompt, wait a few minutes, and a working website comes back. Pages, forms, a real design, sometimes a full database behind it. That is not an exaggeration and it is not a strawman. It is what these tools actually do in 2026, and for a first version of a site, they do it well.

So this is not an argument that AI can’t build you a website. It can. This is about what happens starting around month three, after the twentieth or fiftieth small change you ask it to make, once your speaking career has actually moved forward and your site needs to move with it.

Every claim below is sourced, dated, and specific. None of it depends on AI being bad at what it does today. It depends on what the data already shows happens over time, to real projects, measured by people who build software for a living.

The real problem isn’t editing. It’s what editing does to code nobody fully understands.

Engineering research in 2026 has a name for this: the “Spaghetti Point.” A site built entirely by prompting moves fast for the first few weeks. Then, typically around the third month, complexity catches up. Adding a new feature starts breaking an existing one, because the code was never built around an underlying structure. It was built as a series of prompts, each one solving a single request in isolation, with no memory of why the last ten decisions were made.

This is not a guess or an opinion. It is what the data shows, from multiple independent sources in 2026.

The scale of the problem, measured directly. GitClear analyzed 211 million lines of code changed across real repositories between 2020 and 2024, tracking the shift as AI coding tools became standard practice. Duplicated code rose 48 percent over that period. Code that actually gets refactored and properly reused fell by more than half. Duplicated code carries 15 to 50 percent more defects than code that was properly reused rather than copy-pasted. 2024 was the first year on record where copy-pasted code outpaced code that got properly cleaned up and improved.

What happens after the code ships. Lightrun’s 2026 State of AI-Powered Engineering Report surveyed 200 senior site-reliability and DevOps leaders across the US, UK, and EU. 43 percent of AI-generated code changes required manual debugging in production, even after the code had already passed quality assurance and staging tests. Not one of the 200 organizations surveyed could verify an AI-suggested fix worked with a single redeploy. 88 percent needed two to three redeploy cycles. 11 percent needed four to six.

Why debugging AI code specifically takes longer. This is the part that explains everything else. 45.2 percent of developers report that debugging AI-generated code takes longer than fixing code a human wrote from scratch, and the reason given is consistent across sources: the AI tool does not understand the full context of the project. It solves the prompt in front of it without checking whether a similar solution already exists elsewhere in the codebase, or whether the fix conflicts with a decision made three prompts ago. A separate 2026 security analysis found AI-generated code carries 2.74 times more vulnerabilities than code written by a human, and that professional trust in AI-generated code’s accuracy has fallen sharply, from over 70 percent positive sentiment a few years ago down to 29 percent trusting it on first pass today, even as more developers use these tools than ever.

What this looks like in practice, for a site like yours. Your website is never finished. Every new event adds a testimonial. Every pivot adds a keynote topic. Every award, every press mention, every updated bio photo is another prompt back into the same tool. The first handful of those edits go fine, because the codebase is still small and simple enough for the AI to hold most of it in view at once. What the research above describes is what tends to happen by the fifteenth or fortieth edit: the tool has no persistent memory of why an earlier prompt built something a particular way, so a request as ordinary as “add this new testimonial” can quietly alter a form, a layout, or a page that was already working, with no warning until a visitor or an event organizer hits the broken part.

This is the actual cost. Not that AI can’t make the edit today. That the probability of an edit breaking something else rises with every change you have already made, and the tool has no way to warn you when that threshold gets closer.

What AI Cannot Do, Even When the Code Works Perfectly

Separate from the maintenance problem above, there is a judgment problem, and this one has nothing to do with how capable the tool eventually becomes. A prompt can write flawless code for a homepage and still produce the wrong homepage, because writing code and making a business decision are not the same skill.

Here are the specific calls a speaker’s website actually requires, calls that come from understanding your positioning and your audience, not from generating correct syntax.

Which topic leads. If you speak on three different subjects, which one should headline your homepage for a healthcare audience this month, versus a tech audience next month? The AI has no way to know which of your topics is currently in higher demand, which one aligns with where event budgets are moving this year, or which one your best recent testimonials actually support.

Whether your fee appears on the page at all. Early-career speakers often benefit from listing a fee range to filter serious inquiries. Established speakers often benefit from removing it entirely, to avoid anchoring a negotiation too low. This decision depends on where you are in your career and what your last five negotiations looked like, not on anything a prompt can infer.

Which testimonial goes above the fold. You likely have several. One might be the most impressive name. Another might be the most specific about outcomes. A third might be from an event nearly identical to the one you are trying to book next. Choosing correctly requires knowing who is actually reading the page, which the AI does not know unless you already know it and tell it directly, at which point you have done the actual strategic work yourself.

How the site should read to one specific kind of organizer. A corporate leadership conference and a university commencement committee are evaluating you on almost entirely different criteria, even if your keynote content overlaps. A generic AI-built site, optimized for describing you accurately in general, does not make this adjustment on its own.

What belongs on the page and what doesn’t. Every additional page, every additional line of copy, is a decision about what earns a visitor’s limited attention. AI tools, left unguided, tend to include everything you tell them about, because they have no independent judgment about what actually helps versus what dilutes the page. A person who has watched hundreds of these decisions play out knows what to leave out.

The pattern across all five: AI can execute a decision once you have already made it. It cannot make the decision for you. And if you already know the right answer to all five of these, the tool never needed to make that call in the first place, which raises the real question of what exactly you were paying for.

The security data is not hypothetical

In a widely reported 2026 incident, a vulnerability in applications built with Lovable, a missing basic database access control, exposed data across more than 18,000 users and over 170 different apps. That is not one unlucky project. It is a pattern.

The broader numbers back this up. AI-generated code has been found to carry 2.74 times more vulnerabilities than human-written code, and separate 2026 research puts the rate of AI-generated code containing security vulnerabilities at 45 to 48 percent. A 30-day experiment conducted in early 2026 using Claude and Cursor saw coding speed increase fivefold, and alongside it, critical security flaws appeared, including passwords stored in plain text and exposed API keys, the kind of mistake a website builder tool will not flag for you because it is not designed to.

This matters specifically for a speaker’s site because of what it actually collects. Every inquiry form gathers a name, an organization, an event date, and often a budget range. Course or book sales run through a payment gateway. If you work with European clients or organizers, GDPR compliance is not optional, and a site with an unreviewed security gap is not compliant just because it looks finished. This is not a corner case. It is the ordinary data every working speaker website handles every week.

The discoverability gap, and why it is getting more expensive to ignore

Search engine performance is measurable, and the gap is not small. Only 43 percent of sites built on automated AI platforms passed Google’s 2025 performance threshold, compared to 86 percent on a properly optimized WordPress build. AI tools handle surface-level SEO reasonably well, metadata, basic page titles, but they consistently fail at the structural depth that actually drives rankings: internal linking between related pages, content architecture that signals topical authority, and technical performance tuning that a generated site was never specifically built around.

There is a newer version of this problem that matters even more in 2026. Event organizers are increasingly asking ChatGPT or Perplexity directly, “who should I book to speak at a leadership conference about employee engagement,” and getting two or three names back with no further scrolling or comparison involved. What determines which names get returned is what the industry calls signal density: consistent, specific, structured content across your site that an AI system can actually extract and cite with confidence, the same structure covered in our guide on AEO vs SEO for speakers. A thin, generic AI-generated site, built to look complete at a glance rather than to be cited by another AI system later, has nothing distinctive for these tools to pull from. Traditional search volume is forecast to drop meaningfully as this shift continues, which means a site invisible to AI search is not a future problem. It is a present one.

The boring argument, and also the hardest one to dispute

If a platform raises its prices, changes its terms of service, or shuts down entirely, a site built completely inside that platform’s own tooling goes down with it, and rebuilding starts from zero, with no warning and no migration path guaranteed. A WordPress site avoids this by design. The code, the content, and the database are yours, on hosting you choose, portable to a different provider at any time without anyone’s permission.

This is the least dramatic argument in this entire post. It is also the one that requires no interpretation and no statistic to defend. Either you own what you built, or you are renting the ability to use it.

What changes when a person builds it instead

None of this means AI tools are without a real use. For a weekend project, a placeholder page, or testing whether an idea is worth pursuing before committing real time to it, they are truly useful and fast, and pretending otherwise would be dishonest.

The difference with a site built by someone who has done this specifically for speakers, over and over, is not that the code is magically bug-free forever. It is that every decision, from which topic leads the homepage to how the media kit is structured to what happens when you need to add your fortieth testimonial two years from now, comes from someone who already knows the answer instead of guessing at one, and who is still there when something needs to change. This is the same approach covered in more detail in our post on why keynote speakers should hire StageNexa.

Can AI tools like Claude or Lovable actually build a working speaker website?

Yes, and quickly. These tools can generate a functional site with real pages, forms, and design in a single session. The limitation is not day-one capability. It is what happens to that code over the following months as more changes are requested, and whether the underlying strategic decisions, which topic to lead with, which testimonial to feature, whether to show a fee, get made correctly without a person who understands your specific positioning.

Is it true that AI-generated code is less secure than human-written code?

Yes, based on multiple independent 2026 studies. AI-generated code has been measured to contain roughly 2.74 times more vulnerabilities than human-written code, with 45 to 48 percent of AI-generated code samples failing security tests in separate analyses. A documented 2026 vulnerability in Lovable-built applications exposed data across more than 18,000 users. This matters directly for a speaker site, since inquiry forms and payment flows collect real personal and sometimes financial data.

Why does editing an AI-built website get harder over time instead of easier?

Because AI coding tools generate a solution for the specific prompt in front of them without checking whether a similar piece of code already exists elsewhere, or whether the new code conflicts with an earlier decision. Industry research tracking this describes a “Spaghetti Point,” typically around three months into a project, where adding a new feature starts breaking existing ones. Nearly half of developers report that debugging AI-generated code takes longer than fixing human-written code specifically because the tool does not retain full context of the project as it grows.

Do AI website builders hurt SEO and search visibility?

Meaningfully, yes. Only 43 percent of sites built on automated AI platforms passed Google’s 2025 performance threshold, compared to 86 percent for properly optimized WordPress sites. AI tools tend to handle basic metadata reasonably well but miss the structural depth, internal linking, content architecture, technical performance tuning, that actually drives both search rankings and citation by AI search tools like ChatGPT and Perplexity, which organizers increasingly use directly to find speakers.

What happens to my website if the AI platform I used changes its pricing or shuts down?

If your site was built entirely inside that platform’s own tooling, you are typically left rebuilding from zero, since there is no guaranteed way to export a fully working, portable version of what you had. A WordPress site avoids this because the code, content, and database are yours outright, on hosting you choose, and can move to a different provider at any time without needing anyone’s permission or losing functionality in the process.

Is a human-built website worth it if I only need a simple site?

For a short-term placeholder or a way to test whether an idea is worth pursuing, an AI-built site can be a reasonable starting point. The calculation changes the moment your website needs to keep evolving alongside a real, ongoing speaking career, since that is exactly the pattern, repeated edits over months and years, where the data above shows AI-generated codebases accumulate risk fastest.