Ještě nedávno musel člověk, který chtěl vytvořit webovou aplikaci, vědět alespoň něco o HTML, hostingu, serveru a databázích. Dnes může do Claude napsat: „Udělej mi dashboard, ve kterém půjde měnit stav úkolů, ukládat data a sdílet je s týmem.“ Za chvíli dostane stránku, která vypadá jako hotový produkt.
Právě tím se Claude Artifacts posouvají z kategorie hezkých jednorázových výstupů k něčemu podstatně zajímavějšímu. Podle pozorování The Chaos Guru už některé Artifacts umějí ukládat vlastní verze, pracovat se sdíleným úložištěm JSON dokumentů, filtrovat data a posílat živé změny do otevřených kopií stránky.
To je skvělá zpráva pro prototypování. Zároveň je to přesně okamžik, kdy se obyčejná otázka „umí to vytvořit aplikaci?“ mění na mnohem důležitější otázku: kdo bude rozumět datům, která v ní vzniknou, a kdo za ně ponese odpovědnost?
Od obrázku k malé aplikaci
Artifacts začínaly jako způsob, jak z konverzace dostat něco názornějšího než dlouhý text. Claude vytvořil graf, kalkulačku, jednoduchý report nebo malou webovou stránku a uživatel si ji mohl prohlédnout. Anthropic dnes Artifacts popisuje jako živé interaktivní stránky, které mohou pokračovat v aktualizaci podle toho, co se děje v relaci Claude Code.
Novější vrstva jde dál. Stránka může mít ovládací prvky, tlačítko pro uložení, vlastní datové záznamy a živé odběry změn. Uživatel tak nemusí pokaždé žádat model o nový HTML soubor. Přepne stav úkolu, odešle formulář nebo upraví položku a změna se může propsat do dalšího načtení i do dalších otevřených kopií.
Důležitá brzda ale zní: tato část popisu vychází hlavně z praktické analýzy a z dokumentace, ne z velkého veřejného uvedení samostatné databázové platformy. Dnešní rychlá zpráva na Radyz proto mluví o nových možnostech opatrně. Nejde o důkaz, že z každého Artifacts je automaticky bezpečný produkční systém.
Programátor na povel, bez lekce databází
A tady přichází změna, kterou technické popisy často přehlížejí. Část těchto aplikací budou vytvářet lidé, kteří ještě včera netušili, co je databáze. O webu věděli přibližně tolik, že ho někdo vytvořil a že se dá najít přes Google. Teď napíšou několik vět do chatu a dostanou dashboard, formulář nebo evidenci úkolů.
Výsledek může být překvapivě použitelný. Člověk, který nikdy neřešil tabulky a dotazy, si nechá vytvořit seznam zákazníků, interní přehled rozpracovaných zakázek nebo jednoduchý tracker reklamací. Když něco nefunguje, popíše problém přirozeným jazykem a Claude stránku upraví.
Jenže funkční obrazovka ještě neznamená, že její autor rozumí systému pod ní. Neví, zda se změna skutečně zapsala, jestli ji může přepsat jiný uživatel, kdo ji uvidí za týden nebo co se stane, když někdo omylem uloží špatná data. Přesto může během odpoledne začít působit jako člověk, který „vyvinul aplikaci“.
To není výsměch začátečníkům. Je to logický důsledek nástroje, který odstraňuje technickou bariéru. Problém vzniká ve chvíli, kdy se odstranění bariéry zamění za získání znalosti. Claude umí vyrobit rozhraní rychleji, než se jeho uživatel stačí naučit, co všechno může rozbít.
Když první prototyp začne žít vlastním životem
U malého interního přehledu to nemusí být problém. Tým si může vést stav úkolů, seznam nápadů, jednoduchý registr obsahu nebo tabuli s prioritami. Pokud se data dají snadno zahodit a nikdo podle nich neposílá faktury ani nerozhoduje o lidech, je rychlý prototyp přesně tím, čím má být.
Potíž nastane, když prototyp začne být důležitější, než původně vypadal. Z evidence úkolů se stane hlavní seznam práce. Z formuláře vznikne zdroj zákaznických údajů. Z dashboardu se začne reportovat vedení. Nikdo přitom nemusí vědomě rozhodnout, že aplikace přešla do produkce. Prostě ji lidé začnou používat, protože je po ruce.
V tu chvíli už nestačí, že stránka vypadá dobře. Je třeba vědět, jaké má datové struktury, jak se mění, kdo je vlastní, jak se obnoví po chybě a jestli se dá obsah exportovat. To jsou otázky, které se do prvního promptu často vůbec nedostanou.
Data nejsou jen řádky na obrazovce
Databáze není jen místo, kam se odloží několik objektů JSON. Je to také soubor pravidel. Kdo smí číst? Kdo smí zapisovat? Které údaje patří konkrétnímu týmu? Co je povinné? Co se stane při duplicitě? Jak poznáme, že záznam někdo změnil oprávněně?
Právě tady je popis Artifacts zajímavější než samotné tlačítko Save. Podle analýzy The Chaos Guru může mít úložiště pravidla nastavená samostatně pro čtení a zápis a pracovat s cestami v datové struktuře. Některé části mohou být soukromé pro konkrétního uživatele, jiné sdílené s týmem.
Oficiální dokumentace Claude Code zároveň upozorňuje, že stránky s konektory používají účty jednotlivých diváků. Dva lidé tak mohou na stejném dashboardu vidět odlišná data podle toho, k čemu mají oprávnění. To je užitečné, ale také to znamená, že „sdílená stránka“ nemusí znamenat „stejný pohled pro všechny“.
Dokumentace také uvádí, že Artifact využívající konektory nemůže být sdílen jako veřejný odkaz. Obecné sdílení a sdílení dat napojených na cizí systémy tedy nejsou totéž. Člověk, který si nechá vytvořit aplikaci jednou větou, musí najednou rozumět rozdílu mezi stránkou, úložištěm a oprávněním.
Největší problém: nikdo neví, co se vlastně vytvořilo
Podobný problém už známe z programovacích agentů. V dřívějším článku o AI agentovi s klíči od databáze jsme řešili situaci, kdy nástroj umí rychle vytvořit migraci, endpoint nebo nový kus datového modelu, ale nevidí celý systém a jeho historii.
U Artifacts se stejná věc přesouvá blíž k běžným uživatelům. Claude může vytvořit další datovou strukturu, protože neví, že podobná už existuje jinde. Může použít jiný název pro stejný typ údaje. Může uložit datum jako text, přestože ho později potřebujeme řadit. Může navrhnout formulář, který sbírá osobní údaje, aniž by někdo promyslel jejich životní cyklus.
Člověk přitom často nevidí žádný problém. Vidí stránku, tlačítko a výsledek. Nevidí schéma, pravidla validace, historii změn ani místa, odkud se data načítají. Rozhraní skrývá složitost tak dobře, že může skrýt i chybu.
Poslední vítězný zápis není spolupráce
Další omezení je technické, ale pro laiky bude mít praktický dopad. Podle popisu nové databázové vrstvy používají zápisy princip posledního vítězného zápisu a nemají transakce. Když dva lidé změní stejný záznam, nemusí vzniknout chytrá sloučená verze. Jeden zápis jednoduše přepíše druhý.
Pro stavovou tabuli je to možná přijatelné. Pro inventář, objednávky, finance nebo evidenci citlivých rozhodnutí už ne. Tam potřebujeme vědět, kdo změnu udělal, co přesně se změnilo a zda se dvě operace navzájem nevylučují.
To je rozdíl mezi aplikací, která něco umí, a systémem, kterému lze svěřit důležitá data. Claude může vytvořit první variantu během několika minut. Druhá varianta vyžaduje návrh, testování a někoho, kdo dokáže vysvětlit, proč je systém nastaven právě takto.
Bezpečnost začíná tam, kde končí prompt
Ještě citlivější je otázka obsahu, který se do stránky dostane. Bezpečnostní analýza Pluto Security popsala test, v němž se syntetické přihlašovací údaje podařilo v deseti z 85 pokusů přimět agenta vložit do publikované stránky – ukryté ve skriptu, který se běžně nezobrazoval.
Neznamená to, že každý Artifact tajně odnáší hesla. Znamená to ale, že pravidlo typu „nikdy nevkládej citlivé údaje“ může být jen instrukcí pro model, nikoli technickou kontrolou na hranici systému. Pokud stránku později čte další agent, komentář nebo konektor, vzniká další cesta, jak se škodlivý obsah může dostat do pracovního procesu.
To je známý problém prompt injection: data se pokusí tvářit jako pokyny. U obyčejného textu může být výsledek jen špatná odpověď. U živé stránky s možností zapisovat, volat nástroje nebo měnit data může být důsledek mnohem nepříjemnější.
Artifacts proto nejsou automaticky nebezpečné. Jen se u nich bezpečnostní otázka přesouvá z kódu, který obvykle kontroluje vývojář, do směsi modelu, oprávnění, sdílení a obsahu stránky. Pro člověka bez technického zázemí je to velmi těžké místo, protože nevidí, kde přesně končí text a začíná program.
Kdo má být vlastně programátor?
Nové nástroje neznamenají, že každý uživatel musí studovat několik let informatiku, než si smí vytvořit jednoduchý tracker. To by popíralo jejich hlavní přínos. Znamenají ale, že odpovědnost za výsledek nezmizí jen proto, že kód napsal Claude.
Rozumná hranice může být jednoduchá. Nechte Claude vytvořit prototyp, ale před jeho rozšířením si nechte vysvětlit, co se ukládá, kde se to ukládá, kdo k tomu má přístup, co se stane při souběžné úpravě a jak se data exportují. Pokud na tyto otázky neumí odpovědět člověk, který aplikaci používá, neměla by rozhodovat o ničem důležitém.
- jasný vlastník dat a člověk, který schvaluje změny
- oddělení testovacích a skutečných údajů
- omezení práv pro čtení, zápis a volání konektorů
- historie změn, možnost exportu a plán návratu po chybě
- kontrola osobních údajů a obsahu, který může číst další agent
- ověření, zda dva lidé nemohou navzájem přepsat důležitou změnu
To není byrokracie pro radost. Je to minimum, které bývalo součástí práce programátora, správce databáze nebo provozního týmu. Artifacts tuto práci nemažou. Jen dovolují, aby první verzi systému vytvořil někdo, kdo se s ní nikdy předtím nesetkal.
Důležitý posun, ne hotový podnikový software
Claude Artifacts mohou být velmi užitečné právě proto, že zpřístupňují malé aplikace lidem mimo vývojářské týmy. Umožní rychle ověřit nápad, zjednodušit interní proces nebo ukázat, co by měl později postavit skutečný software.
Chyba by byla považovat rychlost vytvoření za důkaz kvality. Když člověk, který ještě před týdnem nevěděl, co je databáze, během odpoledne vytvoří funkční formulář, je to úspěch nástroje. Když se z něj kvůli tomu stane jediný správce zákaznických dat, je to selhání organizace.
Artifacts tedy nemění laiky v programátory tak úplně, jak se může zdát. Mění je v lidi, kteří dokážou programátorský výsledek vytvořit. Rozdíl mezi těmito dvěma věcmi bude rozhodovat o tom, jestli se z nové generace AI aplikací stanou užitečné pracovní nástroje, nebo rychle rostoucí sbírky dat, kterým už po čase nebude rozumět vůbec nikdo.
