Je AI fluency nezbytná pro budoucnost práce?

Čím dál více se otevírají nůžky mezi lidmi, kteří AI používají, aby jim umělá inteligence řekla, jakou si mají vybrat barvu kuchyně, a těmi, kteří si vytvořili procesy pro každodenní úkoly, agenty a automatizace nebo AI zaměstnance na řízení celé firmy.

Photo by Med Badr Chemmaoui on Unsplash

To se obklopuje vlnou paradoxů, jako je nahrazování zkušených lidí AI s nejistými výsledky, junioři se nemají na čem učit a posouvat se do seniority a seniorů je najednou ještě větší nedostatek. AI generuje výstupy, které nemá kdo kontrolovat. Nelze přehlédnout ani to, že prakticky žádná AI nezaručuje kompletní zabezpečení informací, které do ní vložíme.

Najednou nelze přehlédnout výrazy jako API, GIT, CLI, MCP nebo terminál. Základy algoritmizace nejsou potřeba k programování, ale k vytvoření instrukcí a plánu postupu.

Tento článek diktuju svými slovy pomocí Wispr Flow. Všechny zdroje, které jsem našla, jsem si uložila do NotebookLM a díky tomu jsem mohla čerpat ze stovek z nich. Používám Karpathyho metodu propojení Claude a Obsidianu pro stavění Knowledge Base nebo druhého mozku, díky které můžu vyhledat jakékoliv informace, které jsem kdy přečetla nebo zpracovala. Článek je i přesto psaný (či namluvený) mými vlastními slovy.

Nenechat si ujet vlak

Nechci předložit optimistický úhel pohledu bez argumentace. Během doplňování zdrojů při psaní tohoto článku mi Youtube doporučil živé hudební video s názvem *Claude FM 🎵 music for thinking and building*, které v daný moment poslouchalo 900 uživatelů. Hranice je tenká, někdy děsivá a algoritmus neúprosný.

Mým cílem bylo, abych se více přiblížila té straně, kdy vím, co jsou agenti, jak funguje AI na pozadí, jaký model si vybírám a proč a kde jsou bezpečné limity. Vím, jak pokládat otázky, jak psát prompty, jak si vybrat nástroje, se kterými budu pracovat, a jaké je jejich zabezpečení.

Studium kurzu Elements of AI mi přineslo poznání o jádru fungování umělé inteligence. Proč umělá inteligence, se kterou běžný uživatel konverzuje, někdy generuje nesmysly a máme pocit, že si vymýšlí nebo se točí v kruhu? A taky to, že nás nakonec nejspíš neovládnou roboti.

Kontextové okno

I my lidé si nejlépe pamatujeme to, co se stalo na začátku a na konci. Umělá inteligence má několik limitů a jedním z nich je kontextové okno. To je část obsahu chatu, kterou model skutečně vidí. Všechno ostatní si už musí domýšlet na základě pravděpodobnosti a šance. Proto se v určitém momentě může začít točit v kruhu, říkat věci, které nedávají smysl, a působit, jako by zapomněla na začátek nebo na prostředek konverzace. Protože si ho doslova nepamatuje.

Když jsem s tímhle tématem začínala, kontextové okno nebylo nástroji příliš komunikováno. ChatGPT vám neřekl, že už ho vyčerpal. Jeho velikost nebyla součástí popisu předplatného. Dalo se najít jen pár okrajových informací o počtu tokenů, se kterými model dokáže pracovat, a o tom, co všechno „udrží“ v paměti. Co to ale znamená, je poměrně abstraktní, zvlášť když token není nutně slovo nebo znak.

První poučení: je nezbytné začínat každou novou konverzaci a každou otázku v novém chatu. Případně pokud to nástroj umožňuje, používat projekty nebo složky, aby se neztrácel kontext (ve smyslu znalosti právě řešeného problému, nikoli kontextového okna) a nebylo potřeba znovu vysvětlovat celé zadání.

V té době jsem ještě používala ChatGPT a vlastně mi nevyhovovalo, že si vymýšlí a nedává odpovědi, které potřebuji. Nejlepší benchmark měl Gemini, které mělo být lepší při práci s dlouhými texty a dokumenty. Největší výhoda byla, že Gemini pracuje také s Google Workspace a údajně je dostatečně bezpečné na to, abych v něm mohla pracovat s jeho dokumenty nebo si připojit NotebookLM.

