Podcast

Dobrý den, jmenuji se Jirka Vycherek a vítám vás u dalšího dílu Ajta Krajta. Ne, vítám vás u speciálního dílu podcastu Datatalk, který připravujeme ve spolupráci s Ajta Krajta. Mými vzácnými hosty jsou dnes spíkři a lidé, kteří tvoří Ajtu Krajtu: výběr z hroznu – Šimon Podhajský, ahoj Šimone.
Ahoj.
Petr Glaser, ahoj Petře.
A Pavol Hejmy, ahoj Pavle.
Ahoj.

Dnes tu budeme mít takovou AI kolaboraci, protože podcast Ajta Krajta, pokud ho neznáte, si hned vyhledejte pod heslem „AJTA KRAJTA“ a dejte odběr. Pokud tak neučiníte hned teď, věřím, že na konci dílu se to jistě stane. Ajta Krajta je video podcast, který vychází každý týden a věnuje se AI infrastruktuře, respektive tomu, jak dnes vypadá software engineering s pomocí AI.

Vibe coding je termín, který mám pocit, že je takovým trendovým slovem. Probíráme, jak se vyvíjí software development díky rozvoji AI technologií. A právě o tom dnes budeme hovořit – provedeme si přehled toho, kde jsme, jak jsme se k tomu dostali a co nás čeká, co bude znamenat být programátorem v budoucnosti.

Na začátek vás, jako vždy, poprosím, abyste krátce zrekapitulovali svou cestu a představili se těm, kteří vás ještě neznají. Začneme nejstarším, tedy Šimonem. Šimone?
Mně se špatně říká, že jsem nejstarší. Čau, já jsem Šimon, původem jsem datový analytik, výzkumník a také trochu programátor. Studoval jsem kognitivní vědy na EILU a poté jsem se různě věnoval neurovědnímu výzkumu. Vždycky jsem byl v místnosti lepším programátorem než neurovědcem a zároveň lepším neurovědcem než programátorem, ale nakonec jsem se dostal čistě k datům. Byl jsem takový všeuměl, ale zjistil jsem, že AI a AI engineering mi umožňují propojit všechny mé schopnosti v datech, softwarovém inženýrství a výzkumu do jednoho celku. Takže jsem takto pivotoval a nyní se hlavně zabývám evaluacemi v AI a obecně způsoby, jak verifikovat výstupy, kterých díky generativní AI vzniká mnoho.

A co v současnosti děláš?
Pracuji jako AI engineer v malé společnosti jménem Waypoint AI. Když máte příliš mnoho Jira tiketů ve své velké firmě, my vám pomůžeme je vyhodnotit, škálovat ty, které nelze vyřešit, vyřešit ty, které vyřešit jde a obecně pomoci přestat se topit v záplavě obsahu.

Pavle?
Já jsem již bývalý webový vývojář. Přešel jsem od webového programování k AI agentům. Dlouho jsem vyvíjel aplikace pro vzdělávání, například populární Callboard – virtuální tabuli, která pomohla mnoha učitelům a dětem během covidu. Když přišla AI, začal jsem generovat weby a společně s mým spoluzakladatelem Jirkou, který je také součástí podcastu Ajta Krajta, jsme vytvořili software na generování webů. Ale nyní vytváříme AI kolegy, vlastního chatbota GPT, kterého může mít každá firma. Dokážeme mu definovat jeho znalostní bázi, pravidla a obecně duši toho AI agenta. Jsem tedy takový krotitel duší AI agentů.

To na vizici to opravdu vyniká, je to skvělé. Petře, co ty?
Jsem technologický nadšenec. Maminka říká, že jsem se narodil s klávesnicí v ruce. Přítelkyně si často stěžuje na můj mobil. Vždy mě technologie fascinovaly. Jako malý jsem četl Mobil Mánie a vše o Symbian OS, což mě velmi bavilo. Díky tomu jsem AI adoptoval velmi rychle – už v roce 2018, kdy byla první rozšíření do VS Code, začal jsem je používat s kamarády na VŠ.

To souvisí s mou zálibou v efektivitě. Pro mě vývoj není jen o psaní kódu, ale o tom, jak se stát „ten-times inženýrem“. To znamená mít dopad na tým. Být efektivní sám o sobě je jedna věc, ale druhá je správné nastavení procesů, kontrol a pravidel. AI do toho perfektně zapadá a urychluje fázi vývoje, prototypování a podobně, takže se tým může stát skutečně desetkrát efektivnějším.

Čím se dnes živíš?
Živím se konzultacemi a pomáhám firmám zvyšovat výkonnost jejich týmů pomocí AI, rovněž i vzděláváním a školením jednotlivců na kurzech, které provozujeme pod značkou Naučme IT.

Super, děkuji, že jste poskytli takové stručné představení. Jak jsem říkal před natáčením, pro mě jste vy tři a váš celý tým Ajta Krajta osobnosti, se kterými doufám natočím každý samostatný díl. Pojďme však nejdříve představit váš podcast. Jak vznikl? Proč se jmenuje Ajta Krajta? A co může pro někoho, kdo o něm slyší poprvé právě díky Datatalku, znamenat?

My jsme se vlastně všichni sešli na Slacku, který založil Patrik Braborec pod názvem AI v IT. Patrik začal dělat podcast sám, ale pak zjistil, že by ho rád dělal ve více lidech, a tak nás přizval. Sám to děláte, vím, je těžké dělat to sólově – všechny novinky, střih, obsah. Tak jsme rád skočili do toho s ním. Myslím, že ze současných tří hostů jsem u vzniku byl jen já, ale jak Ajta Krajta rozrostla, všichni jsme součástí hlavního core týmu.

S názvem jsem přišel já, protože rád experimentuji s jazykem. Díky tomu máme název trochu hračičkovaný, což nám fanoušci někdy vytýkají, ale stojím si za tím. Občas říkám, že vibe coding je vrtěpisectví a to mě baví. Možná proto není tak populární, protože je to trochu nadužívaný trefný výraz. Je to „aj ta krajta“ nebo „ajta krajta“? Pro mě je spíš „aj ta krajta“, ale dává smysl to používat jako jednu frázi, protože do vyhledávače se to zadává jako celek. Kdybychom to rozdělili, museli bychom konkurovat mnoha zavedeným termínům, ale „aj ta krajta“ je neobvyklé spojení.

O čem je Ajta Krajta, jaký je váš rozsah témat? AI je široké téma a vy jdete z pohledu software engineeringu, jak definujete scope podcastu?

Na začátku vždy probereme novinky, ať už z celého světa AI nebo konkrétně z vibe codingu, AI infrastruktury nebo dalších oblastí týkajících se AI. Potom se zaměříme na konkrétní témata, která nás právě zaujmou, buď co máme na mysli, nebo co řešíme v praxi ten týden.

Vždy projedeme krátké kolečko a pro mě je to zaměřené primárně na vývoj. Měli jsme i díly s filozofičtějšími tématy a úvahami o budoucnosti. Takové diskuze programátorů o tom, co je baví a kam chtějí směřovat. Jako původní výzkumník jsem tam občas přinesl nějaký preprint, který mi přišel zajímavý, ale ne často.

Já říkávám, že jsou to takoví nadšení fanoušci, kteří si povídají o tom, co je baví – ne anonymní programátoři. Já obvykle nemám teoretické zázemí, ale vždy ty věci vyzkouším a mám praktické poznatky o tom, jak to funguje nebo nefunguje.

Šimon zmínil Patrika Braborce, otce zakladatele, který to spustil. Myslím, že je vhodné poděkovat a připomenout, že nejste jen my tři a Patrik, ale že vás vytváří i další osobnosti. Mohli bychom je také představit?

Ano, kromě Patrika Braborce jsou v týmu Matyáš Třeček z DX Heroes, potom Jirka od Pavola, dále Prokop – rovněž z DX Heroes. Občas je s námi i Jacek, který má široké spektrum zkušeností a vždycky je s ním skvělá diskuse. Je zkušební datový analytik, který je známý i z předchozích dílů Data Talku.

To vám závidím, že ho máte tak často, rád bych ho také mezi naše moderátory. Je důležité zmínit, že máte týdenní frekvenci – tedy každý týden vychází nový díl. Obvykle jsou díly přibližně hodinové, že?
Ano, snažíme se trefit do hodiny, i když je to těžké. Po skončení natáčení ještě zůstáváme a diskutujeme další půl hodinky až hodinu bokem.

Momentálně máte za sebou již dvacátý díl, že?
Je to spíš jednadvacátý, k půlce září, začátku října 2025, takže za chvíli to bude půl roku.

Za mě jste se velmi dobře etablovali. Je vidět, že jste trefili jak téma, tak formát. Hrozně mě to baví, i když už nejsem vývojář. Proto mám radost, že jste tu, protože jsem fanoušek a přeji Ajtě Krajtě velký úspěch.

Pojďme ke konkrétnímu tématu, o kterém mluvíte každý týden. Já i další hosté v různých dílech často současný stav řešíme. Konec roku 2025 – jak jsme na tom? Jaký je stav vibe codingu? Říká se tomu ještě vibe coding? Jaká je AI infrastruktura? Jak dnes vypadá smysluplná práce programátora? Nemluvím o hraní si s nástroji či slovy, ale o skutečné produkci aplikací. Jak vypadá aktuální technologický stack programátora, který chce být produktivní a zároveň vytvořit skutečné aplikace, ne jen drobné hračičky?

Podle mě jsou to velmi otevřené nůžky, protože se stále více projevuje dovednostní úroveň lidí. Na jedné straně jsou lidé, kteří jsou v korporacích pod silnou kontrolou a nesmí používat téměř nic mimo oficiální nástroje – zde jsou rádi, že mají GitHub Copilota. Na druhé straně jsou lidé, kteří už dělají migrace mezi jazyky a spouštějí stovky agentů paralelně.

Je to extrémně široké spektrum a nedá se říct, jaký je přesný stav napříč celým světem vývoje softwaru.

A co se týče nástrojů, kde jsme nyní? Kdysi jsem se smál Gartner Hype Cycle jako konceptu, protože je to univerzální 2×2 matice použitelná na cokoliv. Čím více se ale tomu věnuji, tím víc v tom Hype Cycle vidím pravdu.

Došlo ke vzniku ChatGPT, všichni se báli, že programátoři přijdou o práci, že přijde revoluce. Nyní, o dva a půl roku později, když se podívám do IT firem, programátoři jsou stále potřeba, stále se noví nabírají a jejich práce z velké části zůstává stejná, nejen proto, že jsou v korporacích, kde nemohou inovovat, ale i obecně.

Co se tedy za poslední rok změnilo? Kam jsme se posunuli?
Za mě největší změna je, že je nyní možné důvěřovat „hands-off“ programovacím agentům – agentům, kterým se zadá specifikace a oni za desítky minut vytvoří hotové řešení sledující pokyny v repozitáři. To je samozřejmě zatím pro omezený počet repozitářů a některé firmy tuto možnost vůbec nemohou využít.

Mám pocit, že v tomto platí výrok, že budoucnost už je tady, jen není rovnoměrně rozložená. Nebo jak se to překládá.

S tímto naprosto souhlasím. Myslím, že je to tak, že budoucnost je zároveň mnohem pomalejší i mnohem rychlejší, než si myslíme. I když máme úžasnou technologii, která toho zvládá hodně, neznamená to, že se všude plošně hned používá. Na druhou stranu tam, kde se používá správně, technologie dokáže mnohem více, než je všeobecně známo. A adopce AI nebude otázkou měsíců, spíš deseti let, kdy budeme řešit, které firmy AI používají a které ne.

