Něco se změnilo v tom, co vlastně předáváme dál

Zkuste na chvíli zapomenout na AI. Představte si, že máte ve firmě funkční proces. Onboarding nového klienta, schvalování faktur, evidence leadů, cokoliv. Jak ho dnes předáváte dál? Máte Google Doc s postupem. Šablonu ve Wordu. Zaškolené lidi. A možná SaaS aplikaci, která to drží pohromadě.

Každá z těchto forem má svou cenu. Dokument nikdo nečte. Zaškolení se zapomene. SaaS stojí měsíční poplatek a je to krabice, která se přizpůsobí vám, ne naopak.

A teď to zajímavé. S AI agenty dnešní úrovně (Claude Code, Codex, Cursor, vlastní orchestrátory) se otvírá čtvrtá možnost: předat pouze dobře napsanou specifikaci. Markdown dokument. Popis toho, co má proces dělat, proč na tom záleží a jaká jsou pravidla. A agent ze specifikace postaví konkrétní implementaci přesně pro prostředí, ve kterém žijete.

Pro českou firmu to znamená, že část věcí, které dnes řeší drahým SaaSem nebo ruční administrativou, půjde nahradit interní AI vrstvou. Není to revoluce zítra, ale je to trend, který už dnes reálně funguje.

Karpathy to pojmenoval, my to používáme

Andrej Karpathy (bývalý director AI v Tesle, spoluzakladatel OpenAI, jeden z nejcitovanějších hlasů v AI) v dubnu 2026 publikoval GitHub Gist s názvem „LLM Wiki“. Ten dokument popisuje pattern, který řada z nás intuitivně dávno používá. Rozdíl je v tom, že Karpathy to dal do čitelné podoby a dal tomu jméno.

Jeho pointa je jednoduchá: velká část jeho token spotřeby už nejde na manipulaci s kódem. Jde na manipulaci se znalostmi. Místo toho, aby LLM při každé otázce znovu hledal informace ve stovkách zdrojových souborů, udržuje si persistentní markdown wiki. Ta se průběžně doplňuje, revizuje a propojuje křížovými odkazy.

V praxi to vypadá takhle. Máte tři vrstvy:

Vrstva 1: Raw sources. Surové zdroje. Články, PDF, interní dokumenty, přepisy schůzek. Nic se v nich neupravuje, jsou jen jako vstup.

Vrstva 2: Wiki. Markdown stránky, které průběžně udržuje LLM. Shrnutí, entity, křížové odkazy. Tohle je ta část, kterou agent používá jako pracovní znalostní bázi.

Vrstva 3: Schéma. Konfigurační dokument, který agentovi říká, jak má vrstvu 2 strukturovat. Jak pojmenovat stránky, co kam patří, jak dělat cross-referencing.

Tři operace stačí: ingest (agent přečte nový zdroj a aktualizuje 10 až 15 wiki stránek), query (prohledá wiki, odpoví, uloží cennou syntézu jako novou stránku) a lint (zkontroluje rozpory, zastaralé claims, osiřelé stránky).

To je celé. Žádná složitá vektorová databáze, žádný vendor lock-in. Jen markdown, git a agent, který se stará.

Proč to v Softmedia funguje i bez drahých RAG systémů

Když klient přijde s požadavkem „chceme AI, které zná naši firmu“, první věc, kterou očekává, je drahý projekt. Vektorová databáze, custom embeddings, fine-tuning, API integrace. Měsíce práce, desítky tisíc na infrastrukturu.

Jenže u středně velké firmy je tohle často zbytečné. Reálná potřeba není „najdi mi mezi 10 miliony dokumentů“. Je to „znej naši firmu, naše procesy, naše klienty a rozhoduj podle toho“. A na to nepotřebujete RAG. Potřebujete dobře strukturovanou markdown knihovnu a agenta, který ji umí číst a aktualizovat.

V Softmedia udržujeme pro klienty znalostní bázi v Obsidianu (1,5 milionu uživatelů, zdarma, otevřený formát). Markdown soubory propojené zpětnými odkazy. Git pro verzování. Claude Code nebo vlastní orchestrátor jako interface.

Pro většinu středně velkých firem to pokryje 90 % potřeb AI vrstvy. A zbývajících 10 % se dá dořešit MCP servery, které propojí wiki s konkrétními nástroji (Gmail, Slack, CRM, fakturační systém).