Již dříve jsem používala NotebookLM k správě zdrojů a rychlému vyhledávání informací. Ať už nad projektovými dokumenty, různými daty, design briefy a deníky, nebo nad tématy, která jsem si chtěla nastudovat. Naplnila jsem si ho zdroji, které jsem považovala za relevantní, a používala ho jako rychlý přehled před hlubším ponořením do tématu nebo naopak pro zpětné dohledání zdroje, když jsem chtěla vědět, odkud konkrétní informace pochází.

Postupně jsme ale narazili, protože si Gemini začal vymýšlet už velmi brzy. I když má velké kontextové okno, myslím, že tehdy už poslední verze měla kolem 1 000 000 tokenů. Začala jsem hledat alternativy. Testovala jsem několik dalších nástrojů, jako třeba Antigravity od Googlu nebo Perplexity, a nakonec jsem objevila Claude AI. Ten díky Code (a Claude co-work) poskytuje dostatečně ucelený nástroj, abych s ním mohla dlouhodobě pracovat.

V tuhle chvíli ale bylo potřeba se zastavit a říct si, že nástroj jako takový mi nepomůže. Benchmarky se mění s každým dalším modelem a navíc je více než vhodné nechávat různé modely vzájemně porovnávat s vlastní prací.

Čeho chci dosáhnout

AI literacy je ještě o něco dál než zmiňovaný příklad na začátku článku, kdy AI používáte jen ke konverzaci a běžným dotazům.

AI literacy

Gramotnost je základní úroveň kompetence. Zahrnuje pochopení toho, co je AI, co dokáže a jak se s ní základně pracuje. Také znamená vědět, jak AI nástroje používat, když dostanete konkrétní pokyny.

• Rozumíte tomu, co jsou ChatGPT, Midjourney atd.
• Dokážete napsat základní prompt (příkaz).
• Znáte rizika (např. halucinace, bias/předpojatost).

AI fluency

Pokročilá úroveň vyžadující hlubší expertízu. Nad nástroji nepřemýšlíte jako nad izolovanými úkoly, ale integrujete je do své práce.

• Přepracování pracovních postupů (workflow) tak, aby byly efektivnější.
• Kombinování různých AI nástrojů pro komplexní úkoly.
• Hluboké porozumění tomu, jak promptovat pro co nejlepší výsledky (inženýrství promptů).

Dílčí cíle

Bylo na čase přistoupit k AI fluency a stanovit si vlastní konkrétní cíle:

• Porozumět tokenům a jejich využití: jak být co nejefektivnější, aby došlo k co největší úspoře. Nejen kvůli čerpání kontextového okna, ale i kvůli udržitelnosti. Používání AI není zrovna úsporné.
• Poznat bod zlomu: kdy je lepší převzít kontrolu a nepokračovat v nekonečném lazení, které jsem si pro sebe pojmenovala jako detailing.
• Nepadat do králičích nor: Povídání si s AI vás někdy vtáhne. A to hlavně při tvorbě nějakého řešení (např. mikrowebu). Protože designér nikdy není hotov, vždycky narazíte na něco, co by ještě šlo vylepšit.
• Změnit pracovní proces: Jaký je workflow s AI?
• Změnit způsob práce na počítači: jak pracovat se soubory psanými v Markdownu, jak strukturovat složky.
• Připojení externích služeb: jak je připojit, aby práce s nimi byla skutečně efektivní.
• Jak pracovat s rozsáhlým sborníkem dokumentů: který by umožnil svobodu mému nelineárnímu toku myšlenek a vzájemným vazbám mezi jednotlivými dokumenty.
• Jak rozpoznat, který model zrovna použít.
• Jak si včas uvědomit, že už je vhodné zahájit novou konverzaci.
• Poznat limity AI a umět je vysvětlit klientům či stakeholderům.
• Předejít krizi vlastního já, vlastní expertízy a seniority: jak neztrácet kreativitu a umět si nastavit vlastní hranice.

Většina cílů je provázaná jako pavučina a jedna znalost navazuje na druhou. Tokenová efektivita souvisí s prompty a propojením s dalšími nástroji. Změna pracovního procesu úzce souvisí s efektivitou práce a s vlastním chápáním sebe sama. Nastavení vlastních hranic předchází úplnému zničení kreativity, vlastního zapojení a krizi imaginace.