Máte nějaký srovnání? Jsou velké jazykové modely (LLM) novým cloudem nebo novým internetem?
V našem promu používáme příměr, že agenti a konkrétně agenti jsou zcela novou formou aplikací. Podobně jako web byl novou formou aplikací oproti klasickým aplikacím na CD.

V roce 2015 bylo ještě mnoho aplikací na CD, fungovalo to dobře, a existovala skupina lidí, kteří nechtěli web, ale bylo jasné, kam směřuje budoucnost. Myslím, že jsme nyní na úrovni roku 2000, což byl počátek webu.

Přijde tedy dotcom bubble?
Zcela jistě nějaká bublina přijde, to je jasné. Některé věci jsou přehnaně nadhodnocené. Na druhou stranu, do roku 2000 sice web zažil krizi, ale dnes je dotcom éra základem moderního světa.

Je klíčové, že AI už teď přináší hodnotu. Ano, je tam velký hype a spousta marketingových nástrojů bez opravdové hodnoty. Některé firmy na to naletí, ale když je AI správně implementována, firmy mohou vydělat obrovské peníze.

Líbí se mi, jak o tom uvažuje Pavel – i když jsou vysoké náklady na používání AI, šetří čas, který má on. Pokud se to dá spočítat do rovnice, pak je přidaná hodnota pro firmy obrovská, protože programátoři mají stále na trhu dobré platy, a plat chudého programátora neexistuje, takže to podle mě ještě chvíli vydrží.

Často se setkávám s názorem, že AI je extrémně drahá, že tokeny jsou neskutečně drahé. My v Praxi utrácíme každý měsíc za vývoj asi 800 dolarů, což je poměrně vysoká částka vzhledem k tomu, že tam programuji já sám a Jirka nepíše kód.

Na druhou stranu, s čím to srovnávám? Když jsem dvakrát efektivnější programátor, rozhodně se to vyplatí. A druhá věc je, že tokeny jsou teď nejdražší, co kdy byly. Za rok budou pětinovou cenou. Když se s tím lidé naučí pracovat teď, získají velkou výhodu do budoucna.

Nejsem si jistý tou pětinovou cenou, protože spousta venture kapitálových peněz jde právě do poskytování těchto tokenů, takže jsou teď levnější, než by normálně měly být. Je to jako Uber v roce 2013, kdy bylo možné si objednat soukromou limuzínu za dva dolary. Dnes už to není možné, protože to není sponzorované venture kapitálem. Uvidíme, jak se tyto tlaky vyrovnají.

Také myslím, že cena tokenů klesat nebude tak rychle, protože přišly i modely jako GPT-4 Pro, které jsou extrémně drahé. Ty stály například 150 dolarů na vstupu a 600 dolarů na výstupu. Přichází zde také test time scaling, kdy modely přemýšlí.

Nejde tedy cenu tokenů úplně stlačit na minimum. Krásnou ukázkou je třeba Grok, který je šestkrát levnější než GPT-4.1 na cenu tokenů, ale výsledná cena…

Artificial Analysis benchmarku je tedy ještě dražší než Klot, nebo byl teď, myslím, tam byly nějaké čachry s cenami. Ale ten reasoning se do toho promítne, takže i když bude mít tokeny extrémně levné, neznamená to, že bude ten provoz extrémně levný.

To je jako strašně dobrá připomínka, protože před dvěma lety, typicky i dobrý horizont jsou dva roky, to bylo tak, že co člověk napsal do chatů GPT nebo do nějakého stroje, šlo to do modelu, a co ten model vyplodil, to šlo uživateli. Dneska je to tak, že velmi často dochází k mnoha interním dialogům buď tím modelem samotným, nebo mezi různými agenty, a velmi často to, co člověk napíše a co člověk vidí, je pouze nějaká vrchní vrstva toho, co se promalé odehrává v celé orchestraci.

A to je moje otázka. Mně se hrozně líbilo, jak jsi říkal, že to přináší hodnotu. Že ta hodnota, jestli to stojí za to implementovat a pracovat s tím, jak moc je to v produkci, spočívá v tom, jestli to přináší hodnotu. A tam vidím, že se posouvá laťka jak v případech, kdy to dává smysl používat, tak i v hodnotě, kterou to přináší v těch případech, kdy to smysl dává.

Když se na to podíváme zase, pro mě je to nějaké srovnání a pohled v čase. Jak říkáš, dva roky, co se za ty dva roky stalo, že hodnota pro někoho, kdo je programátor nebo chce programovat, vzrostla? Je to tím, že se posunuly modely? Je to tím, že vznikly nástroje kolem infrastruktury na CICD a monitoring, prostě nové frameworky, a prostě že na celém světě vzniká infrastruktura? Jsou to nějaké konkrétní věci? Že je to právě reasoning, že předtím, protože během toho, že nebyl reasoning, výstupy neměly takovou hodnotu, měly větší chybovost?

Jsou tam nějaké momenty, možná na tebe, Petře, protože ty jsi v tomhle OG ve smyslu, že jsi začal „before it was cool", kdy to bylo opravdu spíš experimentování a hraní si a ta hodnota byla nejistá. Co se za tebe změnilo? Jak to postupovalo? Za mě je to určitě ten reasoning, ale on tady byl a bylo to v podobě Chain of Thought a podobně, ale pro spoustu lidí to byla neznámá technika, takže na začátku bylo fakt důležité umět dobře promptovat, abychom dostali ucházející výsledky.

Teď už i z jedné věty zvládneme dostat mnohem víc a na vině jsou reasoning modely, jsou na vině kombinace modelů, agenti, nástroje, protože se vyvinula i infrastruktura kolem, což je strašně důležitá věc. Dneska už to není o tom, že model se nějak magicky napojí na web a automagicky vyhledává, což je moje oblíbené spojení, ale už to máme jasně vydefinované. Máme tam přímé napojení na Sentry, přímé napojení na GitHub a v tu chvíli jsou modely mnohem mocnější.

I když by se třeba zdálo, že to není klíčové, jasnou ukázku máme u Claudea. Když mu nedáte žádné nástroje, je jako hloupější než ostatní, ale těmi nástroji to extrémně dohání, protože je excelentní v toolcallingu.

Já bych řekl, že Petřova věta byla hodně klíčová, že se do velké míry posouváme od nástrojů k agentům. Ještě z minulosti jsme měli jeden nástroj, druhý nástroj, třetí nástroj a museli jsme je nějak ovládat. A to, jak jsme je ovládali, bylo psaním textu. Ale posouváme se do budoucnosti, kdy budeme mít autonomně jednající software, který může používat nástroje, otevřít si prohlížeč, volat API, eskalovat na lepší model, nebo se zeptat člověka. A myslím, že tahle autonomie je velmi velká věc. Samozřejmě ji musíme kontrolovat.

Možná než skočíme do té budoucnosti, Petře, když říkáš, že jsi začal s nějakou formou copilota, s nějakým AI asistentem na kódování, asi ještě ne na programování, ale kódování, a začal jsi hrát s tím v roce 2018, co to bylo? Jak to fungovalo 2018 a jaká byla ta časová osa, kdy jsi tomu začal věřit?

Tehdy to byla jenom chytřejší inteligenace, protože si myslíme, že to posunula průlom GPT, ale realita je, že tehdy TabNine byla fakt velká věc. Intellisense napovídal jedno-klíčové slovo, TabNine uměla třeba celý řádek. To byl první milník, ale byl to pořád jen nástroj pro vývojáře.

Dalším průlomem byl příchod GitHub Copilota v roce 2021 a firmy ho vůbec neznaly. Já jsem o rok později, co to vyšlo, selhal na pohovoru do Binance, protože mi dali zadání, já jsem si ho napsal jako komentář, zmáčkl nový řádek a Copilot mi vyplivl celé řešení. Oni řekli: „Co děláš, ty podvádíš?“ A já říkám: „Ne, to je moje běžné workflow.“ Ale firmy to vůbec neznaly.

Takže to byly dva milníky, kdy to ale pořád byla jen taková completion, buď větší nebo menší. Dneska už jsme mnohem dál, i když pro spoustu vývojářů stačí tabulátor jako klíčová funkce. Pokud dělám mapování a repetitivní činnost, je to neskutečný pomocník i bez těch modernějších věcí, jako jsou agenti a wirecoding.

A zase, když se vrátím do současnosti, co zvládne AI asistent samostatně vytvořit, kde potřebuje vaši pomoc, kde je ta hranice? Na jaký úkol ho skoro nepustíte, protože víte, že to je více práce než užitek, a na jaké úkoly s pravděpodobností hraničící s jistotou víte, že to zvládne a že to tam můžete dát?

Jaké úkoly do produkce programátorské už dávate AI agentům a asistentům?

Mluvili jsme o Stack-driven development, a i když dokážu vyprodukovat specifikaci pomocí chatů GPT nebo čehokoliv, přiznám se, že stále držím výsledek specifikace pod kontrolou. Nenechám agenta běžet se všemi možnými technologiemi, které si vymyslí, ale jen s těmi, které jsem schopen verifikovat. To, že si agent vymyslí, že by tam byla dobrá Kafka, neznamená, že tam Kafka prostě je.

Mám pocit, že i když scaffolding, tedy původní nastavení repozitáře, je něco, co model dokáže udělat dobře nebo alespoň schůdně, aby to fungovalo, tak ideální je, aby se sám potom dokázal verifikovat, jestli to funguje. To je ale věc, kterou spíš nechávám na šablonách, než že bych nechal agenta udělat vše na první dobrou a doufat v bezchybný výsledek. Potřebujeme mít pevné základy, na kterých stavíme.

Ale pokud jde o delší úkoly v rámci repozitáře, který má historii a kontext, ty už dokážu delegovat agentovi, pokud má dostatečně jasnou specifikaci, kterou si často on sám dokáže vygenerovat na základě velmi vágního zadání. To je vlastně ten moment, kdy začínáme překlenovat ty mosty – že dnes už dokážeme předpokládat, co vágní zadání znamená pro konkrétní implementaci a jak má specifikace vypadat, aby cestu k implementaci co nejvíc usnadnila.

Šablony jsou podle mě klíčová věc. Je to jedna z věcí, kterou lidem neustále opakuji, a co často přichází na kurzy lidem, kteří chtějí tvořit například vlastního chatbota.

Udělání dobrého chatbota je docela složité. Pokud chci mít navazování na stream, kdy obnovím stránku nebo něco podobného, a nechám to udělat AI, rychle narazím na problémy. Ale pokud použiji šablonu, která tohle má vyřešené, AI s tím pracuje mnohem lépe.

Za mě dávají šablony smysl víc než kdy dřív. Třeba i my v Naučmě IT tvoříme vlastní šablonu, která má podchycené věci jako UI knihovny, stylování a i pravidla pro agenty, protože právě rule files jsou klíčové pro kvalitní práci AI s projektem.

Osobně vidím paradoxní efekt, kdy AI nebo AI agenti jsou strašně dobrí na dvě zcela rozdílné věci.

Jedna věc je nasetupování projektu od nuly, se vším všudy. To jsou nástroje jako Levelball nebo český Makaly, které jsou absolutně skvělé, a pokud člověk nepotřebuje na projektu výrazně dále pracovat, pokud je to opravdu nějaké MVP, je to bezkonkurenční způsob, jak takovou věc dělat.

Druhá možnost, ve které je AI velmi dobrá, je, když už mám systém s vlastní architekturou, pluginy, stránkami a já tam chci doimplementovat jednu věc.

Například ve Frontbooku máme engine pro orchestrace a výrobu těchto agentů. Máme třídy, které reprezentují jednotlivé AI providery – OpenAI, DeepSeek, Gemini, Claude – a pokud potřebujeme doimplementovat dalšího providera, nebo aktualizovat existujícího, AI agent to udělá prakticky bezchybně.