Výhoda tohoto přístupu není jen cena. Je to kontrola. Všechny soubory jsou čitelné pro člověka. Verzují se v gitu. Jdou editovat v jakémkoliv editoru. Fungují offline. A hlavně: nejsou zamčené v cizí platformě, ze které byste je museli někdy draze migrovat.

Idea files: když se shareable unit přesune z kódu na specifikaci

Druhý koncept, který s wiki přístupem souvisí, nazývá Karpathy „idea files“. Je to popis toho, co se má postavit. Ne kód, ale strukturovaná specifikace. Markdownový dokument, který obsahuje záměr, kontext, omezení, rozhodovací pravidla a očekávané chování.

Dnes si vývojáři předávají repozitáře. Zítra si možná budou předávat idea files. Proč? Protože cizí agent ze specifikace umí postavit implementaci na míru konkrétnímu stacku, preferencím a prostředí příjemce. Ten samý idea file vygeneruje jinou aplikaci pro Next.js programátora a jinou pro Django tým. A obě budou řešit stejný problém.

To je zásadní posun. Místo jedné aplikace pro všechny dostanete personalizovanou variantu. A vy jako autor nemusíte řešit kompatibilitu s každým možným stackem.

Co to znamená v praxi pro firmu:

• Know-how firmy (onboarding proces, sales playbook, pravidla schvalování) se dá převést do specifikace, kterou si agent přečte a bude se jí řídit při každém rozhodování
• Interní procesy, které dnes drží na „Anička to ví“, se dají popsat a předat AI agentovi jako trvalou část systému
• Mikroaplikace na míru (evidence, reporty, automatizace) se dají vygenerovat ze specifikace za minuty, ne týdny
• Pokud potřebujete aktualizaci, změníte specifikaci a agent přegeneruje implementaci

Praktický postup: jak na to začít ve firmě

Teoretizovat o AI-first architektuře je lákavé, ale většina firem potřebuje vědět, kde začít. V Softmedia klienty vedeme takhle:

Krok 1: Identifikujte jeden proces, který stojí čas a peníze. Nemusí to být nic velkého. Vyhodnocení poptávek, příprava nabídek, onboarding klientů, reporting. Cokoliv, co se opakuje a co dnes drží na hlavě jednoho člověka nebo v rozházených Google Docs.

Krok 2: Napište specifikaci, ne návod. Rozdíl je zásadní. Návod říká „klikni sem, pak sem“. Specifikace říká „pokud přijde poptávka nad 50 tisíc a je od firmy v našem segmentu, připrav draft nabídky podle template A a pošli ke schválení“. První je instrukce pro člověka. Druhá je pravidlo, které umí agent aplikovat sám.

Dobrá specifikace obsahuje:

• Cíl procesu (čeho chceme dosáhnout)
• Vstupy a jejich zdroje (odkud data chodí)
• Rozhodovací pravidla (jak se věci třídí, eskalují, schvalují)
• Výstupy a cílové systémy (kam má výsledek jít)
• Hranice a výjimky (co agent nesmí bez schválení)

Krok 3: Zapojte agenta. Máte dva praktické scénáře. První: specifikaci přečte orchestrátor (Claude Code, Codex nebo vlastní agent) a sám spouští další specializované agenty podle potřeby. Druhý: specifikace se stane součástí kontextu pro jednoho agenta, který má přístup k nástrojům (email, CRM, dokumenty) a sám rozhoduje, co udělat.

Krok 4: Iterujte specifikaci, ne kód. Když něco nefunguje, nezačnete přepisovat agenta. Upravíte specifikaci. Zpřesníte pravidla. Doplníte výjimku. Agent si novou verzi přečte a začne se podle ní chovat. To je fundamentálně jiná forma údržby než u klasického software.

Nástroj, který stavíme: specifikace s vedením AI

Největší bariérou není technologie. Je to schopnost napsat dobrou specifikaci. Většina lidí ve firmě je úžasně dobrá v tom, dělat věci. Mnohem hůř v tom popsat, jak je dělají. Implicitní znalosti se do explicitních formalismů převádějí těžko.

Přesně tohle teď v Softmedia řešíme. Stavíme systém, který provádí klienta procesem tvorby AI-readable specifikace krok za krokem. Místo prázdné stránky a otázky „napište nám specifikaci“ dostane klient vedení od AI agenta, který se ho ptá na správné věci, navrhuje strukturu, hledá mezery, kontroluje konzistenci a pomáhá převést živou praxi do dokumentu.