Porozumět tokenům, modelům a jejich využití

Claude vás v podstatě donutí k tokenové efektivitě, protože máte týdenní limit i pětihodinové okno na práci. Pro další posun bylo nezbytné zjistit, jak s tokeny správně nakládat. Když nemůžete nástroj používat, nemůžete se ve svých schopnostech prakticky rozvíjet.

Generováno s NotebookLM z vlastních poznámek.

Protože jsem si důležitost tokenů uvědomila při přechodu na Claude, mnoho bodů souvisí právě s tímto nástrojem, jsou ale obecně platné i jinde. Zároveň se tak stalo v momentě, kdy Claude měl významné chyby při čerpání tokenů, takže internet zaplavily diskuze a videa o tom, jak jimi šetřit tak, aby nikdy nedošly.

• Konkrétně Claude čte zpětně celou konverzaci od začátku. Čím delší konverzace je, tím více ji znovu a znovu čte. Včetně svých vlastních odpovědí.
• Proto je také vhodné požadovat spíše krátké odpovědi. Z vaší strany ale musí odcházet kvalitní požadavky.
• Použití správného modelu šetří čas i tokeny. Čas nejen na získání odpovědi, ale také na to, aby dodaná odpověď byla relevantní a správná.
• Čím více jste konkrétní, tím méně si AI musí domýšlet, co jste vlastně chtěli. Udělej syntézu je příliš obecné. Váš kolega by z tohoto požadavku byl stejně zmatený a strávil by nějaký čas navíc tím, že by zjistil, co si přesně představujete pod syntézou a syntézu čeho máte na mysli.
• Používání plánovacího módu v Claude Code významně šetří budoucí tokeny a umožňuje větší kontrolu nad výstupem.
• Neodcházet od konverzace v jejím průběhu je dalším důležitým prvkem. Claude pracuje s cache, pokud její timeout vyprší, musí si načíst kontext znovu.
• Používání CLI místo MCP. Vypínání MCP, které aktuálně nepoužíváte. Ty totiž čerpají tokeny ještě předtím, než položíte dotaz.
• Chaty udržujte co nejkratší nebo používejte jednou za čas shrnutí a smazání předchozího kontextu (pokud vám to situace umožňuje). Osobně používám spíš to, že nechám Claude z důležité konverzace vytvořit výstup do .md souboru a ten pak ukládám do příslušné složky pro další použití.
• Při práci na projektech a ve složkách je potřeba dodržovat srozumitelnou strukturu, aby inteligence měla vždy velmi rychlý přehled o tom, kde se co nachází a kam se má dívat jako první. Tohle lze udělat přímo v Claude napsáním požadavku na reorganizaci složky. A nebo využitím metody Karpathyho v kombinaci s Obsidianem.

Poznat bod zlomu, nepadat do králičí nory

Paretovo pravidlo 80:20 při tvorbě výstupů dává ještě větší smysl dodržet. Nejdůležitější je uvědomit si, kdy k tomuto bodu dochází. Kdy už není dobré popisovat každou dílčí úpravu textem (či slovy) a čekat na zpracování umělou inteligencí. A to většinou nastane hrozně rychle (v oněch 20%, kdy máte 80% výstupu hotového).

Ladění každého detailu momentálně s umělou inteligencí nedává smysl. Buď je potřeba se spokojit s výstupem, anebo přejít k samostatné manuální práci. To se projevuje hlavně u komplexnějších výstupů, ať už jde o dokument, prototyp, hotový web nebo aplikaci.

Čemu stále nemohu odolat, je posouvání ne úplně důležitých a podstatných částí řešení. To ale dělám i při vlastní práci, takže ačkoliv to považuji za nesplněný cíl, pořád platí, že designér není nikdy hotov a je to tedy práce spíš s vlastními limity než s nástrojem.

Změnit pracovní proces a způsob práce na počítači

Před pár lety jsem kompletně přešla do cloudu a všechny dokumenty mám v Google Workspace. Můj počítač má nejmenší možný hard disk, protože v něm nepotřebovala paměť. Musím přiznat, že pro mě bylo docela těžké zvyknout si znovu na to, že používám soubory na počítači a musím je nějak strukturovat.