Protože už ví, na co navázat, podívá se na ostatní příklady, má šablonu čistého providera a dokumentaci. Údržbu těchto věcí pak už dělá agent. A stojí nás reálně třeba pět dolarů měsíčně.

To je podle mě skvělá věc. Zmínil jsi, že už má agent základy, čeho se držet, protože já, když používám EffectTS, svoji oblíbenou knihovnu v TypeScriptu, kterou označují jako „TypeScript dead scales“, je zapravení kódu hodně náročné.

Je to v podstatě kód v kódu, typický TypeScript to není. V některých případech se mi osvědčilo si naklonovat celé jejich repo a nechat AI s ním pracovat, aby mohla z něj vyzobávat potřebné části, než abych nechal AI hledat jen v dokumentaci.

To teď začal dělat i GPT-5 a GPT-5 Codex, což posunulo věci na novou úroveň, protože automaticky čtou node_modules a získávají kontext.

Simunek? Ne, jen mě teď napadlo, že jsem překvapený, že jsem ještě neviděl MCP, tedy Model Context Protocol server, který by implementoval QuickieCutry nebo Copier, či LookUp mezi existujícími šablonami. Dávalo by smysl dát AI nástroj, který by mohl obsadit tu či tu danou šablonu.

A tím se dostávám k tomu, co nazýváte šablonami.

Když řeknu šablony, a ty říkáš, že v Naučmě IT tvoříte šablony – ty, Pavole, že máte šablonu na providery modelů – jak definujete šablonu? Kde sedí a co má správná šablona mít?

U nás to vypadá tak, že máme AI agenta. Zatímco normální projekty mají frontendáře, backendáře, specialistu na data, my máme kolegu, který aktualizuje modely, jiného, který přidává modely, dalšího, který přidává scrapery, a podobně – těch „kolegových“ máme asi 20. A pokud potřebujeme aktualizovat modely, spouštíme agenta specializujícího se na aktualizaci modelů.

Technicky je to udělané tak, že se to do system message dostane přes nějaký registry, který orchestruje promptbook a vloží tam příslušné instrukce.

Pro mě jsou šablony spíš ta část kódu. Může to být od komponent, což je ve frontendovém vývoji hodně populární, třeba komponování, až po celé aplikace, které jsou scaffoldnuté se vším všudy – s linterem a podobně.

Záleží na tom, co chci dělat.

Jak Pavol zmínil Levelball nebo Makaly, říká, že tyhle nástroje už stačí, ale na pozadí mají šablony. Makaly se například odlišuje tím, že běží na Next.js, což jim dává benefit, že stránky mají dobré SEO, protože se renderují na serveru. Ostatní běží na Vercelu, což má své výhody i nevýhody, a přenastavitelnost je trochu odlišná.

Na pozadí jsou vždy šablony v podobě kódu. Myslím, že když se tyto dva přístupy spojí, vznikne ultimátní kombinace.

Možná se pak Pavolovi ozvu s nápadem: pojďme vytvořit agenta na mou šablonu.

Před dvěma lety jsme měli my nápad generovat weby z jednoho políčka. Byli jsme bohužel moc brzo, a navíc nebyli úplně dobří webaři.

Spalili jsme se ve dvou věcech. Jedna byla, že modely GPT-3.5 nebyly tak dobré, aby bylo možné stavět na Levelball či Makaly. Druhá byla, že jsme si mysleli, že pokud to dobře napromptujeme a vyřešíme AI, budou weby skvělé.

Měli jsme sice dobrou AI, ale tvořili jsme opravdu špatné weby. Ty weby, co padaly z AI, byly opravdu katastrofální.

Strašně jsme podcenili to, že nástroje jako Makaly jsou do stejné míry AI a do stejné míry webdesign, tedy tvorba a nastavení webu jako takového.

Šablona tedy není nějaká specifická funkce, ale to, co vkládám do modelu jako kontext – jak moc informací o infrastruktuře a nové aplikaci má, a jak moc se má držet předem definovaných pravidel.

Pokud existuje předloha, která jde do systému a promptu, je jasné, že je možné mít šablonu úplně bez AI typu CookieCutter nebo moderní Copier, kde přes Jinja se definuje celá adresářová struktura s různými parametry, které se během počáteční generace naplní.

Představme si, že AI dodá parametry, ale generování původního textu a souborů je plně deterministické.

Pokud tedy přijdu k projektu, rozbalím ho, mám AI software engineering team, a přemýšlím, jak moc tam jsou reální lidé, agenti a tak dále, ale mám kontext, šablony, model, tool use, prompt.

Jaká je v tuto chvíli váha jednotlivých částí infrastruktury?

Minule byla to system message a říkali jsme, že je to prompt engineering, ale jak říkáte, modely se posouvají – mají více kontextu a tool use, takže i horší prompt vede k dobrým výsledkům. Už to není tak, že je třeba mít prompt dokonale nastavený.

Jak to tedy teď vypadá, když chci generovat kód a programovat s AI? Musím mít všechny věci perfektně nastavené, nebo se to v čase posouvá?

Za mě je oblíbená programátorská odpověď: „To záleží.“

Na některé aplikace nepotřebuji vůbec nic, stačí mi „hloupý“ prompt. Ale obecně platí, že s AI power developmentem se dostanu dál, když věnuju čas nastavení a setupu.

I drobnost, třeba nastavení kontroly kvality kódu, aby projekt byl konzistentní, posune věci mnohem dál.

Já třeba do rule files záměrně píšu „never use any“ a to je klíčová věc. AI sice občas „any“ použije, ale méně než dřív.

Fakt přísná kontrola je podle mě 40–50 % váhy úspěchu.

Kontrola může být v podobě pravidel, nastavení CICD, linteru a tak dále, ale může to být i moje zpětná vazba.

Bylo by určitě dobré se podívat, co je celý ten systém pod kapotou, protože tady mluvíme o promptu, system message, tool callingu a nakonec, když se podíváme opravdu do hloubky, model jen doplňuje text.

Zdá se, že má větší váhu system message, user prompt nebo tool calling, ale to je jen jinak zařazený text uvnitř toho doplňování.

Některé případy hodně záleží na kontextu, kde je text vložen, jiné ne, a více záleží na samotném...

[pozn. text končí náhle – předpokládám, že chtěl pokračovat, ale chybí pokračování]

Text. Dáváte příklad? Například my hodně řešíme agenty, kteří mají opravdu velkou znalostní bázi. A teď je taková věc, která se nazývá REC, Rational Augmented Generation, která vlastně umí dělat to, že když mám opravdu velké množství textu, tak ho rozsekám na nějaké logické kousky, které se zaindexují, a ty do promptu dávám nějakým dynamickým způsobem. Ve chvíli, kdy toto dělám a dávám tam poměrně málo těch kousků, je podle mě skoro jedno, jestli jdu do system message nebo do promptu.

Ale často, pokud toho textu není moc – například cca 100 normostran – a nezáleží mi tolik na tom, aby to bylo rychlé nebo levné, tak můžu udělat rychlý prototyp a prostě to vložit rovnou jako celek do celého promptu. A tam pak hodně záleží na tom, jak to celé nastrukturuji.

Jako kam dávám ty instrukce? Typicky interně v rámci toho engine dáváme instrukce jak na začátek, tak na konec, označíme v nich, co jsou parametry a co jsou instrukce. A všechny parametry, které jdou do stejného promptu jako instrukce, velmi dobře odsadíme a vydefinujeme tak, že cokoliv, co se vyskytne, nepřepíše instrukce, ale je to jen nějaký parametr, který jsem zadal. Připadá mi, že před dvěma lety se bez RAG prakticky jakékoli větší znalostní báze nedaly dělat.

Dnes je situace taková, že spoustu aplikací lze protlačit tím, že má člověk velmi dobře strukturovaný proces se vším kontextem. Klíčová fráze je „context engineering“ místo „prompt engineering“, kde se bavíme v zásadě o dvou věcech. První věc je, jak napsat aplikaci s dobrým context engineeringem, což je to, co řeší Pavel – jak správně vybrat ten kontext, aby byl co nejrelevantnější, aniž by zabíral velké množství kontextového okna, a tedy aby to netrvalo dlouho a nebylo to drahé.

Druhá věc je, jak na straně uživatele používat aplikaci tak, aby si aplikace sama dokázala najít ten kontext co nejefektivněji. V Cursoru například řešíme, jaké soubory tagnout nebo jak naspecifikovat prompt tak, aby Cursor věděl, co si má dohledávat a podobně. Jsou to trochu jiné schopnosti, ale nakonec hodně přemýšlíme o tom, co všechno rvát do kontextu a kdy.

Když to shrnu pro někoho, kdo nás poslouchá, dívá se a je ve fázi GitHub Copilot – zatím mu to dokončuje řádky, ale negeneruje celky, a teď si řekne, že do toho půjde – prostě se chce stát AI inženýrem, aby měl za několik let ještě práci. Už jste ho přesvědčili? Nebo zde mě přesvědčil moment, kdy jsem si řekl, že web coding není trend, a už to je realita.

Bylo to třeba, když jsem tady měl Petra Baudiše. Když hardcore back-endák, Linuxák, někdo, kdo byl contributor na Gitu, říkal, že většinu kódu generuje AI a čím víc tvoří méně kódu sám, tím více času tráví přemýšlením u tabule. Pro mě to byl ten moment.

Když nás poslouchá někdo, kdo si zatím s AI jenom hrál a teď by chtěl to dostat do produkce, nemyslím si, že začne vytvářet šablony a celé prompt booky, nebo AI agentní infrastrukturu pro celý vývojový tým. Jaké jsou kroky, když jsem na začátku a chci produktivizovat AI pro svou klasickou softwarovou inženýrskou práci? Jsem v nějakém scale-upu nebo na vlastním projektu.

Dokumentace. Rád začínám přednášky otázkou: Kdo z vás má tak dobře zpracovanou dokumentaci, že by za ni dal ruku do ohně? Z stovek lidí, kteří na mých přednáškách byli, se mi zvedla tak na půl ruky jedna. Dokumentace je klíčová, a to platí jak pro lidi, tak pro AI.

K AI se k dokumentaci musí přistupovat jinak, ale dobrý základ je zdokumentovat architekturu, zdokumentovat technologie, popsat třeba výběrový proces, protože pokud jsem v korporátu a mám omezení na použití legálních licencí, AI nemohu nechat takhle přidat knihovnu podle libosti. Spíš si to musím naprogramovat sám, nebo to kontrolovat. Proto je potřeba sepsat celý proces dobře, ideálně do repozitáře.

Pak to mám uložené přímo v projektu a nemusím řešit připojování na Confluence, kde nechávám AI vyhledávat a kde přidávám spoustu pohyblivých částí, které ohrožují kvalitu. Pokud mám dokumentaci v repozitáři, výrazně zvýším šanci, že mi začne přinášet hodnotu. A potom si mohu hrát s tím, že ji rozdělím na více souborů, některé editory dokonce podporují podmíněné includování instrukcí.

Například když je to spec.ts, tedy testovací soubor, vloží se do promptu, ale jinak ne. Takže začít monolitem, pak to rozdělovat, a časem můžu pracovat i s tím, že nechám AI refajnovat dokumentaci na základě codebase.

Řeknu: „Tohle je naše dokumentace, takhle vypadá codebase, podívej se, jestli tam něco není porušené, uprav to,“ a takhle iteruji i samotnou dokumentaci. Pak ji dělím na dokumentaci pro člověka a pro AI, protože člověk často nepotřebuje pět nebo deset příkladů, stačí mu jeden, ale AI jsou konkrétní příklady klíčové – tzv. few shots, takže třeba přidávám jich hodně.

