Tvorba webu pomocí AI pod lupou: co zvládne a kde narazí

Když dnes hledáte způsob, jak vytvořit web pomocí AI, narazíte na celou řadu nástrojů, které slibují hotový výsledek za pár minut – někdy zdarma. Pokud podnikáte a web potřebujete, je to lákavé: proč platit desetitisíce, když to zvládne stroj?

Rozhodl jsem se to ověřit na vlastním testu. Vzal jsem tři prompty – od dvouřádkového zadání po pořádný brief s předlohou – nechal AI vygenerovat tři weby a porovnal je řádek po řádku. Nešlo o řízený experiment s opakováním a statistikou, ale o konkrétní ukázku, co se stane, když se zadání liší. Tento článek je její výsledek – tři výstupy, srovnání toho, co každý zvládl, a seznam věcí, které ve všech chyběly.

Nechce se vám dlouze číst? Poslechněte si to.

Audio souhrn hlavních myšlenek článku v délce 27 minut a 33 sekund. Najdete v něm přehled nástrojů na tvorbu webu pomocí AI, rozdíl mezi slabým promptem a pořádným briefem, srovnání tří výstupů a to, proč je AI nejrychlejší cesta k prototypu, ale ne k provozu. Audio si můžete stáhnout přímo z přehrávače tlačítkem se šipkou dolů.

Čím se dnes generují weby na několik promptů? Aplikace, služby a nástroje

Pod pojmem „tvorba webu pomocí AI" se míchají různé způsoby práce. Chatovací asistent na pokyn navrhne obsah nebo kód. Builder přidá vizuální editor a někdy i publikování webu. AI editor či agent může pracovat přímo se soubory projektu a spouštět nástroje. Tyto kategorie se mohou překrývat. Lokální běh modelu je jiná otázka: říká, kde model běží, ne jaký typ produktu používáte.

Chatovací asistenti pro návrh a generování kódu

V těchto službách zadáváte úkol v chatu. Mohou navrhnout text, ukázat kód nebo vytvořit prototyp; možnosti exportu, publikování a dostupné modely se liší podle služby, plánu i regionu.

Lokální modely: model a prostředí pro jeho běh

Open-weight popisuje dostupnost vah modelu, ne hotovou chatovací aplikaci. Některé takové modely lze spouštět lokálně pomocí prostředí jako Ollama nebo LM Studio. Data zůstávají na zařízení jen tehdy, když lokálně běží i model a připojené nástroje neposílají vstupy do cloudu. Lokální provoz obvykle neúčtuje poplatek za každý dotaz, ale vyžaduje vhodný hardware a spotřebovává elektřinu.

AI buildery pro weby a aplikace

Builder spojuje generování s vizuálním editorem; některé služby zajišťují také hosting a publikování. Liší se ale v tom, co lze exportovat, kde výsledek běží a co je zahrnuto v tarifu. Před výběrem si proto ověřte podmínky konkrétní platformy.

AI editory a agenti pracující s projektem

Tyto nástroje se propojí s kódovým projektem. Asistent může doplňovat nebo navrhovat změny; agent navíc může podle nastavení prohledávat soubory, upravovat je a spouštět příkazy či testy. Rozsah přístupu a míra samostatnosti se liší, proto je potřeba výstupy kontrolovat.

Tyto skupiny se překrývají: jeden produkt může nabídnout chat, editor, agenta i publikování. V tabulkách je proto dělím podle hlavního způsobu práce, ne podle modelu, který běží na pozadí. Pro test jsem zvolil agenta, který mohl pracovat se soubory projektu; výsledek tak ukazuje právě tuto kombinaci nástroje a zadání.

Prompt aneb jak AI zadat, co má udělat