Díky Notionu, který měl boom před pár lety, jsem si zvykla na psaní dokumentů v markdownu a podobně mám nastavené i Google Docs. Významně to urychluje práci. S jakou radostí jsem zjistila, že i pro AI je to nejlepší formát, se kterým se příliš nezdržuje. Jenže to také znamená, že potřebujete nějaký nástroj, který vám text napsaný v markdownu zobrazí vizuálně přehledně a už se zase noříte do změn vašeho systému, o kterém jste si mysleli, že je konečně maximálně minimalistický.

A proto jsem začala používat Obsidian (na správu .md souborů). O Obsidianu a práci s dokumenty se rozepíšu podrobněji v dalším textu.

Připojení externích služeb

Byl to právě ten moment, kdy jsem potřebovala zpracovat stovky, ne-li tisíce, lístečků z FigJam, což mě přimělo se více zabývat strojovým zpracováním. Smyslem nebylo nevědět, co na lístečcích je. To jsme dávno věděli, protože jsme je sami psali. Ale jejich organizace, syntéza a získání insightů do přehledného a smysluplného dokumentu se jevily jako práce na několik týdnů.

Zrovna v té chvíli vyšel MCP server pro Figmu, a tak bylo na čase objevit i práci v kombinaci s dalšími nástroji.

• Propojení Figmy s Claude je výrazně lepší, když probíhá přímo na počítači, i přesto, že jde stále o MCP.
• Nevyužívaná propojení je nutné vypínat, jinak zbytečně čerpají tokeny.
• Skrz Figma MCP jsem si propojila také Cursor, abych mohla otestovat vytvoření rychlého prototypu s existujícím design systémem. Zatím mě to pracovně příliš neuspokojilo.

Práce s velkým souborem dokumentů

Co mi dlouhodobě chybělo, byla práce s vlastními znalostmi, deníky a zdroji. Problém s poznámkami a vlastní knowledge base řeším celý život. Ať už skrz commonplace book, ručně psané indexové kartičky nebo používání různých forem a principů psaní poznámek a nástrojů pro jejich přehlednost. Zde se dostává do popředí **Karpathyho metoda pro organizaci dokumentů s pomocí Obsidianu**. Důležitý je způsob zpracování vkládaných zdrojů, jejich vědomostní provázání a schopnost rychle dohledat určitou informaci v daném kontextu (bez nadbytečného čerpání tokenů).

Založení wiki s touto metodou je až nepříjemně jednoduché:

1. Vytvoříte si v počítači složku, kterou v Obsidianu označíte jako vault.
2. Následně v Claude Code (musíte mít desktopovou verzi) v této složce vytvoříte nový projekt (to znamená pouze otevřít danou složku v chatu Claude Code).
3. Jako první příkaz v chatu pošlete obsah souboru ****llm-wiki.md.
4. Claude založí příslušné složky a nezbytné dokumenty s instrukcemi a indexem.
5. Do nově vzniklé složky, která se téměř s jistotou jmenuje raw, vkládáte soubory, které chcete do své nové wiki importovat. Lze na to použít i doplněk do prohlížeče.
6. V Claude Code otevřete nový chat, napište prompt ingest @název souboru a nechte ho pracovat. Claude si s vámi bude chtít ověřit důležitost a smysluplnost informací, které do wiki uloží. To mu potvrdíte. Z tohoto důvodu je také lepší ingest spouštět soubor po souboru a vždy v novém chatu.

Protože přemýšlím nelineárně a /btw je můj nejoblíbenější příkaz (a zkratka). Potřebovala jsem přijít na něco, co mi umožní procházet zdroje jako Wikipedii. Ale psaní vlastní wiki je neskutečně časově náročné, navíc se po nějaké době začnete ve vlastním objemu dat ztrácet, nehledě na to, že je téměř nemožné celou databázi udržovat vždy aktuální v kontextu nově přibývajících souborů.

Při vkládání jakýchkoliv dat do mé vlastní wiki k dalšímu zpracování respektuji, pokud je někde blokovaný přístup pro AI nebo napsaná žádost o nezpracovávání pomocí AI. Pokud tam takový zdroj chci, popíšu vlastními slovy myšlenku, nebo vložím vlastní poznámky.

Model využívám ke katalogizaci zdrojů a jejich snadnému vyhledávání, protože si chci stále zachovat vlastní přehled a expertízu.

Umět vysvětlit limity AI klientům a stakeholderům