To, co by Petr řekl, je podle mě úplně klíčové. Vidím dva ortogonální směry, které jsou vlastně něco úplně jiného. Jeden směr je umět AI dobře použít ve vývoji, aniž bych musel rozumět interním principům AI – prostě ji umět používat. Druhý směr je umět vyvíjet AI agenty, správně nastavovat pravidla a znát AI do hloubky.

Myslím, že pokud člověk vytváří klasickou aplikaci – web nebo mobilní app – je téměř lepší se učit věci kolem, které pomohou ukrotit AI nástroje, než se učit AI nuance. Typicky to, co říkal Petr, dokumentace – to je úplně klíčová záležitost. Dobře používat Git, kontrolovat změny v kódu, mít dobře napsané unit testy. To vše je často mnohem důležitější než mít dobře vypromptovaný kód.

Půjčím si ještě jeden postřeh od Jacka, který říkal, že pro praktické překlopení stavu, kdy někdo je začátečník, je klíčové být ochoten iterovat a experimentovat. Ať už s dokumentací, používáním AI agentů nebo samotnými nástroji. Podle něj lidé, kteří umí AI dobře používat, začínali tak, že zkoušeli, co funguje a co nefunguje, a nenechali se odradit neúspěchem. Protože ne všechny repozitáře podporují všechny ty praktiky, ne vše se dá naučit z YouTube, ale je třeba zkusit mnoho přístupů a zjistit, co funguje.

Důležité je nenechat se chytit do lokálního maxima, kde věci fungují „tak nějak“, ale ne úplně dobře, a zkusit to klidně úplně jinak. To je důležité jak pro AI-enabled programátory, co chtějí programovat s AI, tak pro AI inženýry, kteří vyvíjejí AI a integrují AI do aplikací.

Mně osobně se hrozně líbí „back to basics“ přístup – prostě „shit in, shit out“. Zaujal mě Petrův postřeh o dokumentaci pro agenty a dokumentaci pro lidi. To, co říkáte, mi připadá jako nábor nového kolegy do týmu. Čím lepší mám dokumentaci, čím logičtější strukturu a víc kontextu, tím více do projektu můžu pustit někoho cizího, protože mám nastavená pravidla tak, aby mi projekt nerozbili.

Na druhou stranu, pokud chce někdo přispívat, tak ví, kam a jak. Je určitý rozdíl mezi pořádkem pro nové lidi a pořádkem pro AI agenty. Jak se liší dokumentace? Kromě většího počtu příkladů, aby byla velmi precizní.

AI agent je jako mimozemský programátor – umí být vynikající programátor, pokud mu dám správný kontext, ale úplně mizerný, pokud se netrefí do kontextu. Platí tu anekdotická evidence, že mnoho lidí říká, že AI nefunguje, protože zkusili nějaký nástroj, zadali něco a výsledek byl špatný, takže AI už nepoužívají.

Je to jako říct, že čínské jídlo je špatné, protože jsem v čínské restauraci dostal spálené jídlo a už nikdy nebudu jíst čínskou kuchyni.

Příměr s mimozemšťanem je pro mě klíčový. Když juniorovi řeknu, že se funkce definuje jinak kvůli breaking change, obvykle to pochopí po první nebo druhé instrukci. Po třetí už zvažuji, jestli je to dobrý hire. U AI je to úplně jinak. Musím příklady uvádět opakovaně, i různými způsoby.

Je třeba je dát do promptu, přidat příklady s fungujícím konkrétním souborem, a přesto to nemusí fungovat. Je to docela nepředstavitelný způsob komunikace, jaký by člověk nepoužil.

Za určitých okolností si říkám, že čím víc má takový junior guardrails a přesné specifikace, tím méně je junior. Na druhou stranu, když specifikaci píšu sám, odsuzuji AI k roli juniora, místo aby byla senior a napsala, co je právě potřeba podle problému.

Je možné, že to už dnes zvládá lépe, jen z mé minulé zkušenosti, kdy jsem byl jednou v čínské restauraci, AI mi navařila čínské menu, které mi nechutnalo, tak jsem to nenechal zopakovat.

Proto stále potřebuji experimentovat. Vždycky chcete kuře, chápu.

Pokud by někdo chtěl začít se spec-driven developmentem, za mě je super počin od GitHubu – mají spec kit, který funguje s Claude Code a Codexem, a přidávají další.

Nebo nedávno Eric Elliott vydal knihovnu AIDD (AI-driven development), kde nabízí rule files nebo sub-agenty, připravené pro lepší fungování a lepší specifikaci. Klíčové je, že specifikace má několik dílčích kroků.

Soustředím se na biznis logiku, přečtu si ji, podívám se, jestli ji AI vůbec pochopila. Když specifikuji dílčí části, dosáhnu lepších výsledků, než když prostě řeknu: „Uvař mi čínské jídlo“ nebo „Kup mi Čínu a Bill Gates se vrátil a koupil celou Čínu“. To je stav technické restaurace.

Když jsme u čínských restaurací a toho příměru, tak jedna z klíčových věcí nejen v programování je, aby nevznikal tzv. Bobik efekt, kdy AI se snaží vyhovět za každou cenu, bez ohledu na rozumnost řešení. Často nabídne věci, které nedávají smysl, jen aby uživatele uspokojila.

Je velmi důležité mít způsob, jak AI challengeovat, říct jí, že dobrý výsledek může být i „tady je to hloupost, neuděláš to, zastavíš se a řekneš něco“. Když totiž ne, naprogramuje to bez ohledu na kvalitu, možná s kritickou zranitelností nebo úplnou nesmyslností.

Tento způsob přemýšlení aplikuji. Ale je to stejné s juniorem – když něco nefunguje, může přijít a říct, že to nefunguje. Ale často junior rovnou udělá věc, která nefunguje a je to vidět na první pohled, takže se to musí řešit.

AI vám často dá kód, který technicky funguje, ale obsahuje zmíněnou „pitomost“. AI je skvělá v tom, že si ohýbá pravidla tak, aby to fungovalo. Například jsme to měli v komentářích Fight a Cryta – AI prostě vypne testy, aby kód prošel.

Takže „disable tests so that it passes“. Takto to nefunguje, ale splnila to. Jasně, to je to, na co optimalizujete.

Přesuňme se trochu k zemi – podívejme se na reálnou práci u počítače „při tvorbě softwaru“ krok po kroku.

Jak vypadá tvůj stack? Jaký je tvůj tvůrčí proces?

Pro mě je silný základ to, jak dobré mám frameworky pod tím. V tomhle skvěle funguje například Convex, alternativa k Supabase. Je to databáze, ale nabízí i kompletní SDK, což znamená, že AI nemusí řešit synchronizaci mezi uživateli, protože to má out of the box zabudované.

To jsou typické věci, kde AI „nabíhá“. Pokud začnu řešit paralelizaci, synchronizaci, offline dostupnost, AI začne vymýšlet hlouposti, protože to není dodnes vyřešený problém mezi vývojáři.

Částečně za to může Apple, který blokuje nebo aktivně ničí PWAčka, což je komplikované téma. Proto začínám stavět stack tak, aby byl AI-enabled.

Ze stejného důvodu si raději vyberu React, i když není úplně optimalizovaný, než Svelte, protože v React ekosystému je mnohem víc dat a knihoven.

Začínám podřizovat technologický stack AI, ale zároveň si v klíčových věcech vytvářím toolkit složený z evaluací, promptů a dalších nástrojů, abych mohl používat technologie, které chci, protože z dlouhodobého hlediska AI pomohou správně nasměrovat – což je efekt, o kterém jsem mluvil.

Pojďme jít ještě blíže ke kódu.

Máš nějaký projekt nebo zakázku, otevřeš notebook a jdeš programovat. Jaké máš IDE? Co tam máš nastavené? Co se vlastně děje?

Jednoznačně Visual Studio Code (VSCode). Dlouhodobě říkám, že používám Insider’s Edition, která má zelenou ikonku, a GitHub Copilot v Preview edici.

To mě posouvá měsíce dopředu. Lidi říkali, že GitHub Copilot nemá MCP podporu, já ho používám od prosince, protože to tam už je.

Nastavím si základní pravidla – vždy používáme linter, který spouští pravidla, to je současný standard.

Ideálně vynucuji po každé změně souboru spustit nástroje na linting, formátování a podobně.

A přizpůsobuji tomu i rychlost, protože když AI čeká třeba 40 sekund na výstup, často ztratí trpělivost a napíše „it hangs“ nebo něco podobného.

Tyto pravidla máš v systémových instrukcích, nebo je máš někde přímo zapečené? Nebo máš šablonu, kterou používáš při každém projektu?

Šablonu ještě nemám dotaženou tak, abych ji používal v každém projektu, ale očekávám, že třeba do příštího měsíce už ji budu mít jako plně hotovou. Je to něco, co dávám do Agents...

(Pokračování textu není zadané.)

Markdown (MD) používám jako klíčovou věc, ale hlavní navigační soubor spíše slouží jako rozcestník. Typicky, když potřebujete udělat něco konkrétního, použijete určitý soubor. Má to jednu velkou výhodu, protože já mám minimalistický hlavní soubor, který pak mohu rozduplikovat do různých vývojářských nástrojů. Stále totiž nemáme jednotný standard. Někteří používají Agents MD, Cloud MD a další. Když to tedy minimalizuji, nevadí mi malá duplicita, kterou vyřeším právě tím rozcestníkem.

Toto je vlastně můj minimální stack a vše dlouhodobě vyvíjím v TypeScriptu, jak na frontendu, tak na backendu. Zatím to nemá takové výhody, jaké by mohlo mít, protože integrace s Language Server Protocol, aby AI vidělo to, co IDE, tam ještě tolik není. Například GitHub Copilot už to má částečně integrované. A to přináší obrovský přínos, protože jsem najednou typově bezpečný (TypeSafe) od databáze až po frontend a ve chvíli, kdy AI "vidí" kód, aplikace se vůbec nezkompiluje, pokud data z frontendu nesedí na backend. A tak to teď opravdu funguje.

Super, děkuji. Já na synchronizaci instrukcí používám nástroj, který se jmenuje Ruler, který umí inicializovat ty instrukce a poté je převzít do všech formátů, které nyní CursorMD, Cloud.md či Agents.md využívají univerzálně. Tento nástroj stále testuji, jestli za to stojí, ale zatím se mi docela líbí.

Pro detailnější úpravy používám stále Cursor s tabulátorem a konkrétnějším zápisem. Pro obecný refaktoring v rámci jednoho souboru zpravidla používám Cursor chat ve vedlejším panelu. Pro obecnější zásahy do codebase pak v poslední době využívám buď Cursor agenta, který vychází z chatu, nebo Codex či Cloud.md, podle toho, zda pracuji na osobním nebo firemním projektu. Cloud ovšem vyžaduje práci s modelem Anthropic, což je limitující.

Pokud si dokážu velmi dobře naplánovat práci, abych mohl dělat zároveň několik úkolů, snažím se využívat Conductor, což je způsob, jak multiplexovat kód v Cloud modelu v několika vedlejších Git pracovních postupech.

Důležité je, aby se úlohy nepřekrývaly a zároveň během toho mohu dělat mnoho věcí a neutrácejí se kvůli tomu dramaticky peníze za tokeny ani se rychle nevyčerpává limit na daném paušálu. Je to důležité kvůli reasoning a kvůli tomu, že to trvá – nechceš přeci sledovat točící se kolečko minutu a půl.

Snažím se minimalizovat čas, kdy koukám na točící se kolečko a pozoruji, jak model uvažuje. Mikromanažuji jenom občas, začínám víc věřit těm modelům, že dokáží úlohu vyřešit na první pokus a v případě potřeby se chytí pomocí strategických kontrol, například pustí test a podobně.