Ať zvolíte jakýkoliv nástroj z předchozích tabulek, jedno mají společné: výsledek stojí a padá se zadáním. Prompt – pokyn v přirozeném jazyce, případně doplněný obrázkem, souborem nebo odkazem – je hlavní způsob, jak AI říct, co chcete. A právě tady vzniká největší omyl celé „tvorby webu pomocí AI": lidé čekají, že nástroj pochopí záměr. Nepochopí. Nezná vaše nevyřčené obchodní skutečnosti a z kontextu je nedokáže spolehlivě ověřit.

Prompt je ve skutečnosti brief – stejná disciplína jako zadání pro vývojáře, designéra nebo copywritera. Čím vágnější zadání, tím generičtější výsledek. Řeknete-li „udělej web pro instalatéra", AI doplní zbytek podle naučených vzorů – jako by brala z průměru internetu: vymyšlené recenze, nonstop pohotovost, „váš spolehlivý partner". Všechno zní věrohodně, nic z toho nemusí být pravda. Právě proto vypadají weby z AI jako jedna rodina.

Dobrý prompt pro web obsahuje účel stránky, cílovou skupinu, seznam sekcí a tón komunikace. A hlavně věci, které nesmí chybět nebo naopak nesmí obsahovat: skutečné kontakty místo placeholderů, žádné vymyšlené reference, žádné sliby, které neplníte. Rozdíl mezi „udělej web" a pořádným briefem je rozdíl mezi demem a použitelným základem.

A poslední věc: prompt není jednorázový. První výstup je draft, ne finále – zpřesňujete ho dalšími pokyny a vracíte mu chyby k opravě. Další iterace ale může chybu opravit i zavést novou, proto je potřeba výsledek pokaždé zkontrolovat. O tom víc v sekci o testu.

Jak vypadá rozdíl v praxi – stejný web, dvě zadání:

Vytvoř mi jednoduchý web pro instalatéra v Brně.
Sekce: služby, o nás, reference, kontakt.

Proč je první zadání slabé:

• Nedefinuje publikum ani účel. AI neví, kdo na web přijde a co má udělat – sekce proto naplní nejobvyklejším obsahem z internetu.
• Nedodává jediný skutečný údaj. Kontakty, ceny, roky praxe ani jméno firmy v něm nejsou – model je typicky vymyslí.
• Nezakazuje nic. Bez zákazu vymyšlených recenzí a slibů je AI doplní sama – zní věrohodně, což je pro model cíl.
• Neřeší technický výstup. Žádná zmínka o SEO metadatech, funkčním formuláři nebo formě souboru – takže ve výstupu často chybí.

Zkusme to tedy ještě jednou – tentokrát mnohem přesněji, jako pořádný brief. Údaje jsou modelové, nejde o reálnou firmu:

Web pro živnostníka „InstalatérBrno" – jednostránkový, česky.
Publikum: domácnosti v Brně a okolí, hledají opravu nebo havárii.

Sekce:
- hero: název firmy, telefon +420 777 123 456 jako tel: odkaz,
  CTA „Nezávazná poptávka" s kotvou na #kontakt
- služby: opravy vodovodu, havarijní servis, rekonstrukce koupelen
- o mně: živnostník, pracuji sám, bez týmu
- ceník: výjezd po Brně 300 Kč, hodina práce 600 Kč
- kontakt: formulář (jméno, telefon, zpráva) + e-mail a adresa

Podmínky:
- žádné vymyšlené recenze, reference ani počet let praxe
- žádné sliby „24/7" – pracuji Po–Pá 7–16 hodin
- doplň title a meta description
- jeden soubor HTML s CSS, responzivní

Druhé zadání trvá napsat možná dvě minuty navíc, ale rozdíl ve výsledku je zásadní: AI nemá prostor pro vymyšlené recenze, falešné sliby ani placeholder kontakty, protože dostala konkrétní údaje a explicitní zákazy. Pořád to není hotový web (chybí doména, hosting i fotky), ale jako draft pro další iteraci je nepoměrně použitelnější.