Cílem je, aby si středně velká firma dokázala postavit vlastní znalostní bázi bez toho, aby musela najímat drahého konzultanta nebo tým vývojářů. Specifikaci vytvoříte, agent si ji přečte a začne podle ní pracovat. A když se něco změní, vrátíte se do stejného systému, upravíte jednu sekci a pokračujete.

Tohle není vzdálená vize. Je to nástroj, na kterém aktivně pracujeme, a bude základem toho, jak v Softmedia nasazujeme AI do firem v následujících měsících.

Proč je to strategická změna, ne jen další AI hack

Dovolím si teď zabrousit trochu víc do strategie, protože pointa je důležitá i pro agentury, konzultanty a provozovatele SaaSu.

Konzultanti: Doteď jste prodávali hodiny nebo hotové balíčky. Klient si kupoval vaši dostupnost nebo výstup. V agentní éře se otvírá třetí cesta: prodávat operační logiku. Specifikaci procesu, kterou si klientův agent přeloží do exekuce. Jednou napsaný dokument, který žije dlouhodobě, updatuje se a klientovi přináší hodnotu každý den. Productized consulting přesně tímto směrem mířil už roky. Agenti teď dávají tomuto modelu zuby.

Agentury: Konkurenční výhoda nebude jen „umíme používat AI nástroje“. To umí skoro každý. Rozdíl udělá schopnost převést know-how firmy do struktury, kterou agenti umí stavět, upravovat a provozovat. Agentury, které se naučí psát dobré specifikace, budou mít stejnou výhodu jako ty, které dříve uměly psát dobrý kód nebo design. Umění formalizovat doménovou logiku je nová „hlavní schopnost“ pro B2B služby.

SaaS: Ne, zítra nezmizíte. Ale část vaší hodnoty se přesouvá jinam. Uživatelé, kteří by si dříve koupili vaši krabici, si teď mohou vygenerovat vlastní variantu z jednoduchého promptu. To platí pro nižší část trhu (jednodušší nástroje, interní tooling, mikroaplikace). Zatím ne pro komplexní enterprise SaaS s integracemi, compliance a ekosystémem. Ale tlak bude růst. Obranná strategie je zaměřit se na to, co agent nepostaví za víkend: hloubku integrací, síťové efekty, regulatory layer.

Klienti: Měli byste se začít ptát jinou otázku. Ne „jaký SaaS nám chybí?“, ale „která část naší práce je v hlavách lidí a dá se převést do strukturované specifikace?“. První otázka vede k dalšímu měsíčnímu předplatnému. Druhá vede k systému, který roste s firmou a patří jí.

Co to neznamená

Dovolím si být férový. Tohle neznamená, že zítra všichni přestanou platit za software. Neznamená to, že kdokoliv bez technického úsudku postaví robustní systém jen silou promptu. A rozhodně to neznamená, že přichází „digitální feudalismus“, kde pár velkých hráčů ovládne všechno.

Realita je pomalejší a špinavější. Agenti dramaticky snižují cenu prototypování a customizace. Specifikace se stává nositelem hodnoty tam, kde dřív byl kód. Ale infrastruktura, compliance, integrace, dlouhodobá údržba a governance zůstávají složité. A stále budou vyžadovat lidi, kteří vědí, co dělají.

Správnější čtení je tohle: software se přestává prodávat jen jako hotový produkt. Stále víc jde o kombinaci specifikace, agentního build procesu a lokální nebo polosdílené infrastruktury. To je velký posun, ale ne instantní přepis celého trhu.

Kde začít

Pokud vás to zajímá a chcete si udělat první praktickou zkušenost, zkuste tohle:

1. Vezměte jeden opakovaný proces ve vaší firmě.
2. Napište ho jako markdown specifikaci (cíl, vstupy, pravidla, výstupy, hranice).
3. Pošlete specifikaci do Claude Code nebo Cursoru s instrukcí „postav mi nástroj, který tento proces automatizuje podle této specifikace“.
4. Iterujte. Upravujte specifikaci, ne kód.

Za odpoledne uvidíte, jestli to pro vás dává smysl. A pokud ano, je to přesně ta vstupní brána do světa, kde se hodnota přesouvá z implementace na záměr.

👉 Nevíte, kde začít? Rádi vám poradíme, jak převést know-how vaší firmy do formátu, kterému AI rozumí. Zarezervujte si 30minutovou konzultaci zdarma.