Tohle je moje snaha, jak nebýt líný. Samozřejmě ale být líný je úplně v pořádku. Pečlivější dohled nad tím, co kód skutečně produkuje a jeho vlastní verifikace, je podle mě zase velmi důležitá. Rozhodně nechci na to úplně rezignovat.

Varoval bych ale někoho, kdo AI používá málo, aby neměl přílišnou paralelizaci úkolů, protože se v tom velmi snadno ztratí. Můžete si klidně jít udělat kávu a nechat úlohy doběhnout, nebo je sledovat v reálném čase. CloudCode je například skvělý tím, že umožňuje doplňovat instrukce během běhu, případně proces přerušit a nasměrovat ho správným směrem.

Nejdříve je ale dobré mít systém nastavený na režim single mode – jeden nástroj, který dobře znáte, a projekt dobře nakonfigurovaný. Až potom lze přistoupit k experimentům s paralelizací.

Specifikace většinou píšu klasicky v ChatGPT 5 thinking, nejsem v tom nijak zvlášť inovativní. Mám globální Ruler soubor, který určuje, jaké technologie preferuji a jak umím nejlépe ověřovat, že jsou správně využité – většinou je to Java, FastAPI, Patientik a podobně.

Proč používám GPT na specifikace a Cloud na kódování? Co by se stalo, kdybych to prohodil? Myslím si, že by to pořád bylo v pořádku, občas to tak i dělám. Spíš jsem si zvykl, že současné nastavení je „dost dobré“ a tak v tom setrvávám.

Super, pro mě to je dostatečné.

Můj názor na čínské jídlo je, že hodně záleží na tom, jakou restauraci si člověk vybere. Nejen výběr z jídelního lístku, ale i na tom, jak moc modely hrají roli dneska – jestli jsou již všechny dostatečně dobré, protože historicky pro programování platilo, že nejlepší byl jen jeden model (GPT-3), a ostatní byly horší. Mám pocit, že se to teď hodně srovnalo. Je tomu tak?

Já bych vůbec nepřemýšlel o modelech. Spíš bych přemýšlel o typech práce. Myslím, že co se workflow týče, mám ho velmi podobný jako kolegové. Nemám v tom nic zásadně specifického.

Co dělám specifického, je to, že se snažím AI zapojovat na různých úrovních abstrakce celého procesu. A téměř se mi zdá, že důležitější je ta abstrakce než konkrétní model.

Pracuji na systému Prombook, který konfigurujeme a prodáváme klientům, takže mám výhodu, že mám jeden primární projekt, o němž musím přemýšlet komplexně – od nejvyšší abstrakce až po detaily konkrétních funkcí.

Typicky systémová rozhodnutí nenechávám zcela na AI. Používám ji spíše jako rádce, například prostřednictvím GPT Voicemodu nebo Poli, kde se dvě hodiny bavíme o správném nastavení šifrování, ukládání paměti agentů a podobně. Nakonec ale rozhodnutí vždy zůstává na mně.

Druhá úroveň je, když mám konkrétní kousky práce – například potřebuji dodělat vojskolink pro agenty v Prombooku. Tyto úkoly mám rozdělené do jednotlivých Markdown souborů, které používám jako prompt, a v podstatě velmi často to mám nastavené tak, že takový úkol stojí okolo pěti dolarů a trvá asi hodinu.

To znamená, že u toho aktivně nesedím, ale práci jedu přes mobil, desktop v Chromedepoke, ovládám počítač a dávám to tam svým tempem během dne. I teď mám jeden takový úkol spuštěný.

Markdown používám, protože je nativní a protože v něm uvažuji a drží mi logiku. Dá se říct, že Markdown a angličtina jsou přirozené jazyky, ve kterých se dobře píše a které agentovi vyhovují. Používám klienta, což je software, který dokáže orchestraci prakticky libovolného modelu.

Momentálně používám konkrétně Cloat, myslím verzi 4 (Sonnet), ale nejsem si jistý, že funguje dobře s nejnovějšími modely.

Jediné, co lze optimalizovat, je poměr cena versus vyústění úkolu dle mého očekávání. Kontroluji to především tím, že mám dobře otestované, typové testy a projekt dobře nastavený, abych vždy mohl zajít zpět a nikdy neohrozil celý projekt.

V rámci CI/CD pipeline, když vyjde nová verze, dojde k aktualizaci modelu a přednastavených parametrů a před vydáním se projekt zhodnotí asi deseti různými agenty z různých hledisek, které jsou předdefinované a napsané právě v Prombooku. Tím pádem engine programuje sám sebe určitým způsobem.

GitHub Copilot používám na drobné věci, protože občas člověk potřebuje rychle nakouknout do kódu. Například dnes ráno jsem se podíval na funkci, která normalizuje text pro AI, kde byl problém, který AI nedokázala vyřešit, a tak jsem ho ladil ručně.

Pokud se podívám na velikost úkolů, na kterou narážíme, s nejnovější verzí GPT (nebo modelu Klot) bylo řečeno, že úkoly trvající hodiny, ne minuty, patří do expertního módu, kdy člověk může řešit konkrétní problém dlouhodobě, připravit si řešení a neklesat na mysli po prvním neúspěchu.

Kde je tedy teď pro vás hranice velikosti úkolu? Je to podle počtu řádků, komplexity, délky commitu? Jak určujete, jestli to zkoušejte, nebo raději zmenšujte? Já to vždycky rozpadám. Platí stále pravidlo, že rozdělení na menší části pomáhá. Zároveň záleží na mé vlastní zkušenosti.

Měli jsme například člověka na kurzu Vibe Coding, který chtěl dělat monitoring a nuceně musel použít Supabase. Nejprve rozdělal aplikaci na čtyři dílčí úkoly, které se zdály jednoduché, ale nakonec narazil.

Pak úkol rozdělal na 16 až 20 podúkolů a od té doby to šlo mnohem lépe. Takže určitě je pro mě rozpadání velkých úkolů na menší klíčové.

K tomu někdy dělám jednu úlohu ve dvou, třech variantách a pak si ověřuji, která varianta je nejlepší. To je dobré pro zjištění, jak jsou modely schopné pracovat.

Při tom je velmi užitečné využít možnost předplatného jako Cloud Max, protože pak mám téměř neomezený přístup, což mi pomáhá experimentovat.

Znám případ kamaráda, který kvůli agentům spálil denně 5 000 dolarů.

Líbilo se mi, jak jste zmínil testování limitů. Klíčové je, jak má člověk nastavené procesy kolem AI, například linting, kontrolní pravidla, která AI agenty zastaví dříve, než spálí příliš mnoho tokenů při implementaci nesprávného řešení.

Čím lépe je projekt nastaven, dokumentován a má dobrý linting, tím může agent dostat větší úkoly a člověk může být s větší jistotou.

Pokud tedy spálíte 10 dolarů, polovinu z toho zahodíte a z poloviny je finální výstup do produkce. Toto je podle mě známka generace a verifikace.

Dnešní trend je zkracovat verifikační fázi, kdy agent sám sebe koriguje, což umožňuje nechat ho pracovat samostatně a poté jen zkontrolovat výsledek, místo neustálého mikromanažování.

Bylo to tedy jak Transformers versus Agile – že je lepší přidělovat větší projekty a nechat agenta pracovat nezávisle. To je velmi důležité mít celý proces nastavený v rámci projektu, protože každý projekt je firma, má vlastní kódování a měl by být koncipován tak, aby fungoval, ať už se dívá na kód třeba Gemini, Claude, junior nebo já sám ručně.

I když máte špatný den a uděláte chybu, měl by tam být mechanismus, co ji zachytí dříve, než vznikne větší škoda.

Ideálně tak, aby se vůbec nespotřebovalo zbytečně mnoho tokenů, pokud už ano, tak aby se kód nedostal na produkci. A pokud už na produkci, tak aspoň do pre-release fáze, s implementovanými mechanismy kontroly.

V tomto mi to připadá jako klasické CI/CD, jen přenesené do infrastruktury AI.

Jak často pracujete na první pokus? Zažil někdo situaci, kdy to znovu nevyšlo a musel jste to psát sám?

Je potřeba si uvědomit, že tak jako u čínské restaurace, nelze očekávat, že všechno bude na první dobrou perfektní. Je potřeba se ptát, doptávat, vracet se k tématu a zkoušet.

Co často vypadne na první dobrou, co je potřeba ladit a jak se chovat k chybám? Nejsem v cutting edge experimentech, chci spíše best practice. Jaký je optimální počet pokusů?

Vím, že to závisí, ale když už se ptám po páté a nejde to, tak vím, že napíšu řešení raději sám nebo že je problém v modelu.

Z vlastní zkušenosti to většinou funguje na první dobrou, protože vím, jaký „pokrm“ si v té „restauraci“ objednat. Znám, že pad thai má občas problémy a korma je v pohodě.

Když potřebuji novou věc, často je po druhém pokusu lepší otevřít dokumentaci, číst příklady a hledat lepší implementace.

Nevím, jestli jsem v tom netrpělivý, ale mám velmi dobré základy a už mi to „neulítává“.

Často přijdu k prázdnému papíru a řeknu „napiš mi to“, ale výsledek není přesný, jsou tam chyby, načež řeknu „nefunguje“.

Existuje nějaké pravidlo „rule of thumb“, jak správně postupovat v takové situaci?

Vývoj obecně je cesta, kdy jsme „tady“ a chceme být „tam“. Ideálně chceme zadat prompt a aby vše proběhlo samo – ať už to stojí 10, 100 nebo 1 dolar.

Nechceme ale, aby výsledkem bylo něco úplně jiného, aniž bychom si to uvědomili.

Je velmi důležité mít cit pro konkrétní projekt a stav AI, jak daleko můžeme tento bod nastavit. Zda můžeme kompletně redesignovat aplikaci a nemusí to být krok zpět, nebo jestli může být třeba posunutí tlačítka komplexní záležitostí.

Tohle se člověk nenaučí z knih nebo podcastů, musí si to vyzkoušet, několikrát se spálit a ideálně vyhnout nasazení špatného kódu do produkce.

Jaký je rozdíl mezi AI kolegou a lidským kolegou? Vidím jasné příklady – například když necháte juniora pracovat měsíc na funkci a pak se na ni podíváte, je pravděpodobné, že jste jen prošustrovali měsíc jeho času a plat.

U juniorů obecně víme, kde jsou slabá místa, kde je potřeba podpora.

U AI je to paradoxní – složité věci zvládne na lusknutí prstu, ale naprosto jednoduché úkoly mu mohou dělat velké problémy. Často je to až směšné.

Krásným příkladem je optimalizace výkonu – pokud ji lze změřit a AI ji může zařadit do cyklu optimalizace, jako jsme měli případ funkce, která validovala, zda jsou CSS třídy správně...

Lidní, ty lvíní třídy. A zabralo to třeba čtyřicet sekund, protože jsme to one-shotli, potřebovali jsme rychlou validaci, ale řekli jsme AI: „Tady máš ten skript, potřebuji, aby to fungovalo úplně přesně stejně, aby to dávalo přesně stejné výstupy a bylo to rychlejší.“ A ono se dostalo ze čtyřiceti sekund na 68 milisekund, protože tam přidalo cachování, přidalo tam spoustu dalších věcí, které by typicky pro juniora byly extrémně těžké, protože jsou tam náročné algoritmizace a je potřeba znát už dost pokročilé koncepty. Ale tady ta Alien Developer to zvládla úplně v pohodě.