Co z toho plyne pro vás: výsledek „tvorby webu pomocí AI" neurčuje jen nástroj, ale kombinace modelu a promptu. Stejný prompt dá v jiném modelu jiný web – a stejný model z jiného promptu taky. Pokud se vám výstup nelíbí, nemusíte hned měnit službu: často stačí zpřesnit zadání, případně zkusit jiný model. Většina nástrojů v tabulkách má dostupnou vrstvu zdarma, takže základní porovnání vás stojí jen čas; tarify ale mohou omezit dostupné modely, funkce a počet použití.

A ještě třetí varianta, která se v praxi objevuje často – vzít existující web jako předlohu:

Najdi si web na adrese example.com a převezmi veškeré stylování
a hlavní navigaci. Vytvoř mi statickou stránku HTML, která bude
obsahovat kotvy: Úvod, Moje služby, Cenová nabídka, Reference
a Kontakt. Celý návrh musí být kompletně responzivní a musí
dodržovat pravidla přístupnosti.

Technicky to je slušné zadání: říká formát (statická HTML stránka), ukotvuje strukturu přes kotvy a explicitně žádá responzivitu i přístupnost – přesně to, co prvnímu promptu chybělo. Dvě věci ale stojí za pozornost. Zaprvé si model web na zadané adrese „najde" jen tehdy, když umí načítat stránky a daná stránka je přístupná (example.com je v ukázce jen zástupná adresa – v praxi tam patří web, který se vám líbí) – čistý chatbot bez nástrojů si vzhled prostě vymyslí a může předstírat, že předlohu viděl. Zadruhé: kopírovat cizí design 1:1 je autorskoprávní i obchodní riziko. Předloha se hodí jako reference struktury a stylu, ne jako stránka k přepsání.

Tento typ promptů se také hodí v situacích, kdy chcete udělat kompletní redesign webu a nevíte, jak začít. Namísto hledání inspirace po desítkách stránek stačí ukázat svůj současný web nebo vzor, který se vám líbí – a nechat si navrhnout novou strukturu a vzhled, který pak doladíte.

Použít cizí web jako inspiraci je něco jiného než převzít jeho texty, fotografie, logo nebo konkrétní grafické zpracování, které může být chráněno - ochrana konkrétního prvku závisí na obsahu a okolnostech. Co lze použít, závisí na konkrétním obsahu, licenci a případném souhlasu; širší kontext autorského práva a AI shrnuje také Ministerstvo kultury. A ani převzaté rozvržení, které napohled vypadá hezky a funkčně, nemusí splňovat vaše cíle nebo fungovat pro vaše zákazníky.

Od teorie k praxi – tři prompty, tři výstupy

Všechny tři prompty z předchozí sekce jsem otestoval na stejném zadání – jednoduchý web instalatéra v Brně. Generoval je stejný nástroj (vývojářský agent, se kterým pracuji denně) a výstupy jsem pak prošel řádek po řádku a porovnal stejnými kritérii. Otázka zněla: jak moc rozdíl v promptu změní výsledek?

Pro poctivost testu: žádný z výstupů jsem neopravoval ani nedolaďoval. Každý soubor je přesně to, co AI vydala na první pokus.

Výstup 1: web ze slabého promptu

Jeden soubor, 115 řádků, 6 kB. Na první pohled překvapivě dobrý: modrý hero s gradientem, karty služeb, recenze, kontaktní formulář, patička. České texty bez chyb, responzivní layout. Ručně by podobná stránka znamenala den práce – tady zhruba třicet sekund (můj odhad, ne měřený čas).

Pod pokličkou ale demo, ne web. Formulář nemá action – po odeslání se data standardně odešlou metodou GET na aktuální stránku, ale bez backendu nedoručí poptávku. Telefon není odkaz. Web tahal tři externí služby – Tailwind z vývojářského CDN, Font Awesome a fotku instalatéra přímo ze serveru Unsplash (může kdykoliv zmizet a navíc předává IP návštěvníků třetí straně). A hlavně: AI doplnilo mezery fikcí – „více než 15 let zkušeností", „jsme tu pro vás 24/7" a tři recenze se jmény, která nikdy neexistovala.