Nemyslím si, že bych zatím uměla plně a srozumitelně vysvětlit veškerá rizika — nejen bezpečnostní, ale i rizika s replikovatelností problému a se schopností replikovat kvalitní výstup opakovaně.

Za úspěch považuji, že tuto konverzaci pravidelně otevíráme s kolegy v týmu. A to bez ohledu na to, že někteří klienti už očekávají, že to za nás zpracuje AI. A že nejsme tak optimističtí jako lidé ve videích na Youtube, kterým celou firmu řídí jeden AI agent.

Zároveň považuji za úspěch, že už přicházejí požadavky na to, aby to, že to zpracuje AI, bylo vedeno někým, kdo dokáže poznat kvalitu výstupu a dokáže napsat vhodné a kvalitní zadání, stanovit si cíle, metriky, očekávání a limity. Kdo je kurátorem řešení.

Předejít krizi vlastního já, vlastní expetízy a seniority

Toto téma je nakonec nejdůležitější. Při práci s AI se začnete velmi snadno ztrácet v tom, co je váš vlastní vstup a co je interpretace AI na základě pravděpodobnosti a šance. Všechny nástroje se snažím mít nastavené (pomocí instrukcí či jiné adekvátní metody), aby minimalizovaly domýšlení, více se ptaly a méně navrhovaly řešení nebo předávaly hotové výsledky. Nenápadně se to vkrádá a najednou se najdete hluboko ve zbytečné diskuzi o něčem, o čem by vás samotné nenapadlo ani přemýšlet.

Před několika dny jsem si vše ověřila na mikrowebu na zakázku. Trvalo to asi dvě hodiny, pak jsem na dvě hodiny unikla do ladění detailů, které nebylo třeba ladit.

Ještě více považuji za důležité kritické myšlení, ale také probouzení a zachování vlastní kreativity. Vracím se k tomu, že si ve volném čase dělám matematické úlohy, maluji nebo chodím na keramiku. O to víc píšu tužkou na papír, šiji a chodím po městě. O to víc se snažím věci popsat slovy místo poslání fotky či pouhého “wow, podívej!”.

Důležité je také pozorovat první verzi, která vznikne bez vašich expertních zkušeností, a verzi, do které vložíte vlastní zkušenosti, heuristiku, představu o výsledku a použitelnosti.

Kdyby to byl klientský projekt, asi bych se zarazila dříve než po dvojnásobku času, který byl opravdu nezbytný. Co je ale důležité pozorovat: AI web či aplikaci v takovéhle fázi prostě poznáte. Protože tomu chybí kreativita. Jde o pouhé dodržování pravidel, která dávají smysl. Ale je to funkční? Je. Splnilo to cíl? Ano. Ověřila jsem si na tom výše popsané nabyté zkušenosti? Samozřejmě.

Chci takhle dělat všechno? Nikoliv. Pořád mi přijde nezbytné zůstat u vlastního ručního skicování wireframů, tvorby moodboardů, skic grafického návrhu a psaní vlastního obsahu. Musíme si zachovat bujnou mysl. Jinak mi nedává smysl cokoliv z toho dál dělat.

Závěr

Zpětně vnímám AI fluency (případně alespoň AI literacy) jako nezbytnou pro udržení se na trhu práce i pro udržení tempa se světem v prostředí, ve kterém se nacházím a pracuji. I ti, co se tomu nejvíce bránili, docházejí k závěru, že je to nevyhnutelné.

A když už používáte AI na obyčejnou konverzaci, tak se umíte vyhnout sebenaplňujícímu proroctví. Protože když se AI zeptáte, jestli můžete jít běhat, když máte rýmu, dost možná vám řekne, že je to skvělý nápad. Když se zeptáte, jestli by nebylo lepší běh vynechat, když máte rýmu, taky řekne, že je to skvělý nápad.

Není ale nezbytné AI používat pro každou příležitost. Jako důležité považuji i umět rozpoznat, kdy a proč to nedává smysl a je to na úkor vlastních kvalit, osobního rozvoje a přínosu výstupů, které tvoříme. Rozvíjet se do seniority. Umět odpovědět na to, proč nedává na tento úkol použít umělou inteligenci, jinak než: AI se nedá věřit nebo ai je jen bublina, která splaskne.

Co uděláte pro zachování vlastního já, kreativity a identity?

Článek byl původně publikován v osobním studijním portfoliu v květnu 2026.