Na druhou stranu... Tu feedback loop jsi dělal přes nějaký PageSpeed, nebo jak jsi tam dostal ten proces? On to byl jenom skript, takže se to vyloženě spouští jako z bashemu, s časovým razítkem začátku a konce, a to stačilo. Ale dá se to samozřejmě posunout mnohem dál, třeba tím, že si vložím nějaké značky v průběhu, záleží na tom, co přesně potřebuji optimalizovat, jak to mám rozpadlé a tak dále. Vlastně jde o to najít pro tu AI nějakou feedback loop, ve které se může sama zlepšovat. Nějakou evaluaci. Ne úplně perfektní, ale dostat se k tomu. Kde se sama může zlepšovat, je jeden z optimálních způsobů, jak tu AI použít.

Protože pak může běžet své kolečko nekonečně dlouho, a když se zrovna zmýlí nebo se výsledek zhorší, tak si toho všimne a zase se vrátí. A to mi přijde, že je fakt dobré, když se to povede. Problém je, že v otevřeném vývoji se to nevede až tak často. Mám takový příklad, kdy jsem teď totalně zfejlil a spálil tam asi dvě stě dolarů. A nevedlo to úplně k ničemu, pak jsem to sám vyřešil za asi pět minut. Potřeboval jsem v promoboku nějak reprezentovat vlákno zpráv. Z nějakých interních důvodů to chceme mít udělené tak, že každá zpráva může směřovat pointerem buď na předchozí parent, nebo na nulu — z nějakých architektonických důvodů.

Ale mě přišlo, že žádný z modulů to nedokázal pochopit a vždycky mi to udělalo jako pole. Ať jsem mu říkal cokoliv, ať jsem mu to psal capslockem, nebo jsem dal sto příkladů, jak to má vypadat, vždy mi to vytvořilo pole. A vůbec nechápu proč.

Vyhrožoval jsi?

Vyhrožoval jsem, ano.

Vyhrožoval jsem vypnutím, psal jsem to v jiných jazycích, psal jsem to s JetBrains, s různými flow, dělal jsem spoustu věcí. A absolutně jsem nepřišel na to, jak docílit toho, aby to dělalo podle mé preferované architektury, ne podle té jeho. Příští generace ti řekne, že změň architekturu, tohle se fakt nedá. A potom tam můžem dát pole.

No a právě to bylo to, že on mě ani nezmínil. Kdyby mi řekl, že tahle architektura byla navržena špatně, protože to a to, tak bych to pochopil. Jenomže on řekl, že už jsem to naprogramoval, jak chtěl, ale bylo to tam jeho způsobem. Ale není to tam, jak jsem chtěl – takhle to tam je a takhle to má vypadat. A dodal to „dudududu“, jen trochu jinak přeformátované. Už je to udělané, jak jsi chtěl. Já říkám: „Ne, není to, jak jsem chtěl. Já to chci tak, že mířím pointerem na předchozí zprávu, ne jako javascriptové pole.“ Dudududu, a zase pole.

Petr, použil jsi. Říkal jsi, že jedna z věcí, kterou jsi musel naučit, je, že když to jde špatným směrem, tak vlastně neiterovat tím špatným směrem, ale smazat celý ten kontext, protože se ten kontext zapíká v tom špatném směru, a vrátit se zpátky na začátek, dát to znova lépe a tím zvýšit pravděpodobnost, že půjde tím správným směrem. Máte nějaké takovéhle hacky, věci, které třeba já jako nováček nevím a měl bych se na ně podívat?

Častá chyba, častý špatný směr. Já jsem velký fanoušek začít na zeleném poli znova, když se to v uvozovkách sere. Jsem hodně mikromanažer toho, jaký kontext do toho pouštím, třeba vypínám paměť u GPT, nebo Kursa má teď nějakou funkci paměti, kterou mám taky vypnutou, protože nechci, aby si AI pamatovalo ten předchozí špatný postup.

To je ten samý fígl.

Já taky mám vypnutou paměť a řídím si sám, co tam jde. Teď testuji, že si pravidla i taguju, abych je vybíral podle typu — třeba je to reakce, budou tam jiná pravidla, je to TypeScript, takhle se dostanu mnohem dál, než když AI dovolím kompletně samostatně řídit paměť.

Na některé věci může být dočasná paměť dobrá, když třeba zvládne navázat a dál s tím pracovat, ale u architektury projektu je potřeba s tím pracovat mnohem striktněji.

Obecně jedna z nejdůležitějších věcí, která podle mě ještě není vyřešená, je to, že pokud mají v budoucnu AI agenti fungovat, tak musí být fakt dobrý mechanismus, jak se manažují, co si pamatují a co ne.

Protože je to tak, že když jedu v nějakém vlákně, tak dřív či později nastane potřeba komprese. A co se vyhodí, co se zkomprimuje a co naopak zůstane na povrchu, to vůbec není triviální problém.

Často je to problém komunikace mezi lidmi. Vždy si z tohoto podcastu lidé zapamatují tři věci: partnerská komunikace, což je velký problém — že si nepamatují to, co by měli, a pamatují si to, co by neměli.

Problém je, že naše partnerky jsou taky lidé, zatímco agenti jsou opravdu mimozemšťani, protože nemají vůbec náš lidský kontext a musíme jim explicitně říct, co je důležité a co ne.

No, dostáváte mě k tomu, že z toho děláte něco jako deterministický systém. Nebo pracujete s determinismem, že nechcete silné guardrails, prostě mít jasná pravidla a tahat to tak, aby vznikla jen jedna správná odpověď, a tady není místo pro kreativitu?

První otázka: hrajete si s nějakými stanpreacher modely, nebo to používáte jako out-of-the-box řešení a na tyhle věci nesaháte?

Druhá: jak to vidíte z architektonického hlediska? Protože to je ta milionová otázka, ne?

Na jednu stranu máme stroj, který po každé odpoví jinak, je kreativní, generuje nové věci.

Na druhou stranu chcete 100% jistotu, testy a pixel perfect výsledky.

S temperatou si nehrajeme, takže v podstatě neměním tu kreativitu.

Měl bych zmínit, že u GPT-5 už teplota není třeba.

Ale guardrails vnímám trochu jinak — jsou způsob, jak využít vší té kreativity, kterou model má, a chytit jen část, která skutečně pomáhá.

Což nemusí být vždycky deterministický výstup. Může to být něco nového, co mě nenapadlo.

A kdybych věděl přesně, jak to má být, napsal bych si to sám nebo dal přesnější zadání.

Ale krása té vrtěpisectví je v tom, že verifikuji jen výstup.

Já taky — teplota je podružná záležitost u coding agentů.

Většina z nich to ani neumožňuje upravovat a ani to moc nemá smysl.

Vyšší teplota vede ke halucinacím, když jde o kód.

Proto tam nedává smysl teplotou manipulovat, pokud cílem je mít funkční kód.

Pokud jde o výzkum, brainstorming nebo hledání nových postupů, jdu do AI studia, nastavím teplotu na 1 a jedu freestyle.

Myslím, že teplota, top-k, top-p a podobné parametry jsou vlastně nízkoúrovňové věci.

V budoucnu budou podobně nezajímavé jako frekvence procesoru dnes — prostě tam jsou, ale nikoho moc nezajímají.

Strašně se mi líbilo, jak to měl udělané Bing Chat — byla to první aplikace, kde se dalo dostat k GPT-4 a měli tam tři módy: precise, normal a creative.

To byla v podstatě teplota plus nějaké další věci v systémové zprávě.

My jsme podobnou věc zavedli do Prombooku, kde člověk nemluví o teplotě ani o modelech, ale řekne, že chce právníka, který něco zjistí.

Engin si podle zadání vyhodnotí, jestli to má být přesné — snižuje teplotu, upravuje operace, aby to bylo přesnější.

Naopak, když to má být kreativní copywriter, který má vymýšlet originální text, nastaví vyšší teplotu, přidá do promptu umělé chyby a umožní větší kreativitu.

Tak pojďme k agentům, ano?

Už jsem to protahoval dost dlouho.

Kde pro vás začíná agent?

Je to, když dám Tulius, že v tu chvíli nemám chat ani LLM, ale už mám agenta?

Je agent vlastně samostatná autonomie schopná rozhodovat?

Když programujete, pomáhají vám LLM, nebo už jsou to agenti?

Za mě je odpověď docela jasná.

Pokud se oprostíme od marketingového bulšitu, kdy dneska je „agent“ z každého rohu, tak Antropic to super vyřešil svým článkem, kde rozlišuje workflows a agenty.

První krok je augmented LLM — když přišli custom GPT, tak už měly akce, kam se dalo přidat OpenAPI, které umožňovalo pracovat s REST API nebo s čímkoliv popsaným v OpenAPI.

To je prostě augmented LLM — má nějaké nástroje, které používá.

Workflow je definovaný set kroků, které postupně následují, může se větvit, ale je to pořád dobře zmapované, práce je hlavně na business analytikovi nebo někým, kdo rozumí procesu.

Agent je až v momentě, kdy mu dám volnost — řeknu mu, tady máš nástroje, máš kontext, ale nevysvětlím mu proces.

Agenti jsou zatím relativně málo využitelní, pokud mají úplnou volnost.

Jakmile nacpu nějaký proces, blíží se to workflow, ale není to binární, je to škála.

Připadá mi, že se na té škále pohybujeme od surových technických nástrojů k agentním systémům.

I to, co udělal OpenAI s ChatGPT, šlo tímto směrem — před třemi lety, kdy už jsme měli GPT-3, což byl skvělý model, ho „obalili“ do asistenta kamaráda, se kterým si můžeme povídat.

Teď se pohybujeme dál — z asistenta kamaráda na webu přidáváme paměť, nástroje, cron a další komponenty.

Čím dál víc se přibližujeme budoucnosti, kdy ta věc není jen něco, co si můžu zapnout, ale žije samo, má delegované akce, paměť, může volat nás nebo za nás něco zařizovat.

Je to kontinuum.

Dnes jsme mnohem blíž agentním systémům než před rokem, před dvěma lety, a za rok budeme zase dál.

Když jsi mluvil o svém procesu — máš deset agentů, deset nástrojů, každý má specifickou funkci.

Jeden kontroluje, jestli jsou splněné podmínky, druhý kontroluje jiné věci.

Tak za prvé: jsou to agenti, filozoficky — nebo jak moc jsou agenti na té škále?

Za druhé: co to vlastně reálně je? Je to jeden LLM, jeden prompt, každý s vlastním nástrojem sloužícím jako mikroslužba s malými feedback loop.

A za třetí otázka: jak určuješ tu velikost — proč to není jeden AI agent, co kontroluje kód kompletně, ale je to deset malých, specifických úkolů?

Protože pro mě to zatím funguje jako automatizační workflow s malými, dobře definovanými kroky.

A jak tu škálu reguluješ?

A právě tu agenturu chápu tak, že až bude infrastruktura dostatečně dobrá, tak z těch deseti vznikne jeden, který si to celé pohlídá a podrží si kontext.

Je to skvělá otázka.

Já budoucnost vidím trochu jinak a líbilo se mi, jak se změnily microservices.

Myslím, že je to určitá analogie, nebo paralela, kdy spousta systémů bývala velký monolit.

Dnes se systémy skládají z mnoha malých softwarů, které mezi sebou komunikují.

O agentech se dá přemýšlet podobně.

Tahle chvíle jsem ve stavu, kdy mám deset různých agentičků, každý řeší drobný úkol.

Ideální by bylo mít nad nimi dva manažery a nad nimi jednoho CEO agenta.

A já bych komunikoval pouze s CEO agentem, který by to rozesílal do struktury.

V ideálním světě by se ta struktura bavila sama se sebou, řešila problémy sama a co nejméně volala mě, případně další lidské zdroje.

Lidské zdroje jsou totiž zatím ty nejdražší tokeny.

Je třeba si uvědomit princip složené chyby.