Výstup 2: web z pořádného briefu

Podobná velikost (120 řádků), ale obsahově jinde. Telefon jako funkční tel: odkaz, meta description, skutečný ceník ze zadání, pracovní doba Po–Pá místo „24/7". Žádné vymyšlené recenze – prompt je zakázal. A protože jsem chtěl „jeden soubor HTML s CSS", žádné externí CDN: celý web je soběstačný.

Zajímavé je, co chybělo pořád: formulář má sice action, ale jen placeholder # – data se po odeslání odešlou na aktuální stránku (GET), ale bez handleru nedoručí poptávku a mohou se objevit v URL. Žádné <label> prvky, žádné ARIA atributy, žádné OG tagy. Brief pokryl obsah a poctivost, ale přístupnost ani technické detaily jsem v něm nežádal – a nedostal je.

Výstup 3: web podle předlohy

Třetí prompt jsem trochu zvýhodnil: místo example.com jsem jako předlohu podstrčil svůj vlastní web. A protože nástroj, který jsem použil, umí stránky skutečně načíst (na rozdíl od čistého chatbota, který by si vzhled vymyslel), výsledek předlohu skutečně převzal: petrolejový akcent, přilepená navigace, karty s tónovaným podkladem, dokonce štítek „Nejoblíbenější" nad cenovým balíčkem. Se 178 řádky nejrozsáhlejší výstup ze všech tří.

A protože prompt explicitně žádal některé prvky přístupnosti, výstup obsahoval skip-link pro uživatele čteček, <label> u každého pole formuláře, aria-expanded na mobilní navigaci a aria-labelledby u sekcí. Jde o konkrétní prvky, ne o úplné posouzení přístupnosti; požadavky shrnuje například standard WCAG 2.2 (W3C, anglicky).