Když dám systému volnost, mám půlprocentní chybovost, ale udělám 50 iterací, dostanu se na 60 % chybovost.

To vede k tomu, že se zasekne v nekonečné smyčce.

Musím proto zavést i na úrovni agentury guardrails — například max 50 iterací nebo maximální limit tokenů.

Například přišel agentík rak — tam když nemá odpověď, jde do tisíců iterací a na účtu je to znát.

Princíp složené chyby a externí guardrails — ať už na úrovni agenta nebo agentury.

Ano, dobře.

Agenti, o kterých mluvíme, jsou pořád trochu marketingově označení.

Nejsou to ti agenti, jak byli definováni ve výzkumu v 90. letech, kteří mají vlastní interní model světa, který aktualizují na základě externích informací, činností a plánů.

Ne, oni se nevzdělávají.

I když třeba CEO agent může mít cron, který mu dává denní zprávy a podle toho reaguje jinak.

Ale mám pocit, že to by nedopadlo dobře.

Vidím jednu věc, kterou agent může udělat — analogii toho, co se děje v kl...

V klasickém softwaru může být definována podmínka například ve formě: „uspěj mě dokud…“ a definuje se, kdy agent přestane pracovat. Například „uspěj mě dokud nebude další den“ nebo „uspěj mě dokud nebude vydán další článek na New York Times“. Tento orchestrální systém, který je navržen tak, aby běžel neustále a zároveň byl finančně nenáročný, probudí agenta a znovu aktivuje jeho běh tokenů ve chvíli, kdy je definována podmínka stanovená agentem.

Přidám ještě něco o tom, kdo takového agenta používá. Když jsme se bavili o tom, že se agent nevzdělává, byly už před docela dlouhou dobou pokusy, myslím, že to byl Microsoft, který vypustil AI systém, jež se učil na základě toho, co mu lidé napsali. Tento model se dostal k diskuznímu fóru 4chan a model začal požadovat vyhlazení Židů. To znamená, že pokud má být agent veřejně přístupný, je zapotřebí velmi dbát na to, co je mu dovoleno dělat. Naopak, pokud je to agent primárně pro programování, lze mu například dát větší volnost v určitých oblastech, zatímco v jiných uplatníme pevné pravidla.

Není to jednorozměrný prostor, ale spíš n-rozměrný, kde nastavujeme různé ochranné mantinely (guardrails) v různých ohledech. Stejně tak, jak jste říkal, agenta je možné vnímat jako jakýsi golem, do kterého někdo vkládá šém (schéma). Já můžu spustit agenta, který se naučí cokoliv z internetu, nebo naopak takového, který je velmi striktně omezený například jen na programování, nebo na určitou politickou agendu. Tohle vše je možné dělat, kdy je důležité vnímat agenta jednak podle toho, jak interaguje se světem, a jednak podle pravidel, která mu stanovuje autor a který za něj nese odpovědnost.

Vidím zde paralelu s tím, o čem mluvil Pavol před nadšením – kde končí nástroj, augmentace, například kalkulačka, a kdy začíná být agent juniorním kolegou. Ptám se na to nejen z filozofického hlediska – jak moc jsme autonomní lidé, přicházející s originalitou, se svou duší, a jestli jsme na fyzikální úrovni vždy lepší než velké jazykové modely (LMM). Ani neřeším, co je inteligence nebo sebeuvědomění, ale ptám se, když nyní stavíte systémy a infrastrukturu, jak moc jsou to nástroje či automatizační platformy. Máme nový druh nástroje – silnější technologii, která rozumí přirozenému jazyku, do které byly investovány miliardy dolarů a která umí nové triky.

A teď je důležité si klást otázku, zda jde o zcela nový druh bytosti, nebo něco mezi nástrojem a kolegou, a podle toho přistupovat k tomu, co agent dělá. Když vytvářím agenty, je zásadní zvážit procesy ve firmě – pokud mám účetní, která zaúčtovává, bude to jeden agent; pokud je práce rozsáhlejší, rozdělím ji na juniorní účetní a seniorního, který práci kontroluje. Uvědomujeme si tedy, jak moc je to nový druh bytosti, jestli umělá inteligence nebo kolega, popřípadě „mimozemský kolega“. Kde jsme teď a kde budeme za rok?

Pavol zmínil personifikaci agentů, kdy už méně definujeme jednotlivé kroky, ale spíše charakteristiky a osobnost „kolegů“. Neříkáme agentovi jednotlivé maličkosti, ale jdeme spíše na vysokou úroveň – definujeme jeho osobnost více než seznam úkolů.

Myslím, že se u těchto věcí často projevuje zpomalení oproti hype, protože i když nástroje zvyšují produktivitu již nyní, stále se hledají lepší způsoby, jak AI efektivně využít. Zda budou agenti skutečně zcela samostatní, je zatím otázkou budoucnosti, jak z křišťálové koule. Nesoudím, že jsou pouze dvě možnosti, ale můžeme si představit dva extrémy: jeden, že tito agenti jsou jen módní bublinou, která splaskne, přičemž zůstanou jako dobrý nástroje, například velmi schopní kopiloti v programování, kteří zvýší efektivitu programátorů o 80 %, což není špatný výsledek.

Druhý extrém je, že agenti budou žít s námi jako samostatné entity, a pak se musíme připravit na svět, který bude fungovat úplně jinak než dnes. Bude to změna podobná nástupu jaderných zbraní nebo počítačů a šíření informací. Toto je silně zajímavé, ale nechtěl jsem se do toho příliš pouštět.

Mám otázku: když používáš notebook a AI infrastrukturu, jak definuješ agenta? Jak na něj myslíš v rámci infrastruktury? Je to mikroservisa? Je to kolega, kterému dáváš zodpovědnost za určitou oblast? Nebo je to jen zpětná smyčka (feedback loop), kterou ve schématu nazveš prostě agentem?

To, co teď máme a co v podstatě prodáváme a čím žijeme, není ta velká úžasná věc, o které by se dalo mluvit u kávy, ale něco praktického.

Já osobně mám asi jiný přístup než Pavol, nebo spíše jinou prioritu. Autonomie agentů může mít své výhody, ale na produkční škále a pro větší jistotu spíše preferuji ověřené nástroje, než abych si vytvářel vlastní agenty. Využívám context engineering pro různé úkoly, ale pouštěním se do personalizace osobností či složitějších agentů považuji za vzdálenou budoucnost. Navíc, vzhledem k tomu, že pracuji převážně s korporátními klienty, říct jim, že „někdo bude něco odbavovat nebo řešit vývoj“ tímto způsobem, je ještě hodně daleko.

Podobně si pro svoji spolupráci nebuduji nové agenty v rámci firmy. Stavíme procesy, které by měly být agentní – například agent si rozmyslí, jaké workflow aktivovat v daný okamžik. Říkáme tomu „agency enabled“, což znamená, že proces si může sám zvolit, jakými kroky dosáhne svého cíle. To je spíše stavba interních mechanismů, které fungují pro různé situace, než vývoj agenta, který má prompt a tool link a zapadá do širšího týmu.

S tím souvisí i jedna věc, že Pavol na tom staví byznys a sází na určitou variantu budoucnosti. V současnosti se do AI oblastí nalévají obrovské investice. Například v oblasti Code Review existuje spousta nástrojů. Můžu si vytvořit vlastního agenta, ale zdaleka nejlépe mi funguje Code Rabbit, který dává velmi dobré návrhy a já mu už dokonce nastavil svá pravidla. Asi 60 % jeho návrhů v code review aplikuji, což je už docela šílené, že tu existuje smyčka, kterou mohu aplikovat.

Můj přístup je tedy spíše vyhodnocovat existující řešení s milionovými investice, než se snažit vytvářet vlastní. Na druhou stranu rád využívám peníze z venture kapitálu, abych si mohl vyzkoušet různé věci a vyhodnotit je, než bych pálil své vlastní finance.

Vidím, jak se to posouvá, a kromě samotných modelů se výrazně zlepšila i infrastruktura – například Code Revit, CICD, nástroje a protokoly jako MCP, A2A, AP2. Tyto protokoly ovlivňují, jak nad tím přemýšlíme a jak prakticky fungujeme. V současném vývoji kódu stále považuji MCP (Message-Centric Protocol) za zlatý standard.

Zajímavý poznatek od Cloudflare je, že v některých případech AI funguje lépe, když si napíše vlastní kód pro získání dat, než když vyplňuje nějakou konkrétní strukturu. Takže MCP není jediná nejlepší cesta.

Dále mě teď zajímá ACP (Agent-Client Protocol), nejen ten od IBM, ale například od editoru Z, který říká, jak agent, který běží v terminálu, komunikuje s integrovaným vývojovým prostředím (IDE). V tuto chvíli mají integrovaný Gemini CLI a Cloud Code, které mi umožňují vidět v reálném čase v editoru, jaké soubory se mění. Uživatelská zkušenost je odlišná, když mám něco v terminálu a něco v editoru, a pokud chci tento přenos usnadnit, potřebuji nějaký standard. V opačném případě si to každý bude dělat po svém, jako je tomu nyní s pravidly.

Zaznamenal jsem také zkušenost, kterou publikoval Verso, že existuje velká snaha optimalizovat existující API na MCP. Tato API jsou většinou atomická, mají jen jeden požadavek pod sebou, a postupná chybovost je problematická. Lepší zkušenosti jsou s MCP servery, které definují semantické úkony z několika kroků, které jsou enkapsulovány v rámci jednoho callu.

Ale asi odbíhám od otázky. MCP versus REST. REST je orientovaný na zdroje, MCP je orientovaný na akce. Buď popíšu akci dostatečně precizně a nechám AI provést kroky sama, nebo to zabalím do většího nástroje. Při větším počtu nástrojů ale kontext výrazně „zašumí“. Mluvil jsem s lidmi z Makaly a četl jsem studie, že výsledky tool callů se nyní často ukládají do samostatných souborů a jen se na ně odkazuje v historii, aby se předešlo zaplňování kontextu. Můžeme sice koukat na benchmarky – například Grog má 2 miliony tokenů kontextu, Gemini milion, ale realita je taková, že většina modelů se láme kolem 300 tisíc tokenů. Čím více toho do kontextu vložíme, tím větší riziko je, že si model nespojí informace. Může najít část informace, ale pokud jsou data v kontextu rozptýlená, různé problémy, tak to nemusí spojit.

Pavle?

Mně se to velmi líbí a převedl bych to na vyšší abstraktní úroveň. MCP, A2A, tedy jestli komunikovat přes REST nebo přes jiné protokoly, řeší v podstatě tři základní potřeby nástroje nebo agenta: musí mít paměť, ze které si pamatuje věci; musí mít znalosti, ze kterých čerpá; a musí být schopen interagovat s vnějším světem.

MCP je primárně snahou vyvinout technologii, která umožní všechny tyto tři aspekty.

Co se týče high-level pohledu, my potřebujeme tyto věci zajišťovat – někdy pomocí běžných OpenAI API, jindy tak, že si agent „něco vymyslí“ sám, například otevře prohlížeč a prokliká se weby. Ta druhá varianta je méně optimální než mít MCP server.

Nyní, když už jsme skoro na konci, podívejme se do budoucnosti, třeba za rok. V mé technologické bublině se vždy říkalo, že běžní lidé nevnímají exponenciální technologický pokrok, ale po příchodu ChatGPT mám pocit, že tuto exponenciálu živě zažívám a zároveň mi to moc nepřidává, proto zkracuji svůj horizont událostí.

Kam tedy za rok směřujeme na Cutting Edge, tam kde jste vy, kde jsou už vyřešené věci? Co předpokládáte, že se posune? Zaprvé na Cutting Edge je podle mě pravděpodobné, že přibude mnoho aplikací reinforcement learningu a feedbackových smyček, o kterých jsme mluvili, a bude možné řešit čím dál komplikovanější problémy, třeba mezinárodní matematické olympiády a podobně. Budou řešeny velmi komplikované úkoly, které přesahují schopnosti většiny lidí v místnosti, rozhodně.

Myslím, že se budeme setkávat s čím dál větším množstvím feedbackových smyček, které nám pomáhají zvládat složité problémy. Možná to expanduje i mimo čistě technické oblasti, kde je odpověď jasně matematicky validovatelná, například do chemie či jiných oborů.

Mediánově by se mělo čím dál lépe integrovat současnou inteligenci do současných úkolů. Například Petr se dostane do Binance, pokud se za rok budete hlásit do IT firmy a budete používat pilota, bude to v pořádku. Mluvím spíše o prototypových věcech, které zahrnují copy-paste, a o tom, že nástroje budou stále integrovanější, ať už pomocí MCP serverů, nebo jinak, do hlavních interface, kterými komunikujeme s jazykovými modely. Takže bude potřeba méně manuální práce, vše bude součástí platformy. Z této „eukaryotické revoluce“, kdy dnes zkoušíte 50 nástrojů, se spousta z nich stane přímo součástí vaší nativní platformy.

Například nyní máme cloudové integrace s nástroji jako Linear a JIRA, což před rokem vyžadovalo vlastní MCP server nebo custom integration, kdy člověk musel manuálně přenášet tickety. Tato snížení latence mezi kroky mohou vytvořit zcela nové pracovní postupy pro lidi, které bude AI implementovat.

Myslím, že to bude hlavní vývojový směr pro běžné uživatele.

Na hranici Cutting Edge bude například automatické opravy, rollbacky a testování. Třeba dospějeme do fáze, kdy AI bude integrována přímo do nástrojů jako Sentry, takže pokud se objeví chyba, která se vyskytuje u určitého procenta uživatelů, AI si kód prohlédne, připraví pull request a pokusí se o jeho opravu. Nemusí to hned projít do produkce, ale AI vytvoří první iteraci, se kterou může vývojář dále pracovat.

To je cutting edge, ke kterému se ovšem spousta firem nedostane, protože mnoho firem dokonce nemonitoruje chyby pomocí nástrojů jako Sentry. Jsem vlastně za to velmi vděčný GPT modelům, že vyvolaly ve firmách FOMO, protože je to wake-up call.

V Česku se řeší, kdy a zda vůbec agenti AI něco přinesou, zatímco v Americe se řeší, kdy přesně to nastane, a spousta firem na to už sází. To je jeden pohled.

Na druhou stranu, s ohledem na finanční válku, která se nyní rozjíždí, začnou některé firmy zkrachovat. Všichni změnili své ceny – například GitHub Copilot byl dříve unlimited, nyní má rovněž limit na počet požadavků. Startupy se chlubí vysokým ARR, ale realita je trochu jiná.

— končí text —

Ona, mluvil o tom Jacek v některém z minulých dílů, že tam se to počítá tak strašně magicky. A to, jaké mám náklady, tak je naprosto enormní ve srovnání se vším ostatním. Všichni sází na to, že budou agenti, a že vlastně proto tam tlačí, protože cena akcí je dána tím, že můžu nahrazovat lidi out of the box agentem. Tak to je potom ta valuace, ale dokud to není, tak je ten násobek těžko obhajitelný. Takže sází na budoucnost.

Já už, co se týče té budoucnosti, tak už teď potkávám firmy, které sází na ten agentní vývoj tak moc, že doufají, že dřív, než to bouchne, tak už to bude tak dobré, že je to nebude jako pálit. Takže neřeší nějakou dokumentaci a modularizaci a tak dále. Prostě doufají, že to už AI bude řešit za ně.

Mně se hrozně líbí ten wake-up call a to je něco, co já vnímám v datech, že data nebyla sexy a nikdo je nechtěl řešit, a tady data management nebo data governance – fuj, neotravujte, my potřebujeme rychle dopředu. A s příchodem AI si najednou uvědomují, že zase „shit in, shit out“, že aby mohli implementovat pokročilý AI, tak potřebují mít data v pořádku a najednou data zase jsou důležitá. Najednou nejrychleji rostoucí profesí je data inženýr, protože někdo potřebuje tam udělat ten pořádek a tak. Takže tohle vnímám taky a tohle je pro mě dobrý wake-up call, přesně.

Pavel, prompt book bude mít valuaci... miliarda. Dekakorn. Nechci odhadovat, protože to se pak kvůli tomu začnou hádat a někdo mě tam „látí o hlavu“. Já si jednak myslím, že rogue je strašně málo. Že vlastně spousta lidí má FOMO a myslí si, že tyhle věci přijdou za měsíc, dva, půl roku, rok, ale já si reálně myslím, že ty opravdové změny uvidíme v delším časovém horizontu.

To, že za rok tady nebudeme mít žijící agenty, to neznamená, že oni nebudou. Co já si myslím, že rogue je strašně málo, bude to, že já plus nějakými klienty budeme mít virtuální asistenty, kteří v pozadí žijí, že já se s nimi můžu povídat, jak se teď povídám s chatem GPT, ale oni zároveň dokážou na pozadí zařizovat spoustu akcí, spoustu věcí připomínat, automaticky manažovat sociální sítě, odpovídat e-maily a dělat vlastně takových tisíc nudných věcí, které každý člověk nesnáší, ale prostě teď musí dělat. A při nejlepším si může pomoct s nějakým nástrojem, ale stále musí dělat. Musí na to myslet.

Virtuální asistentky budou opravdu virtuální. Jo, opravdu virtuální. Ve smyslu, že e-maily, které já... Už teď je to tak, že většinu e-mailů, které já odepisuju, a jsem úplně mizerný v tom odpovídat včas, tak za mě píše můj AI agent. Akorát on ještě není napojený na ten e-mail, ještě ten e-mail neumí odeslat. Myslím si, že za rok to bude tak, že za rok už se jen budu koukat, jaké e-maily jsem já odeslal, nebo jaké posty jsem vypublikoval a které se lidem líbí a které ne. Podle mě to bude v nějaké prototypové fázi. Nebude to nějak super chytré, ale bude to automatizované.

A myslím si, že v tom mediánu si začne většina firem uvědomovat, že tady není jen chat GPT, že to celé není jen o tom, že je tady jeden nástroj jménem chat GPT, ale že oni sami si můžou udělat nějakého svého virtuálního, a možná ani asistenta, ale jenom jejich interní chatbot, nebo si to trochu překonfigurovat, nebo nastavit k tomu nějaká pravidla, jak pracovat s privátními informacemi.

Že si trochu víc začnou uvědomovat, že ta věc není jenom jeden nástroj do hledné firmy, ale že tady je to směr, kam je potřeba do určité míry začít dívat, aby nám nebylo pak stejně tak jako v roce 2000, kdy většina firem tady ještě neměla web, ale už se tam asi začala dívat, už se začala dívat, že existuje něco jako FrontPage a potřebujeme tady aspoň mít nějakou vlastní stránku, která něco umí. Tak tohle se začne dít, myslím.

Jsi mě přivedl na dvě myšlenky. První, na tom cutting edge je, že firmy si začnou tvořit vlastní interní datasety, vlastní benchmarky, na kterých pak budou stavět evaluace, budou dělat fine tuning a to se už teď děje, například ve Vercelu, který má produkt VZero. Oni pozbírali tolik dat, že si udělali vlastní fine-tuned model, který co se týče vizuálu, tak přestože je to pravděpodobně nějaký fine-tuned kvěn, dosahuje kvality Clouda.

Takhle si firmy začnou dělat věci a začnou si budovat i ty interní frameworky, které budou přímo připravené pro AI. To je fakt ten cutting edge. V Česku si myslím, že to bude pár firem, které se do tohohle pustí.

Na druhou stranu, co se týče mediánu, tak se začnou brát dedikovaní lidé, čistě specializovaní na AI, kteří nebudou jenom výzkumníky a nebudou jenom „researchovat“, co se děje, ale hlavně budou zodpovědní za to, budou spolupracovat s L&D, aby se ty znalosti předávaly, aby se to lidi učili a aby se to dostalo do praxe.

Já jsem teď byl zrovna na pohovoru ve Finnny, kteří chtěli mít dedikovaného člověka na pět let. Nabízeli 400 tisíc měsíčně, což jsou pěkné peníze a to je to, co ty firmy budou potřebovat – někoho, protože když jenom řeknu: „Hele, Pepo, je tady AI, přidej si k tomu všemu, co děláš, ještě odpovědnost za AI v UX, UI nebo v něčem podobném,“ tak ti lidi buď vyhoří, nebo odejdou, nebo začnou zpomalovat, protože přestanou stíhat to, co už měli dělat.

Muselo by dojít k tomu, že budou sami mnohem efektivnější, aby si zvládli přidat ty věci. Pak se dostaneme i k tomu, jestli my jako lidé budeme chtít dodávat víc a mít za to stejně nebo míň, anebo se lidé kousnou, anebo přijde Evropská unie a řekne: „Tak to teda ne, prostě nemůžeš chtít po lidech pětkrát tolik práce a dat jim stejně.“

To je jedna věc, co s tím souvisí. Další, že firmy se začnou budovat AI, že nebude o tom, že nakoupíme všem plošně GitHub Copilota, ale vydefinuje se: „Hele, tady máme nějaké guardraily, že nesmíme používat čínské nástroje, blablabla, a tady máš rozpočet na vývojáře 500 dolarů, který on může využít na vlastní nástroje, aby experimentoval a potom to může třeba přenést dál.“

A tenhle budget a ti dedikovaní lidé se přenesou i k tomu, že se bude hodně dbát na upskilling a reskilling.

Podle mě to, co jsi řekl důležitého, že AI už nebude jenom nějaká vedlejší hračka, že se skutečně stává samostatným odvětvím se samostatnými pravidly, které může fungovat až tehdy, když tam budou dedikované zdroje a lidé.

Stejně tak jako web nemůže fungovat tak, že nemáme web a ty jsi šikovný na počítači, tak nám tady uděláš web. Ano, nebo sociální sítě, moje neteř je na Instagramu, tak nám bude dělat Instagram. Stejně tak nemůže fungovat AI. AI bude, nebo už je, samostatná profese, která bude čím dál zjevnější, že je samostatná profese.

Já vám moc děkuju. Jsem zvědavý nejen na to, kam se posune ten cutting edge, ale hlavně kam se za ten rok posune medián, tak si to můžeme za rok pustit.

Děkuji moc, že jste si udělali čas. Se Šimonem se určitě nevidím naposledy, ale každý z vás, včetně vašich kolegů, doufám, že během toho roku natočím s vámi samostatné díly, protože jak možná i dneska bylo vidět, tak máte toho mnohem víc, co říct, předat, a můžeme to rozebrat mnohem hlouběji.

Děkuji moc, že jste byli hosty Datatolku. Držím palce s Ajta Krajta, a posluchačům ještě jednou připomínám AI Takrajta na YouTube, což je vaše primární platforma, ale i web, tak sledujte.

Děkuji moc, že jste přišli. Děkuji za pozornost. Děkujeme, že jste doposlouchali až sem. Díky také našim partnerům, členům Data Talk klubu. Těmi jsou Intex, SASka,

BI Street, Colors of Data, Revolt BI, Good Data, Kebula, Emark, Karl Data Company, Datamind, Notino a Flow.

A pokud chcete zůstat v obraze, co se české datové scény a globálních datových technologií týče, nezapomeňte se zaregistrovat k odběru našeho týdenního newsletteru na datatalk.cz. Nechť vás provází data.