Přesto i tady zůstala díra: sekce Reference obsahuje vymyšlené citace – sice anonymní („Zákazník z Brna"), ale pořád fikce. Prompt žádal přístupnost, ne poctivost obsahu. A telefonní odkaz? V promptu nebyl – a ve výstupu taky ne.

Srovnání tří výstupů

Tabulka řekne víc než další odstavce:

Čtení je jednoduché: každý výstup reflektoval, co prompt žádal - a doplnil, co v něm nezakázal. Slabý prompt nechal prostor pro fikci a AI ho zaplnila. Brief výmysly zakázal, a tak se neobjevily – ale přístupnost chyběla, protože ji nikdo nežádal. Předloha dostala přístupnost, protože ji prompt vynutil – a přesto si vyrobila recenze, které nikdo nezakázal.

Prompt tedy není jen „popis, co chcete". Je to filtr: co v něm necháte volné, AI doplní podle naučených vzorů – jako by brala z průměru internetu; co v něm zapomenete zakázat, AI si klidně vymyslí.

A poslední věc, kterou tabulka ukazuje možná nejzřetelněji: ani jeden ze tří výstupů nemá funkční formulář, OG tagy ani strukturovaná data - chybí věci, které dělají web použitelným pro firemní účely. Tři různé prompty, tři různě kvalitní soubory – ale hotový firemní web z nich pořád není ani jeden. Doména, hosting, odesílání formulářů, pravdivý obsah a údržba se mezi souborem a webem neudělají samy. Základní pravidla pro strukturovaná data popisuje dokumentace Google Search Central (česky).

Tabulka neřeší ještě jednu dimenzi, která se provozu webu dotýká přímo: rychlost. Google měří tři metriky zvané Core Web Vitals - LCP (načtení hlavního obsahu do 2,5 s), INP (reakce na interakci do 200 ms) a CLS (posun layoutu pod 0,1) - a používá je jako rankingový signál. Jednoduchý HTML soubor z testu výše tyto limity pravděpodobně splní, protože je malý a bez JavaScriptového frameworku. AI buildery ale často generují aplikace s těžkým JavaScriptem, velkými CSS frameworky a renderováním na straně klienta - a ty CWV často nesplňují. Rychlost není vizuální záležitost; Google ji měří na reálných uživatelích (anglicky), ne na screenshotu z editoru.

Právní a bezpečnostní rizika už při práci s prototypem

Práva a odpovědnost za obsah

Do zadání dávejte jen texty, fotografie a další podklady, které vlastníte, máte k nim licenci nebo souhlas k použití. Cizí web může posloužit jako inspirace, ale nepřebírejte bez dovolení jeho texty, fotografie, logo ani konkrétní grafické zpracování. U výstupu si ověřte podmínky služby pro komerční použití. Ty samy o sobě nezaručují, že je výsledek jedinečný, že nezasahuje do práv někoho dalšího nebo že máte k výstupu výhradní práva. Širší kontext autorského práva k AI výstupům v EU shrnuje také brief Evropského parlamentu (PDF, anglicky). Před sdílením prototypu ověřte tvrzení, reference a sliby - i návrh může někdo považovat za skutečný.

AI Act nestanoví obecnou povinnost označit každý běžný text na firemním webu jako vytvořený AI. Zvláštní pravidlo se týká například AI textů zveřejněných za účelem informovat veřejnost o věci veřejného zájmu, pokud neprošly lidskou kontrolou a redakční odpovědností. Pokud by se takový text měl později zveřejnit, ověřte, zda se na něj pravidlo vztahuje; Evropská komise vysvětluje rozsah těchto povinností (anglicky).

Přístupnost a zákon

Od 28. června 2025 platí v EU Evropský zákon o přístupnosti (EAA), v ČR transponovaný jako zákon 424/2023 Sb. Zavádí povinnost zpřístupnit weby a služby pro spotřebitele, včetně e-commerce. Výjimku mají mikropodniky - podniky s méně než 10 zaměstnanci a ročním obratem do 2 milionů EUR (nebo bilanční sumou do 2 milionů EUR); tato výjimka se vztahuje pouze na služby, nikoliv na výrobky. Přechodné období pro produkty a služby uvedené na trh před 28. červnem 2025 běží do 28. června 2030. Podrobnosti včetně dalších výjimek (nepřiměřená zátěž, zásadní změna) uvádí Ministerstvo průmyslu a obchodu. AI generovaný web typicky nesplňuje ani základní úroveň WCAG 2.2 AA - přístupnost je potřeba zkontrolovat a doplnit ručně.

Ochrana dat a bezpečnost kódu

Do AI nástroje nevkládejte hesla, přístupové klíče, smlouvy ani osobní či neveřejné údaje zákazníků, dokud neověříte podmínky konkrétní služby: jak vstupy ukládá, kdo k nim může mít přístup a zda je používá ke zlepšování modelů. U osobních údajů je potřeba posoudit také právní důvod a způsob jejich zpracování; pomoci může účinná anonymizace nebo vynechání údajů, které zadání nepotřebuje (pseudonymizace, např. nahrazení jména kódem, údaje osobními nečiní). Podobnou opatrnost při práci s AI a citlivými údaji doporučuje také NÚKIB. I prototyp může obsahovat nedůvěryhodný kód. Před jeho spuštěním nebo předáním zkontrolujte externí skripty a knihovny, přístupové údaje, formuláře a to, kam se odeslané informace skutečně ukládají. Tato kontrola prototypu nenahrazuje bezpečnostní kontrolu finálního webu, který se podle postupu v další části staví znovu.

AI generovaný kód může vypadat funkčně, ale přitom obsahovat známá bezpečnostní rizika: XSS (neescapovaný výstup do innerHTML nebo dangerouslySetInnerHTML), SQL injection (řetězení dotazů místo parametrizovaných prepared statements), chybějící CSRF ochrana, otevřené přístupové údaje v kódu nebo nevalidované vstupy z formulářů. Studie z roku 2026, která porovnávala kód od čtyř AI modelů, našla 64 bezpečnostních zranitelností - 62 z nich kritických nebo vysokých. OWASP proto vydala přehled bezpečnostních rizik AI asistovaného kódování (anglicky): AI generuje kód, který vypadá hotový, ale chybí v něm bezpečnostní kontrola, kterou vývojář přidává zkušeností, ne ze vzoru. V roce 2026 vyšlo i několik CVE zranitelností přímo v AI nástrojích, kde modelový výstup bez sanitizace umožnil XSS útok - například CVE-2026-25802 (prompt injection to stored XSS v LLM gateway new-api) nebo CVE-2026-17496 (XSS přes neescapovaný HTML výstup modelu v NoteGenu). Kontrola kódu před nasazením není formalita - je to jediná vrstva, která AI výstup odděluje od produkčního webu.

Před předáním prototypu dál ověřte, že:

• AI jste neposlali citlivé údaje nebo přístupové klíče,
• ukázkové údaje a reference jsou zřetelně označené nebo odstraněné,
• prototyp neobsahuje tajné přístupové údaje v kódu,
• jste zkontrolovali externí skripty a knihovny, kam formuláře odesílají data a zda kód neobsahuje XSS nebo SQL injection.

MVP z AI: prototyp, se kterým umí webdesigner pracovat

Ze srovnání výše vyplývá, že ani ten nejlepší prompt nevyrobí hotový web. Vyrobí ale něco, co se v praxi hodí skoro víc – použitelný prototyp. V žargonu by se tomu řeklo MVP, minimum viable product - i když to označení nesedí úplně přesně: nejde o funkční produkt, ale o viditelný brief, ze kterého se teprve dá postavit reálný web.

A právě tady je nejsilnější reálné využití, které v těch nástrojích vidím: klient si nechá AI vygenerovat dvě nebo tři varianty webu, vybere, co se mu líbí, a přijde s tím za webdesignerem. Místo abstraktního „chci něco moderního" přinese konkrétní ukázku – layout, strukturu sekcí, tón textů. Designer vidí, co klient má na mysli, už na první schůzce. Podrobněji o tom, jak vypadá pořádný brief a proč se vyplatí, píšu v článku Tvorba webu – plán a jeho fáze.

Co takový prototyp přinese oběma stranám:

• Klient musí přemýšlet. Aby dostal použitelný výstup, potřebuje brief – a tím si vlastně sepíše zadání, které by jinak vznikalo až na schůzce.
• Neshody vyjdou najevo brzy. „Takhle nějak jsem si to nepředstavoval" zazní u prototypu typicky za pár minut, ne u navrženého webu po třech týdnech.
• Iterace je levná. Třetí varianta promptu stojí v mém postupu pár minut; třetí varianta designu stojí dny práce.
• Designer dostane kontext. Vidí typ webu, míru vizuální odvahy a tón, který klient očekává – a na tom staví skutečný návrh.

Hranici je ale potřeba pojmenovat: MVP z AI je prototyp, ne základ stavby. Vygenerovaný kód typicky není produkční kvalita – může chybět přístupnost, metadata, opravdové formuláře i rozumná struktura. Designer ho proto nepřebírá a „jen opraví": použije ho jako vodítko a web postaví znovu, pořádně. Kdo si myslí, že stačí vygenerovaný soubor nahrát na hosting, dopadne jako první výstup testu – hezká stránka, která nefunguje.

Pokud to chcete zkusit, postup je jednoduchý:

1. Sepište si zadání podle briefu výše – účel, publikum, sekce, skutečné údaje.
2. Nechte si vygenerovat dvě až tři varianty, klidně v různých nástrojích.
3. Vyberte, co se vám líbí – a poznamenejte si i to, co se nelíbí.
4. Soubor i poznámky předejte webdesignerovi. Právě jste mu typicky ušetřili hodiny hádání.

Tenhle postup v praxi používám: klient přinese AI prototyp, já z něj vyčtu představu o struktuře a vizuálu, doplním skutečný obsah, technickou stránku a provoz – a klient dostane web, který vypadá podle jeho představy, ale funguje podle standardů, které AI sama nezvládne.

Co prototyp nemá: texty, které prodávají

Prototyp ukazuje strukturu a vizuál, ale texty jsou jeho slabé místo. AI píše copy, který zní věrohodně, ale je generický - „poskytujeme výjimečné služby šité na míru" je fráze, která by mohla patřit komukoliv. AI nezná vaše zákazníky, neví, že se bojí přemrštěných cen, že už je spálil předchozí dodavatel, nebo že volí právě vás kvůli garanci. Tyto nuance prodávají a vyžadují pochopení byznysu, které žádný prompt nepředá. Test z roku 2026, který porovnával tucet AI builderů se stejným zadáním, ukázal, že všechny produkovaly pozoruhodně podobný, generický copy. Prototyp proto berte jako strukturu a vizuál, ne jako texty. Skutečný obsah doplní člověk, který zná firmu a zákazníka.

Komu web patří a co se stane, když odcházíte

AI builder je nejrychlejší cesta k publikovanému webu, ale rychlost má svou cenu: web běží na platformě, kterou nekontrolujete. Vlastníte obsah (texty, obrázky), ale ne kód, infrastrukturu ani nástroje, které web drží pohromadě. Model nebo vývojářský agent vydá soubor, který můžete hostovat kdekoliv - ale vlastnictví kopie souboru neznamená automaticky výhradní autorská práva, a doména, formuláře a údržba zůstávají na vás. Rozdíl mezi buildery je ale větší, než vypadá na první pohled.

Lovable synchronizuje kód s GitHubem nebo GitLabem na všech plánech, takže repozitář máte u sebe. Backend (Lovable Cloud) ale není možné převést jedním klikem - export databáze obsahuje strukturu a data, ale ne uživatelská hesla (ta se neexportují v použitelné formě, uživatelé potřebují reset), ne storage soubory, ne edge funkce a ne tajemství. Kdo se přesouvá, musí si autentizaci, proměnné prostředí a externí služby v cíli nakonfigurovat znovu. Doména registrovaná přes Lovable se dá převést jinam (EPP kód je dostupný), ale vyžaduje to placený plán.

Framer je naopak postavený na otevřených webových standardech - publikovaný web je standardní HTML, CSS, JavaScript a statické soubory, které si můžete stáhnout a hostovat kdekoliv. CMS obsah lze exportovat jako CSV nebo JSON. Doména se registruje přes partnera Hover (nezávislý registrátor), ne přes Framer přímo, takže doména není uvázaná v platformě. Projekt lze převést na jiného uživatele. Z tří builderů v tabulce má Framer nejsilnější převoditelnost.

Durable je opačný extrém: export kódu neexistuje, web běží pouze při aktivním předplatném, a zrušení může web vzít okamžitě offline. Doména registrovaná přes Durable se dá převést, ale až po třech měsících aktivního předplatného. Migrace z Durable znamená rebuild od začátku.

Společné pravidlo pro všechny buildery: žádný z nich nečte projektový soubor jiného builderu. Migrace není import - je rebuild. Před volbou buildera si ověřte, co se stane při odchodu, a doménu registrujte u nezávislého registrátora, ne přes buildera. Je to pár minut práce, které vám ušetří nejhorší verzi lock-inu.

Generovat je snadné. Poznat, že je to dobré, je těžší

AI dnes vygeneruje web, který vypadá hotově, za pár minut. Ale vypadat hotově a být hotový není totéž. Hlavní problém tvorby webu pomocí AI není generování - je verifikace: jak poznáte, že je výstup skutečně dobrý. Pro věci, které se dají měřit (funkčnost formuláře, rychlost, bezpečnost, přístupnost), existují nástroje - Lighthouse, testy prohlížeče, bezpečnostní skenery. AI ale typicky sama nevytváří testy a kontroly, které by tyto nástroje aktivovaly. Pro věci, které se měřit nedají (design, soulad se značkou, UX záměr), neexistuje žádný automatický ukazatel vůbec.

Přirozený reflex je požádat AI, ať výstup zlepší. Studie z roku 2026 ale ukazuje, že to může kód zhoršit: při iterativním „zlepšování" vzrostl počet kritických zranitelností o 37,6 % po pěti iteracích, a ani jedna ze čtyř testovaných strategií promptování - včetně té bezpečnostně zaměřené - bezpečnost nezlepšila. Studie pracovala se 400 vzorky kódu napříč 40 koly „vylepšení" a je dostupná na arXiv a IEEE Xplore (anglicky). Její závěr: lidská validace mezi iteracemi je nezbytná, protože AI bez vnější kontroly nové chyby zavádí stejně ochotně jako staré odstraňuje. Že je verifikace úzkým hrdlem celého agentního vývoje, potvrzují i data z praxe: Martin Michálek, CEO PageSpeed.ONE, na Vzhůru dolů připomíná, že 96 % vývojářů AI kódu nevěří, ale jen 48 % ho před commitem ověřuje - a mediánová délka code review se podle dat Faros AI zvýšila zhruba pětkrát.

Co to znamená pro tvorbu webu? „Zlepši to" bez konkrétního měřitelného cíle může kód zhoršit. Místo iterace naslepo definujte, co se má kontrolovat - odesílá formulář poptávku, splňuje přístupnost, načítá se pod 2,5 s, neobsahuje XSS - a ověřte proti tomu. AI urychluje generování, ale neodstraňuje potřebu lidské kontroly. Naopak: čím více AI generuje, tím více je kontroly potřeba, protože jediná vrstva, která AI výstup odděluje od produkčního webu, je člověk, který se podívá.

Časté otázky

Závěr

Tři prompty, tři soubory, jeden závěr: kvalitu výstupu neurčuje jen nástroj, ale kombinace modelu a zadání. Slabý prompt vydá demo plné fikce. Poctivý brief vydá poctivý draft. A prompt, který žádá přístupnost, ji skutečně může obsahovat - byť několik prvků není úplný audit. AI je rychlá a ochotná – ale nedoplňuje to, o co jste neřekli.

A právě tady se otevírá nejsilnější reálné využití, které v praxi vidím: AI je nejrychlejší cesta k prototypu, ne k provozu. Klient přinese tři vygenerované varianty, webdesigner z nich vyčte představu a postaví skutečný web – s doménou, funkčními formuláři, přístupností a údržbou. AI typicky ušetří hodiny hádání na začátku; nikdy ale nepřevezme odpovědnost za to, co přijde po spuštění.

A pořád platí, že soubor není firemní web. Web je doména, kterou vlastníte, formulář, který dojde, obsah, který je pravdivý, a někdo, kdo to udržuje. Pokud si chcete AI cestu vyzkoušet, zkuste – všechny tři prompty máte výše a za hodinu budete vědět víc než po deseti přečtených článcích. A když narazíte na bod, kde „vypadá to hezky, ale nefunguje to", ozvěte se. Přesně tam totiž moje práce začíná.

Tento článek nechce nikoho odradit od AI. Chce jediné: vyvrátit reklamní slib, že funkční firemní web se vygeneruje za pět minut. AI je skvělý nástroj na prototyp, draft a nápad - stejně jako projektantův výkres je skvělý začátek stavby domu. Ale dům nepostavíte z výkresu, a web nepostavíte z promptu. Oboje vyžaduje odbornost, kterou žádný nástroj nenahradí: u domu zedníka, elektrikáře a statika, u webu obsah, formuláře, přístupnost, bezpečnost a provoz.