90 % kódu, který napíšu, je vygenerovaný AI.

Jindřich: bude vznikat obrovské množství kódu, kterým postupem času nebudou ty vývojáři, který to tvořil rozumět a bude tomu rozumět jenom ten AI agent, až by to mohlo vyústit v tom, že nikdo tomu kódu vlastně nebude rozumět.

Filip: 90% kódu, které ji napíšu, tak je jako vygenerovaný AI.

Jindřich: To nejkrásnější, co jsem to minimálně považuje, je to, že si s tím, s tou Code Daisy, může povídat jako les kdo. Přesně, ty jsi to prakticky zmínil. A jako ne technický člověk, tak se může doptat na to.

Filip: Jsi jako jeden prompt od toho, aby to AIčko udělalo za tebe, takže jako ta generace juniorů si myslím, že jako nebude tak dobrými programátory.

Jindřich: Právě posloucháte DeepLink Show. Filipe, vítej u další epizody podcastu DeepLink Show, vítáme i naše posluchače. Dneska tady máme takový trošku obzvláštěný koncept. V jednom dost podobném ražení nás čekají nasledující dvě epizody, respektive včetně dnešní, a povíme si, jak být lepší díky AI. Dnešní epizodu zeměřujeme primárně na tebe, jakožto na tvoji profesi, na vývojáře, jak být lepší vývojář díky AI. A tu nasledující epizodu zeměříme na mě, na mojej profesi, jak být lepší produkták díky AI. Představíme si konkrétní use cases a konkrétní naše hands-on zkušenosti, tak jak AI používáme, jaký nástroje používáme a obecně půjdeme možná trošku i do většího detailu než ovykle. Filipe, ready? Co jsi si pro mě připravil?

Filip: Tady. Čau, Jindro. Zdravím taky naše posluchače a diváky. Já jsem si připravil takový průřez, řekněme, nějakým mým přístupem, jak já přistupuju k vývoji pomocí AI a jak si myslím, že když posluchači nebo kdokoliv zapojí tady ty věci, tak je to posune v nějaké efektivitě a kvalitě toho, co jsou schopný tvořit. Já se to budu snažit podávat I jako víc obecně, takže pokud nejste jako programátoři, tak se nemusíte bát, budu se to snažit vysvětlovat, ale jsem tam, jako zmíním nějaký technický termín, tak se toho neděste a určitě se to dá aplikovat i pro třeba lidi, kteří dělají Vibe coding, protože já si myslím, že Vibe coding se bude dál a dál jako rozvíjet a bude možný s ním dělat nějaké jako složitější řešení. Pojďme na to. Když jsme začínali s AI ve vývoji, tak to bylo od toho samého momentu, kdy přišlo ChatGPT. A to byl klasický přístup, kdy jsi měl nějaký problém a dřív jako vývojář si ten problém vzal, hodil si ho do Google a podíval ses na takovou webovku Stack Overflow, která byla populární a tam si programátoři ladili navzájem. Přišlo čet GPT a teď jako všichni, že jo, jsme lidi, jsme jako líní stvoření, když to tak řeknu, tak prostě vezmeš ten samej dotaz a jenom to hodíš do čet GPT. No a ono ti bylo schopné, když už mělo to prohledávání internetu, tak vlastně jako dát tu odpověď. No a tohleto byla tak jako první velká změna v tom vývoji, kdy najednou už si jako programátoři neradili tolik spolu na forech, ale začali kopírovat ty věci z GPT. No a dneska už jsme jako daleko za tady tím. Máme tzv. programovací agenty. Já konkrétně používám Claude Code, ale… může kdokoliv použít jako Cursor, antigravity, kodex, těchto nástrojů je celá řada. Ale ten základní rozdíl oproti tomu, že máš četovacího asistenta, tak spočívá v tom, že je to agent. To znamená, ježí u tebe na počítači, samozřejmě volá ty jazykový modely přes nějaký API, to znamená, že používá ty služby normálně třeba od Anthropicu nebo OpenAI, nicméně ty úkoly umí provádět u tebe, umí modifikovat soubory v tom projektu, umí si do nich šahat čistě a přistupat i k dalším datům. A tohle je teď taková největší změna, která spousta programátorů zažívá. Já si trofnu tvrdě, že žiju v určité bublině, kde mám pocit, že všichni tohle už dělají. Všichni mají programovací AI agenty. Ale ta realita mě někdy překvapí, že spousta programátorů zůstává třeba u GPT a jenom se vlastně raději a kopírují tady ty věci. Já nevím, jak to třeba ty vnímáš u sebe z praxe, ale fakt jako mám pocit, že jako žiju v určité uzavřené bublině, kde jako se dělá ten agentic engineering, se tomu teďka říká, ale jakože spousta lidí pořád jede ještě tím jako původním způsobem.

Jindřich: Mimochodem, jak jsi na začátku říkal, že tak dává se všichni býváři používali ten stackoverflow, tak to přesně jako data potvrzujou takový ten jako přirozený switch z toho stackoverflow právě na ty chatovací asistenty. obecně, když to pro nás čistě jako to usage, tak tak jako brutálně klesáme i o tomhle tom vlastně jsme se bavili v jednom z našich předchozích dílů a koukali jsme společně na ten krav, kde viděte, jak tam padá ta usage právě stackoverflow od té doby, kdy bylo komerčně releasnutý gbt. No ale na co vlastně jsem se tě chtěl zeptat, ty se změňovaly ty různý nástroje, týkající se přímo toho agentek vývoje, jaký máš důvody a proč jsi vybral zrovna Claude Code?

Filip: Těch důvodů je několik, jako takový ten primární a to není jako důvod jenom pro Claude Code, ale spíš jako Ten přístup je ten, že Claude Code běží v terminálu. To znamená, že ty nejseš vázanej na nějaké konkrétní vývojové prostředí. Ty seš schopnej ten Claude Code dostat prakticky kamkoliv chceš a nemusí se omezovat jenom na svůj počítač, ale můžeš ho nasadit i na server nebo do CI, CD, pipelines a dalších věcí. Zkrátka, nejseš vázanej na to uživatelské rozhraní, které ti třeba Antigravity, Cursor a tak nabízejí. A proč zrovna Claude Code a ne třeba Open Code, což je vlastně open source alternativa Claude Code, oni se jako netají tím, že se hodně inspirovali, tak je to primárně kvůli tomu, že Anthropic má za mě zatím jako jedny z nejlepších modelů na to agencický programování. Je tady ještě Codex, který je jako velice dobrý, ale čistě nějaký můj jako subjektivní pocit, tak mám rád ty modely Anthropicu. A já jsem dřív používal i Open Code, ale pak přišel Anthropic a řekl, že to není úplně v pořádku a že si nemůžeš přihlásit subscription do nějakého jiného nástroje třetí strany a zatím mi přišly ty jejich limity jako nejštědřejší.

Jindřich: Performance si porovnával právě třeba s Codexem nebo třeba s jinýma modelema, nebo třeba s Antigravity, což je zase od Google, takže to půjde jako Gemini. Čeho já se vlastně aktuálně snažím docílit je to, jestli máš to konkrétní srovnání a jestli opravdu se rozhodl právě na základě těch výstupů v Rockwell Code.

Filip: Já jsem nějaký takovýhle srovnání dělal, nevím, tři měsíce zpátky, čtyři, něco takového, kdy mi to vyšlo ten Claude Code, že se mi používá jako nejlíp. A přiznám se, že teď primárně jedu Claude Code z toho důvodu, že nemám informace o tom, že by nějaký nástroj byl diametrálně lepší než Claude Code v něčem jiném. Ano, můžou být malé segmenty, kde ty nástroje budou trošku lepší, ale já jsem si třeba došel k tomu, Nemám moc volného času, takže když už ho mám, tak si třeba zaexperimentuju. Ale to nejdůležitější je vlastně, že nejenom ten nástroj, ten agentic harness se tomu říká, to je ten Claude Code, kodex a tak dál, ale to, jak ty si vyladíš ty konfigurace, různý napojení na další nástroje, to je vlastně jako ta alfa omega a byť tam budeš mít nějaké malé nuance, mezi těma nástrojema, tak tohle je to hlavní. A proto jsem se rozhodl, že zůstanu u Claude Code, vyladím si já i s týmem vlastně ty workflows, které tam používáme, a tak dostaneš ty nejlepší výsledky. Nemyslím si, že svičování mezi nástrojema je správná cesta.

Jindřich: Rozumím a mám na to dost podobný pohled a podle mě není o tom výběru toho nástroje ale je to o tom jak ty se s ním naučíš pracovat a jak ty si sám uspůsobíš jak to workflow tak vlastně ty možnosti toho nastavení který ti ten nástroj dává. jako pokud by člověk měl zkoušet všechny nový modely co tež vždycky představí a marketing těch společností do nás hrne že ten benchmark je úplně nejlepší který tady kdo byl, ok může samozřejmě v nějakých případech jako být asi benchmarking je zas něco jinýho asi nebudeme úplně. zacházet do jinýho tématu nicméně souhlasím s tím vidím to jako velmi podobně opravdu osahace ten jeden nástroj být s ním dojistým jde spokojnej a naučit se z něj získat maximum než měnit pro jinej.

Filip: To mě přivádí k tomu, co jsem zmiňoval, k konfiguraci a připojení nějakých nástrojů. Ono je ve výsledku ve spoustě nástrojů strašně podobné. Ty konfigurační soubory… Tady mě Anthropic trošku trápí, oni jdou proti proudu trošku a ty soubory nazývají CloudMD a ostatní se shodli, že AgentsMD je ten správný standard, ale ono ve výsledku není složitého tyto soubory přesměrovat mezi sebou. Jsi schopný, když máš vyladenou konfiguraci pro Anthropic, poměrně jednoduše transformovat do nějakého jiného nástroje. Nicméně k tý konfiguraci jako takový, tak to si myslím, že je taková zásadní věc, která spoustu programátorů vlastně jako zastaví, když začnou používat ty, nebo začnou zkoušet tady ty jako AI agenty na vývoj. Protože ty si to nainstaluješ a on má jako docela dobrý wow efekt, ale ve chvíli, kdy ty máš už nějaké přesné očetkávání, jak ten agent v té codebase se vlastně chová. Ty máš nějaké konvence, k něčemu přistupuješ, ty máš nějaké pravidla a očekáváš ten výsledek tak, jak bys ho očekal od toho kolegy, tak ve chvíli, kdy nemáš nastavené konfigurační soupory, to je typicky ten CloudMD a Rules, tak ty dostaneš nějaký výstup a on ten agent je schopnej se podívat do těch všech možných souborů a jako načíst si ten tvůj projekt a pochopit nějaký pravidla, ale v základu sem tam něco jako mine nebo přeskočí a udělá to trošku jinak a to nutně jako nemusí znamenat, že je to jako špatně, protože ve světě programování těch přístupů máš jako bambilion, že jo, co můžeš použít, ale ten tvůj tým se prostě rozhodl pro nějaký přístup a pro toho jako respektuje a ty toho agenta pomocí těchto konfiguračních souborů chceš jako naučit, aby respektoval ty pravidla a ve výsledku ty konfigurační soubory to není nic jinýho, než je to jako markdown soubor, který ve plain angličtině nebo češtině, tak říká tomu agentovi, co má dělat, a on se vždycky vlastně tady ten soubor přilepí na začátek toho tvýho promptu. Takže to vlastně funguje stejně jako ty, kdybys to v tom promptu vždycky vypsal, což jako nechceš, tak to dáš do té konfigurace, jako zjednodušeně řečeno.

Jindřich: Jasně rozumím tomu asi že teda v rámci tvý efektivity jakožto vývojáře tak využívání jajíčkových nástrojů tak to největší oblast je asi ten agente k vývoji. Rozumím konfiguraci, rozumím skills o kterých jsi mluvil, ale ještě tam máš časně jaký plug-in případně jaký mcp server a rozšíření, obecně jak třeba pracují s tímhle tím.

Filip: Pluginy, to je primárně, oni už to adoptujou i jako jiný nástroje, někdy to mu říkají jako jinak, ale u Claude Code jsou to jako pluginy, což jsou vlastně jako balíčky, který ty si můžeš jako nainstalovat k sobě, a je to balíček nějakých skillů, což jsou taky, vlastně to jsou zabalený prompty, dalo by se říct, jo, to je prostě jenom textový příkaz, který pak se volá, nebo jako spouští, takže jako jsou to předpřipravený prompty. Nějaké configy, to už jsme si říkali. Nějaké ruly, to už jsme říkali. A potom nějaké připojení třeba k těm nástrojům. To jsou tzv. MCP servery. Už jsme se o nich tady bavili v předchozích epizodách. A to zase jediné, co dělá, je, že MCP, to je takové… Já to vždycky říkám jako USB pro jazykové modely. Je to prostě nějaké rozhraní, kde ty připojíš nějaký nástroj a ten tvůj agent ví, jak s ním pracovat. A typicky takový krásný příklad pro mě, který vždycky kodávám, tak je Figma. Figma to je grafický nástroj, kde ti jako designer připraví design uživatelského rozhraní. Jak ta appka má vypadat, uděláte návrh. No a často, že jo, ty předtím, než byli tady s ty agenti, tak jsi jako šel a teď jsi zčet, jak vypadá to tlačítko, jak je velký, jaký je tam text a tohle si všechno jako přebouchával do toho kódu, no a ty pomocí toho mcp, tady v tom případě je to Figma mcp, tak se připojíš do té Figmy a ten tvůj agent je schopný si načíst tady ty data přímo z té Figmy, takže ty mu jenom dáš odkaz, hele, chci naprogramovat tady tu obrazovku, udělej mi uživatelský rozhraní, dáš mu odkaz a on si načte veškerý ty rozměry, ty pixely, dpčka, další věci, barvy a má to vlastně v tom kontextu, protože Ten kontext je u toho vývoje, ale nejen u vývoje, to je jako obecně u práce s AI, to je jako zásadní. A ty, co děláš, vlastně jak konfiguračníma souborama, tak těma dle nástrojema, tak ty ho rozšiřuješ a umožňuješ tomu agentovi si na něj šáhnout, aniž bys ty mu to musel jako popouškovat.

Jindřich: Dej mě možná nějaký konkrétní příklady ještě nějakých jako use case o konkrétních mcp serveru třeba který používáš mimo ty figmy, ty jsi vysvětlil dobře jak to funguje, ale obecně nějaký konkrétní třeba ještě další mcp servery používáš.

Filip: Takový skvělej MCP server je, když… Třetivá většina aplikací pracuje s nějakou databází. A ty můžeš tomu agentovi složitě vysvětlovat, jak ta databáza vypadá. Abyť třeba neděláš jako backend, tak někdy potřebuješ vědět, jak ty jako data vypadaj. A ty můžeš použít MCP pro tu danou databázi a dát tak agentovi přístup se do databázy podívat. Takže když mu řekneš, že načítáme data z nějaké tabulky, tak ty už mu nemusíš popisat, jak ta tabulka vypadá, řekneš někdo z tabulky, on si to sám zjistí, dokáže postavit dotaz do databáze, aby si ty data vytahl, otestovat si ho a když tam je chyba, tak to opravit. Takže to je třeba jako delší MCP, který je super. Tady možná takovou malou odbočku. Teď se hodně řeší, že místo MCP, tak se dost často používají tzv. CLI nástroje. To jsou vlastně jako jednoduché apky, které běží v terminálu, stejně jako třeba ten Claude Code a oni tu výhodu oproti tomu MCPčku mají v tom, že nežerou tolik tokenů. Tak ten nástroj umí používat mnohem flexibilnějc a je to jako rychlejší. Takže je to jenom jiný druh jako připojení, ale můžeš jít se s tou MCP, můžeš jít se s tou CLI. Takže to je jen taková odbočka, že někdy třeba zmíním to CLI, ale je to ve výsledku to samé. No a ty pak… Já o tom budu mluvit i v dalších částech toho vývoje, ale typicky používám třeba ještě Playwright, což je zase nástroj, který umožní tomu agentovi spustit prohlížeč, spustit tam tu appku, otestovat si, jak vypadá, jestli tam nejsou nějaký chyby. A zase vlastně nemusíš ty tu appku spustit, proklikávat, jestli všechno funguje, ale dáš tomu agentovi, tady máš prohlížeč, otestuj si to sám. Stejně tak můžeš mu dát přístup do GitHubu, přímo do centry a dalších věcí.

Jindřich: Ok, pojďme se možná posunout, nebo jestli máš ještě něco k této oblasti, ale se mi budou zajímat další oblasti.

Filip: Jo, já možná takovou jako poslední myšlenku k tomu agentickému vývoji jako celku, tak Když s tím někdo začíná a chce to dotáhnout, aby ten agent co nejlepší ty výsledky dával, tak ten základ je uzavřít celý ten loop toho vývoje. To znamená, máš nějaké zadání, to si vytvoříš jako kvalitně, o tom se budeme bavit pak s tebou, protože ty jsi produkták, tak to nebudu vykrádat. Pak je ten vývoj, to je to, co jsem teď popisoval, ale pak je ještě ta testing fáze. Potřebuješ, aby ten agent byl schopnej po sobě ty věci zkontrolovat, AI je skvělý v generování kódu, ale také v dělání chyb, ale zároveň umí velice dobře po sobě opravovat. Takže když mu dáš možnost, tomu agentovi, jak on si po sobě může ten výsledek zkontrolovat a může to být formou toho playwrightu, nebo že mu necháš napsat testy, o tom taky budeme mluvit a podobné věci, tak on sám zjistí chybu, řekne, aha, jasně, opravím a jede si ten agent loop a k tobě už se dostane ten oditerovaný výsledek a ušetří si hromadu času. Takže za mě Při vývoji s agentama je ten základ uzavřít celou tu jako vývojovou smyčku.

Jindřich: Ok, tak možná než se posuneme na další oblast, tak velmi kontroverzní otázka, ale dokážeš jako kvantifikovat, kolik času třeba ti to šetří, jako chápu, že ten výtlak tý práce za stejný čas dokážeš udělat jako významně větší, ale máš nějaké možnosti jak to třeba kvantifikovat.

Filip: To je hodně zaludná otázka. Já si asi netroufnu tvrdit říkat úplně nějaké čísla. Ono totiž při tom samotném psaní kódu, tak si troufnu tvrdit, že se bavíme o desítkách procent až sklidně násobky efektivity, ale vždycky strašně záleží, jaký úkol děláš. důležitý zmínit, a to zmiňuji primárně pro lidi, kteří zadávají práci programátorům. Takže ten rozsah toho vývojářského úkolu často není jen o napsání toho kódu, ale je tam nějaký research návrh, architektury, potom zase nějaké větší testování, řešení edge case a rozplánování toho, jak to napasovat do té codebase, protože nebavíme se o wipecodingu, kdy to tam prostě střílíš, ale ty pořád kontroluješ ten kód, ty si jenom pomáháš ho generovat. tak tam těch kroků, kromě generování kódu, je dost. Troufnu si, že u většiny úkolů to jsou desítky procent zvýšení efektivity, ale u nějakých třeba hledání zapeklitejch chyb, kdy dostaneš fakt nějakou zapeklitou chybu, bys hledal v tom kódu různý cestičky, kam se tom může vydat, tak ty to zadáš AI, jdeš si na kafe nebo děláš něco jiného, ona si proběhne všechny možnosti a pak dostaneš report. A tady to je raketový šetření času.

Jindřich: Já si myslím, že je důležitý point a existují v té studie, že vlastně ten výtlak generování toho kodu, napsání toho kodu, tak to nikdy nebyl jako ten bottleneck. Existují samozřejmě vývojáři, kteří to dokážou kopsat velmi rychle, velmi dobře, velmi efektivní kod z xkvalité zkušeností, ale přesně ten bottleneck, tam jako to za ta kvalita toho zadání, obecně je to ten research, příbrava, architektury, diskuze s ostatními kolegy, protože přece jenom tři vývojáři a 20 různých způsobů jako jak to udělat na její společnosti nejlepší, udělat nějaký koncenzus. Code Reviews, PRK a podobně. Takže asi dokážu si představit, že čistě výtlak toho kódu je mnohem rychlejší, mnohem lepší, mnohem rychlejší. Ale zase je tady celá řada různých prací, které je potřeba společně udělat s tím, aby se dená fíčura deliverovala, ale tam už to aj tolik toho času šetřit nemusí být, asi šetří pořád.

Filip: Já jako teďka si to doufám tvrdit, že kód jako takovej je prostě levnej a díky AIčku je levnej, ale kód nemyslím jako celý ten software, protože neřeším teďka architekturu, neřeším věce, takže jako napsat kód je levný, ale jako ty přesně řešíš ty věci okolo a stejně jak se dřív říkalo to pořekadlo pro projektoví manažery, že devět programátorů opravdu nestvoří, nebo jako devět, že nestvoří dítě za jeden měsíc, tak jako je to jako stejný, prostě roste ti tam pořád to, že ten tým se musí domlouvat, jako manéžovat, takže jako já si třeba myslím, že jako když jsi solo vývojář, tak ten výtlak a ten efekt tý AI je jako raketově větší, než když máš pořád ten tým jako osmi lidí, kteří musí spolupracovat na tom jednom projektu, kdy prostě jako OK, generuješ kod rychleji, ale jako pořád tam máš ten management vokolo. Nicméně, když se posuneme dál, A řekněme, že máme odladěný ten agentick vývoj u tebe, když si vezmeš ten projekt a máš odladěné to workflow, abys udělal tu jednu feature. Ono se typicky stane to, že ty přijdeš, zadáš to tomu agentovi a teď 15 minut čekáš, než on si to přechroupe. a říkáš to, co budu dělat, tak někdo si vytáhne telefon a scrolluje, ale to není úplně ten správný přístup. Začneš přemýšlet o tom, jak bys mohl začít orchestrovat víc agentů dohromady, aby buď to plnili větší úkol v jednom celku, nebo abys mohl pracovat na víc úkolech paralelně. A když vezmu to jako první část, tak teďka je, myslím, že je pořád experimentální ta funkce, ale brzo asi nebude, už v Claude Code, tak se to jmenuje Agent Teams. A ty jsi schopnej vlastně nasadit na ten úkol víc agentů dohromady a můžeš jim nakonfigurovat vlastně jako různé role. Že jeden agent může být jako architekt, který řeší, jak to zasadit do té architektury, té aplikace. Druhý může být jako UX-ák, který řeší, jestli To je dobře použitelné. Většinou máš design, tak ho tam nepotřebuješ, ale pak máš developera, pak máš to Anthropic doporučuje. Mě se líbí, jak to pojmenovali, jmenuje se Devil's Advocate. To je agent, který šťourá do všech návrhů implementace, jestli náhodou by to nešlo udělat líp. Pak si tam můžeš dát testera, který ti má za úkol to testovat. A Claude Code pak umí ten tým agentů orchestrovat tak, že máš nějakýho, Mastra, který je vlastně jako řídí, ale co je super, oni už dlouho měli subagenty, ale ty si nedokázali povídat mezi sebou, ale tenhle ten tým agentů dokáže mezi sebou sdílet nějaký informace, čekat na sebe, reagovat na to, co udělá ten druhej, takže ty najednou díky tomuhle si schopne jako Dřív, když si to třeba rozpadal na dílčí celky, aby si toho agenta neuvařil, nebo aby si mu nenaložil moc, tak díky tému agentu jsi schopný mu dát velice komplexní úkol a oni si s tím dokážou poradit mezi sebou.

Jindřich: Já obecně tuto orchestrace AI agentů vnímám jako hot topic a momentálně je to něco, co v té technické komunitě hodně řeší. Já shodu okolností nebo respektive OpenClaw každej den posílá různý novinky a jako témata a klíčový slova takovéhle věci, které momentálně frčejí a kvůli různý zdroje třeba k tomu a tak podobně. a právě přesně jako to obecně ta orchestrace, tam jako vnímám osobně, že jako poslední dny týdny možná víc ne, tak je to něco, co hodně frčí a vyřeší to jako celá řada lidí, protože už ty lidi, který vopravdu, nebo ty vývojáři primárně, který už jsou na té vlně, že používají AI, používají ty agenty, tak přesně řeší tohle ten problém, jako jak z těch agentů dostat ještě víc. No jasný, přece když mají jenom jednoho agenta, tak to prostě neřekneš, dělej to rychlej a ještě přidej. Tudy cesta nevede, ale ta cesta vede právě v orchestraci.

Filip: Přesně, ty prostě najednou zjistíš, že dokážeš to tomu agentovi zadat, ale ty na ně čekáš. A pak oni čekají na tebe, než ty se zase vyjádříš. A ten Agent Teams, to je ta část toho, kdy jsi schopný jim dávat komplexnější úkoly. Ale potom, já jsem v posledních dnech asi, ty píšeš týdnech, začal experimentovat i s nástrojem, který se jmenuje Vibe Kanban. A ten se snaží řešit ten problém toho, Když se od Vaip Kanbanu vzdálem, tak ty typicky máš ten jeden projekt, tu jednu verzi a necháváš toho agenta na tom pracovat. Ty si můžeš otevřít nový vokýnka, ale ty mu nechceš zadat víc úkolů. On si bude šáhat do toho jednoho projektu. Takže ty si můžeš začít tvořit, říká se tomu, takzvaný git work trees, což je, že se ten projekt znova skopíruje, někde vytvoří a ten agent bude pracovat na něm. Je to krkolomnější, musíš na to myslet. No a… Já jsem začal řešit, jak tady s tím pracovat. První věc bylo, že Claude v jejich desktopové appce má tu záložku i kód tam. A ty v ní jsi schopný nejenom řídit ten lokální vývoj, ale si schopný říct tady ten úkol, jakoby proveď na serveru Anthropicu. Ty to prostředí, místo toho, aby to běželo u tebe, tak nasadíš na jejich serveru, a provede se to tam, takže ty můžeš takhle v té appce nasázet víc úkolů paralelně vedle sebe, oni se provedou vždycky v různých verzích, že jo, a pak jenom uděláš, říká se tomu pull request, což je takovéto porovnání změn, a jestli se ti líbí nebo ne, a ty je případně jako schválíš a dáš je do toho projektu zpátky, takže vytvoříš takové větve, že jo, a potom zase je jako slučuješ dohromady. No a Vibe Kanban jde ještě jako o kousíček dál, že ty vyloženě máš takový, jak jsi zvyklý z těch aplikací prostě To Do, In Progress, Review, Done, takové ty fáze toho úkolu, tak ty vlastně si díky Vibe Kanbanu schopný mít tady ty fáze tam vizuálně daný, A na každé tý fázi ti může ten agent pracovat. Vidíš tam veškerou tu historii, kam jsi šahal, vidíš tu konverzaci a vidíš, jak on si sám posouvá ty kartičky. Pak koukneš do toho reviewu a máš to přehledně vedle sebe. Můžeš to mít rozjeté. Já to mám rozjeté na tom svém Macu, kde mám OpenClaw, takže ne na tom svým hlavním. Pak přijdu a můžu si tam pustit i preview. Takže vidím, jak vypadá ten danej úkol, co zapracoval. A je to vlastně o tom, ty si ulehčuješ to, jak jako zvládat víc paralelních věcí dohromady, protože hej, to je vlastně jako můj největší pain teďka, jako řídit víc věcí najednou a držet nějak jako v hlavě, v jaký fázi jsou, jestli už se to dokončilo a tak dál a ten vibe kandaban ti k tomuhle vlastně jako pomáhá.

Jindřich: Já si přímě nejsem jistý, jestli jsem tomu porozuměl správně, protože já ten kodůl neznám, ale představu si to skládka jenom jako v obyčejný kanban board, jak máš třeba v džíře nebo u tracku nebo v podobných jiných nástrojích, co ti přináší víc než nějaký MCB server třeba právě na džíru.

Filip: Jo, ten, vlastně jako ta největší přidaná hodnota, ne je vlastně strašně jednoduchá. To je totiž, on je integrovaný přímo k tomu vývojovýmu agentovi, takže ten setup mu je takovej, že já mám MacBook, na kterým běží Claude Code a nad ním běží ještě Vibe kanbán a já pak vidím přesně tyhle úkoly, jako v tom Trelu nebo v Tajíře, s jediným rozdílem, že já přímo z toho úkolu jsem schopný říct, agente, teď to zapracuji. a on to začne zapracovávat, já tam vidím, jak na tom úkolu pracuje, a mám jako spárovaný ten progres celou, vlastně tu jako konverzaci i s těma změnama k tomu tiketu. Ten tiket se posouvá v těch úrovních, no a on se dostane až do review, a já pak k tomu přijdu, rozkliknu si, vidím to zadání v tom úkolu, ale vidím tam i jakoby celý, celou tu historii, jak ten agent na tom pracoval, vidím tam i preview toho, jak vypadá ta změna, takže si to rovnou můžu otestovat, pokud je to teda webová appka, mobilní úplně ještě jako neuměj. A když je to v pohodě, tak vytvořím PR-ko a můžu to dát na kolegu, nebo si to stáhnou k sobě do počítače a doladit nějaké detaily. Ale ten rozdíl je v tom, že ty máš synchronizovaný mezi těma tiketama tu práci toho agenta a vidíš to přímo v tom tiketu.

Jindřich: Zajímavý. Pojďme možná na další oblast, jestli máš tomu za tomu. Ať se vejdeme taky do nějakého rozumného času.

Filip: Tady by se o tom dalo mluvit spousta časů. Další oblast mám QA, quality assurance, což je zajišťování toho, že program, aplikace se chová správně, že se testuje a tak dál. A tady vidím obrovský potenciál. to strašně teďka dát jako propaguju, když o tom mluvím, že se snažíme jako posouvat, nebo je správně se snažíme posouvat z toho, že AI je reaktivní, to znamená ty jí zadáváš ty úkoly, že jo, ty třeba v tom webcam banu nebo někde, do té fáze, kdy ta AI je vlastně jako proaktivní. To znamená, že já v bodě, kdy třeba my hlídáme v našem softwaru chyby pomocí nástroje Sentry, to je prostě, když třeba appka spadne a prostě něco se tam rozbije, tak tenhle nástroj to zachytí a je schopnej nám o tom dát informaci. Dřív si přišel, musel ses na to podívat, zjistit, o co jde a upravit to. Potom se to dělalo tak, že už máš napojený to MCP do té Sentry, takže jenom vezmeš odkaz, dáš to agentovi a řekneš, prosím, oprav. No a teď jako ta delší fáze je, že proč by tohle ten agente mohl dělat sám, že jo? Takže on pozoruje center, jestli tam něco novýho, nějaký problém se nevyskytl a jakmile ten problém jako se vyskytne, tak on se ho rovnou vezme, zanalizuje, o co jde, jestli ví, jak to fixnout, popíše ti tu příčinu a připraví ti rovnou vlastně jako možnej fix, možnou opravu. A tohle ti dá zase ve formě pull requestu, kdyby ti to dal kolega, který to opravuje, a ty už jenom přijdeš, podíváš se, dává smysl, nedává, případně upravíš, v nejhorším to zahodíš, ale ještě ty jsi do toho neinvestoval žádný čas, protože jenom jsi dostal tu přípravu. No a on ti to prakticky nějak připraví a vlastně ty jsi zušetřil ten čas, že by jsi musel říct, že jdu opravovat chyby, jdu se tam podívat, zadám to agentovi. On tohle udělá sám a ty už přijdeš k hotovým věcím.

Jindřich: To mě možná napadá, že nebo nevím, jestli tohle máš, nebo jestli jsme trošku nepředběhli, ale to, co říkáš, tak to je trochu expose ty chyby, že ty opravuješ něco, co najdeš. Ale asi ten krok předtím, tak aspoň z mýho úhlu pohledu, tak ty AI agenti by se daly poučít i na pokryvání toho kódu, ať už unit testama, nebo vytváření testovacích scénářů, vytváření a procházení playwrightu a vůbec předcházet těm potenciálním chybám, než potom opravovat ty, které ve skutečnosti přijdou.

Filip: Já jsem si to tady trošku nešťastně se řadil v poznámkách, ale přesně tohle byl jeden z dalších bodů, že to předcházení těm chybám, tak ten agent je velice dobrý v tom generovat tzv. unit testy. To jsou testy, které pokrývají malé části kódu. Všichni vývojáři to nemají rádi, je to otravné, protože už to máš jako hotové, všechno funguje hezky a teď to ještě musíš pokrýt testama, pokud teda nejdeš na test-driven development. Ale to je jedno. Takže ty si můžeš nechat vygenerovat tyto testy, které se pokaždé zpouští, když třeba se vydává nová verze, nebo jak si to ten tým nastaví, a jsou schopní zachytit nějaké chyby. Další krok to jsou vlastně to, co jsi popsal s tím playwrightem. To jsou takové ty end-to-end testy. Že ty dřív si psal… přesný scénáře, co se má stát, že teď ten robot klikne na tohle tlačítko, vyplní tady ty informace a musel si vlastně jako namyslet dopředu veškerý ty scénáře, které můžou nastát, což jako pořád má za mě svoje místo, protože to je ten deterministický výsledek a ty víš, že se vždycky jako stane. Nicméně teď s těmi AI agentama jsi schopný nadefinovat tyto testovací scénáře v klasickém jazyku a říct mu, co má udělat. A on si třeba pomocí Playwrightu tu apku prokliká a ty mu jí nadefinuješ. Dobře, testuj. Registrační flow. Uděláš to, že tady nejdřív dáš špatný e-mail, že si zapomněl heslo, něco. A můžeš mu ty scénáře nadefinovat a on si to sám testuje. A tohle zase jsi schopný spouštět. Pravidelně třeba před každým vydáním nové verze, nebo každý den v noci, když se přidaly nějaké změny na tu testovací VTF a podobně.

Jindřich: Já to vnímám jako základní use case. A mám takový pocit, že jsme na to narazili už v předchozí epizodě, kdy jsme se bavili o wipecodingu. Protože přesně tohle něco, co v rámci wipecodingu, ty můžeš velmi dobře použít. Můžeš si tam snadno napojit ten Playwright MCP a uděláš nějakou změnu. tak mu můžeš říct tomu agentovi zkontroluj to po sobě a proklikaj tu aplikaci že se nikde nic nerozbilo, což je skvělý že jo protože když trošku odbočím právě k tomu vipodingu, tak tohleto něco co se často děje já implementuju opravím jednu věc v jednu část softwaru a jiná část se mi rozpadne aniž bych si toho všiml.

Filip: Rozhodně. A je to jako… Vlastně v tom wipecodingu ty k tomu často přistupuješ, takže to necháváš dělat toho agenta, když ty to vyvíjíš. A v tom profesionálním vývoji ta snaha je odstínit ty vývojáře od toho, aby se to dělo automaticky. Protože čas vývojářů je drahej, takže ty se snažíš to dělat automaticky. A to mě přivádí ještě k jednomu bodu, co jsem této sekci měl. To je vlastně tzv. code review, já už jsem to tady párkrát nakous. Ale to není nic jinýho, než že já udělám nějaké změny, nebo AI, to je jedno, a druhý kolega to po mně kontroluje, jestli jsem prostě někde neudělal nějakou botu. A tohle to, tak za první to vývojáři nemají moc rady, protože číst po někom kod a ty se v tom musíš vyznat, je to prostě otrava. Ale druhá věc je tak, že spousta těch chyb, co se tam objeví, tak se dá odchytit jako velice jednoduše. My už historicky jsme měli nějaké statické analýzy kódu atd., který… na základě definovaných pravidel to kontrolovali. Teď do toho vstupuje AI a ty jsi schopný se nakonfigurat. My to máme přes Cloud Skills. Máme nadefinované Cloud Skilly, které mají popsané, na co se mají zaměřit. Máme tam agent teams, to znamená, že každý agent kontroluje nějakou část. Protože když necháš jednoho agenta zkontrolovat všechny změny, když jsou větší, on se v tom začne ztrácet. a třeba na něco přeskočí, tak nám se osvědčilo používat ten tým agentů a že jeden kontroluje jenom architekturu. Jestli jsou soubory správně v složkách rozřezané, správně pojmenované, dává smysl nějaká úrovně abstrakce a tak dál. Delší kontroluje jenom, jestli jsi náhodou někde nedal ten text, který tam zobrazuješ tomu UI, tak jestli jsi ho nedal natvrdo, protože pak nejsi schopnej ho přeložit. Podobné takhle máme rozpadnuté use cases. No a… funguje to tak, že kdykoliv někdo otevře se tomu říká tady to PR, to znamená, že jako publikuje ty změnačce, na to někdo podívá, tak ještě předtím, než k tomu přijde ten kolega, tak se na to mrkne to AI, udělá tady tu analýzu, hodí tam vlastně komentáře přímo k těm částem kódu, který se to týká a To ještě teda nemáme, ale je to moje vize, kterou budeme dělat je, že nad tím pustíš dalšího agenta, který ti vlastně jako navrhne rovnou ty opravy a potom nad tím můžeš pustit třeba dalšího agenta, který ještě jako bude tak jako spochybňovat ty opravy, jestli náhodou se jako správně, a vlastně jako necháš ty agenty se jako poprat mezi sebou a ty už pak přijdeš vlastně k tomu code review, které je vlastně do jisté míry vyřešené. A to už se jenom podíváš, jestli bys ještě něco doopravil, jestli ti to dává smysl a děláš ten lidský review, který zatím je pořád potřeba. A kdybych mohl vysvědlit,

Jindřich: jak to technicky funguje. Předpokládám, že ten Claude Code musí někde běžet. Vy asi používáte nějaký GitLab, GitHub, něco takového, takže tam asi bude ten bot, který vždy přiřadíte vy to code review. A no, asi to vysvědli. Těch přístupů

Filip: je nespočet. Ten takovej zaměnej, optimálnější je přesně to, jak jsi to začal popisovat. My máme GitHub, takže máš tam takzvaný GitHub Actions, což jsou vlastně ty pipelines, které se spouští, když se něco staneme. Vlastně jako spustíš nějaký virtuální počítač pro zjednodušení. A ty tam můžeš nainstalovat aplikaci jako Claude Code a můžeš mu nadefinovat, kdy se má spustit. Nebo když ho v Code Review označíš, tak on na to zareaguje a spustí virtuální počítač někde, ten Docker Image, a provede ty úkoly a pak se zhasne a dá ti ty výstupy do GitHubu přímo. Druhá taková hekicesta, kterou teďka používáme, nebo používám já, je tak, že pokud ty nechceš… Protože když to máš v GitHubu, musíš platit za API tokeny, za každý ten token zvlášť. Což v kontextu ceny vývojaře je pořád… Troufnu si, že je to zanedbatelné, ale je to nějaký větší náklad. Ty jsi schopný rozběhnout si k cloud kóda někde na serveru, potom pomocí nějakého skriptu si tahat změny, co vyšly v PRkách, a spouštět to lokálně v rámci předplatního. Nepoužívám to takhle všude. Používám to na svojich projektech, šetřím prostě tokeny zcela na rovinu, ale je to taková šedá zóna, jako Anthropic na tohle se netváří úplně dobře, tak to jenom upozorňuji posluchači, že na to bacha, může se stát, že by se to Anthropicu nelíbilo, že v těch podmínkách, že to máš používat pro osobní potřebu, ty subscriptions, nemělo by to být, že v těchto automatizacích tohle je takové jako na pobezí, ale je to taky jedna z cest. Zkrátka, těch způsobů je ještě víc. Pak můžeš Claude koda mít třeba rozběhnutého přes ten apiklíč. Tam nemusíš mít subscription, takže ti nemusí běžet v GitHub, ale může ti běžet na tvojím počítači. Teď se hodně řeší, jak popropojovat tady ty dílky té skládačky dohromady, protože my víme, že toto AI zvládne vyřešit dobře. A teď se hodně řeší orchestrace a to, jak poskládat to dohromady, aby to bylo co nejvíc autonomní a ty se za to nemusel šahat. co se týče

Jindřich: toho pricingu, tak já si myslím, že to dospodobně řeší každej, protože opravdu pokud byste to měl použít, všechny ty nástroje používat tak, jak se skutečně mají, tak se člověk skoro nedoplatí. Takže jiný téma, každopádně. Možná přibíhám a možná se můžeme pustit do

Filip: další oblasti. Ta další oblast, já jsem si ji nechal vlastně nakonec bytě vlastně předsazena úplně před všema, ale říkal jsem si, že vlastně není tak úplně jako sexy, tak je ta administrativna kolem toho vývoje a nějaké jako přenášení toho kontextu, protože zase ty prostě se chceš zbavit toho, abys nebyl… Říkám to lidské USB, že kopíruješ zadání do svého agenta a musíš mu to předávat, tak ty pomocí MCP si schopný si napojit JIRu nebo jakýkoliv systém, kde si eviduje tvůj tým úkoly. Pak už jenom tomu agentovi dáš odkaz. Pojďme zapracovat ten úkol. On si natáhne kontext v nějakém planning modu. To jsem nezmínil u agentního vývoje, tak jen taková odbočka. Je dobré používat plánovací mod pro agenty, protože je mnohem jednodušší odladit ten plán a jeho možné chyby v tom textovém zadání, než když ten agent začne dělat změny v tom kódu a řekneš, že takhle jsem to nechtěl, to má být jinak, a teď to musí smazat a znova předělat, tak je to právě náročnější. Tak to je taková malá odbočka. Ty můžeš si napojit tu jiru nebo nějaký nástroj, aby si natáhnul kontext. Nebo třeba i GitHub. GitHub má skvělý CLI a jsi schopnej přes to dělat jakékoliv úkony, co ty klikáš míší v GitHubu. Tak to můžeš napojit tomu agentovi. Samozřejmě chceš mu dát nejaké omezená práva, aby ti třeba nemohl smazat nějakou větev a tak dál. To je na delší debatu. Ale… Vlastně ulehčíš si tu administrativu, abys nemusel překopírovávat věci.

Jindřich: Co se týče ty administrativy, tak to je asi celá řada různých. Přece jenom když já se trošičku odprostím teď o těch use case vývoje, tak obecně ty manažerské práce a příprava toho zadání a mapování těch aktuálních funkcí, tak to je zase něco, s čím ti to AI v dnešní době dokáže velmi pomoci. možná je o tom částečně budeme mluvit v příští epizodě, protože to je zase nějaká oblast k kterým mám možná něco blíž já třeba. Ok ale každopádně zajímají, máš tam třeba ještě něco obecně z té administrativy, co by jsi si zmínil co ti hodně pomáhá

Filip: s čím pracuješ. Já bych tam ještě zmínil, ale to asi nutně není administrativa, ale jsou to takové ty jako dílčí části, které jsem třeba nutně nevěděl, do jaký se chce se jako zařadit, tak jako jedna věc je, že ty IA agenti jsou jako naprosto skvělí na onboarding nových lidí do toho projektu, protože jako to je vždycky strašná bolest, když ti přijde jako nový kolega, a on může být jako skvělej vývojář, ale jako nezná ten kód, nezná ten projekt, a díky AI on je schopnej se na spoustu věcí doptat. Ty už nemusíš přijít a takhle to s ním proklikávat do detailů a on ti pak první dva měsíce píše s každou blbostí, protože mu to není jasným, že nemá tu doménovou znalost. On je schopnej se AI doptat a on mu to zanalizuje ten kód a vysvětlí. Takže to je jedna ze super věcí, na co se teda použít. A druhá věc, a to platí jak pro programátory, tak i pro netechnické lidi, ty jsi schopnej díky AI si ověřovat nějaké hypotézy přímo v tom kódu. Řekněme, že ty si řekneš, jak nám funguje tady načítání detailů toho produktu. Načítaj sem tam ty fotky všechny hnedka, anebo až když si člověk swipeuje tou galerii. To je příklad, co mě teď napadlo. A ty jako vývojář nebo i jako netechnický člen týmu, pokud máš přístup k tomu repozitáři, k tomu projektu, tak ty se můžeš zeptat AI, jak to funguje. Ono ti zanalizuje ten kód a dá ti ten výstup a nemusíš už třeba jako někdo z… jako produkták, jako třeba ty, že jo, už nemusíš psát jako kolegům, prosím tě, kluci, zjistěte mi z Codebase, jak toto funguje a pak čekat prostě dva dny, než ti to někdo dá. Prostě se zeptáš a dostaneš tu odpověď a to je

Jindřich: super efektivity booster. To rozhodně obecně, tohle přesně co jsi teď zmínil, tak to nejkrásnější, co se na to minimálně považuji já je to, že si s tím, s tou code basí může povídat jako les kdo, přesně ty jsi to prakticky zmínil, jako ne technický člověk, tak se může doptat na to a jako ne jen, že je to jako efektivnější, rychlejší jako pravděpodobně, tak jako neotravuješ těm jako další lidi, že máte celou řadu výhod a v drtí většině se jako dostaneš tomu výsledku minimálně k té odpovědi, kterou ty bys jinak chtěl potom vývojáři, který by to musel sednout, sudnou část kodu třeba ani nedělal, když je to větší projekt musel by to procházet a zjišťovat. Určitě jako jeden z typicky skvělých use case využití

Filip: AI. A hlavně i jako já vývojář, tak mám jako často spoustu situací, kdy prostě ty už si nespomínáme, jak jsme to před tím půl rokem udělali a teď jako buď to bych mohl jako 20 minut proklikávat kód, anebo to prostě zadám agentovi, pokračuju si v té práci, co jako dělám a pak jenom si říkám, jo, takhle to funguje, aha, super, že jo. No vlastně. to je jako super a další věc ještě, no promiň.

Jindřich: Jako napadá myšlenka, nejen že ti ten agent dá tu odpověď, ale on tě třeba ještě přesně navede, řešit se to tady, řešit to, ta podmínka, v této třídě najdeš tu logiku, takže ne technickým lidem dá odpovědět, technickým lidi navede, kde si to můžou uvěřit.

Filip: Jo, a taky třeba častej use case je, že ty v rámci toho týmu, nebo v té firmy, tak často nemáš jeden kód, nemáš jeden projekt, máš jich jako víc, typicky jedné jednodušší rozdělení, back-end, front-end, ale pak typicky máš třeba jako mobilní apky, pak nějaké jiné servisy a máš těch projektů víc. A ty díky tomu agentovi jsi schopný je popropojovat nebo říct mu, ať se podívá do jiného projektu. A on si zase najednou spojí ty věci dohromady. Takže já když dělám na mobilní appce a teď mi něco úplně nedává smysl třeba s nějakým endpointem, jako serverem, který volám, tak já můžu říct, hele, a ještě si to ověř, jak je to udělané tady na tom backendu. A už nemusím pracovat jenom s nějakou obecnou specifikací toho endpointu, protože tam může být chyba. Ale můžu říct, když se podívá do CodeBase, jestli to tak opravdu je. Tohle je taky super.

Jindřich: Ráda. Další oblast? Nebo jak to tam

Filip: máš? Já přemýšlím. Já už tam nemám nutně oblast, samozřejmě těch dílčích věcí, ono by se dalo u každého toho jít fakt jako do detailu. U orchestrace Agent Teams bychom se tady mohli bavit hodiny. Nicméně já jsem tady vlastně jako takovou pátou oblast si dal takové schrnutí toho, jak já vnímám teď přístup k tomu vývoji a co si myslím, že za mě je ten mindset, který ty vývoje dneska musí mít, protože Ať se nám to líbí nebo ne, protože spousta vývojářů má ráda ten kód, který píše a ráda ho píše ručně, tak bohužel tahle doba si osobně myslím postupně odchází a že většina a většina kódu je generovaná. Já si to doufnu tvrdit, že fakt 90 kódu, který napíšu, tak je vygenerovaný AI. To neznamená, že bych ho nečetl, nekontroloval nebo tak. To ne je, že by jsem ho neviděl, ale už ho nepíšu ručně, protože je to rychlejší nechat udělat toho agenta. No a tohle je směr, kterým se to ubírá a ať chcem nebo ne, my vývojáři, tak my třeba nemáme úplně rádi ty code reviews, tu kontrolu kodu po někom a použílejko v této fázi se dostáváš do toho, že neustále po někom a ten někdo je AI, kontroluješ ten kod. A to je jako prostě směr, kterým to teďka jako jde a my jako programátoři se posouváme víc do role těch jako architektů nebo těch, co vlastně tu AI nějakým způsobem jako směřujou, případně jako řešej jak to zorchestrovat, aby to bylo celý jako efektivní. a zkrátka já to vnímám jako takovou další vrstvu té abstrakce, kdy my jsme začali, že on měl si děrné štítky, potom přišli nějaký assemblér a další jazyk a vždycky se stavilo nad tím a vždycky byli lidi, kteří říkali, ty jo, ale ty když píšeš tomu C, tak ty prostě nevíš, jak to v tom assembleru funguje, to nikdy nemůžeš udělat dobře, protože ty nerozumíš tomu, jak to funguje vevnitř. A ty lidi, co dnes píšou v JavaScriptu nebo v Javě, tak jim zase lidi, co píšou C, říkají, no ale vy si neallokujete tu paměť sami, vy nevíte, jak to pořádně funguje. Ale prostě takhle ten trend je a já si myslím, že prostě delší úroveň ta abstrakce je prostě angličtina. A jestli

Jindřich: zůstanou… Promiň, povídej. Nebojí se právě že tohle to bude jako způsobovat právě to že ne všichni budou tak pečlivý jako ty aby ten kod jako četli a potom bude vznikat obrovský množství kodu, kterým postupem času jako nebudou ty vývojáři který to tvořil jako rozumět a bude tomu rozumět jenom ten ajčkovi agent až vlastně by to mohlo vyústit v to že nikdo tomu kodu vlastně nebude rozumět.

Filip: Kapu dotaz, nicméně oba jsme dělali v zakázkovce a dostali se k nám různý kody i od lidí, kdy bylo jako před AI a to, že ti přišel projekt, který je totálně jako zbastlený a nedá se v něm vyznat, tak to nebylo jako Stávalo se to prostě i dřív před AI. Ano, díky AI je toto asi častější, ale vždycky je to o těch lidech, jak se k tomu jako postaví a u těch jako kvalitních software, tak pokud ty workflows a ty jako Pravidla v té firmě jsou nastavené správně, tak si myslím, že se tohle dítě nebude. Teď dávám stranou to, jestli si to ty vývojáři budou pořád tolik užívat, protože pořád jenom kontroluješ kód a to, tak to je vedlejší. Ale ta kvalita je podle mě čistě daná tím, jaký máš nastavený ty workflows. A ano, bude přibírat podle mě spoustu zbastleného kodu. a já tam vidím jako dvě roviny. Jeden je, že u nějakého softwaru to vůbec nevadí, protože ho prostě zahodíš, je to takový jednorázový software, nebo je to nějaký proof of concept, tak se prostě zahodí a přepíše dobře. Napsat ten proof of concept bylo jednoduchý a ty ho můžeš použít jako takovou dokumentaci pro ten správnej, co už pak přepíšeš. A druhý směr je který jsem samozřejmě zapomněl, protože jsem se rozvášnil. Jo, že ty, i když budeš mít nějaký relativně zbastlený kód, tak ty za nějakou časovou investici to podle mě v budoucnu s AI-čkem zase budeš schopný třeba rozplést a udělat pak správně. Takže ano, určitě bude vznikat spoustu zbastlenýho kodu, ale to není vina AI-čka, to bude vina vždycky těch lidí a těch workflows, který se nastaví. A… budoucnu, já jsem jako extrémně zvědavej, jak se budou vyvíjet programovací jazyky, protože teď se programovací jazyky vyvíjely pro nás jako vývojáře, aby byly dobře použitelný, hezky čitelný, ale opravdu je ta syntaxe, to, jak se píšou ty programy dneska, tak dobrá, jak je dobrá pro nás, tak dobrá pro AI. Neexistuje třeba lepší formát zápisu kódu pro AI, který pro ní bude čitelnější. Takže třeba, a teď hodně hypotetizuju, se můžeme dostat do bodu, kdy už nebudeme rozumět tomu kódu, protože to bude úplně jiný format, který je

Jindřich: optimalizovaný pro AI. Zajímá filozofická otázka, může být nám mět na další epizodu, ale k tomu předchodnímu podu, na co já jsem spíš trošku mířil je to, jestli potom nebude jako nedostatek jako těch vývojářů, který by skutečně tomu kódu rozuměli a dokázali by tam třeba něco vyřešit. ještě bez toho AI případně, že se potom, jestli si časem nemůžeme dostat, být takhle na jednu stranu, jasně ty veškej ty AI modely se budou zlepšovat, budou lepší, budou přesnější, pravděpodobně budou rychlejší, ale jako zároveň, jestli někdy si nemůžeme dostat nějakého bodu, že se to AI jako zaciklí a už tomu ty vývojáři jako nebudou rozumět, protože jsou zvyklí ten kód jako generovat, ale ne ho skutečně jako psát a

Filip: vymyšlet. Jo, už chápu, chápu tu otázku, no. Hele, v tohle se ve mně jako pere. Já vlastně na to nemám jasný názor. Jedna část mě, ta programátorská, říká, jo, hele, to jako bude problém, protože jako ruku na srdce být dneska junior, tak to musí být strašně těžké, jako přesvědčit se, aby ses to všechno naučil, protože jsi jako jeden prompt od toho, aby to AIčko udělalo za tebe, takže jako ta generace juniorů si myslím, že jako nebude tak dobrými programátory v tom, jako původním svolovat smyslu před AI, jako byly ty generace, který se to naučili bez toho. Na druhou stranu je otázka, jestli to bude potřeba, jestli to není ten klasický přístup, jak už jsem zmiňoval, že ti někdo řekne, ale ty nerozumíš tomu assembleru, jak se ty instrukce v tom procesoru tam posílají. No a jako vlastně nepotřebuju, že jo? A jako jestli opravdu jako se může stát, že to AI-čko najednou jako tak zhloupne, že to jako nerozplete ten kód, nebo jako neopraví. Já nevím, jakože tohle je fakt na nějakou další filozofickou debatu, říkám, pere se to ve mně tady ty dva názory. Já se teď

Jindřich: už možná trochu dostávám do oblastí, kterých nejsem kovaný, v kterých nemám tu expertise, ale říkám si, že čím víc toho generovanýho kódu bude, čím víc toho špatného generovaného kódu bude, tím logicky se ty modely musí učit nad tím špatným kódem a logicky z toho pak i generovat

Filip: ten špatný kód. No, jasně, rozumím. To je pak o tom řízení těch trénovacích dat. Jo, tohle je reálný problém, který se řeší i u klasických jazykových modelů. Dneska více jak polovina dat na internetu je AI-generated. AI se to učí z toho, ty modely se na to trénujou. Takže to… Ano, může to být reálně problém. Co je lepší u kódu než u textu je, Do jisté míry, ne jako u všeho, ale do jisté míry jsi schopný verifikovat tu správnost. Líp se verifikuje to, jestli je to udělané správně, než u nějakého volného textu. Pak se můžeme bavit o nějaké architektuře a dalších věcech, ale těch skoro náboženských válek, které se vedou mezi programátorama, jestli tenhle framework je dobrý nebo tamten je lepší a tenhle přístup je lepší nebo tamten. Tady je prostě věky věků a… Nevím, no. Vnímám to, že by to mohl být problém, ale myslím, že se to vyřeší, že to fakt nebude takový issue. Spíš si myslím, že to půjde tou cestou nějakých jiných přístupů, které budou víc optimalizovaný pro tu AI. Ale tady už se pouštím hodně do nějakého filozofování. Nemám to

Jindřich: podložený. My se možná trošku takovým kroužkem vracíme zpátky na to, co jsme řešili na začátku, a to je oprostě zaměřit na ty nástroje, které momentálně máme, naučit se s nima co možná jako nejlíp, nejefektivnějíc pracovat. A to je asi ta cesta, jak nás bude dělat produktivní. No důležité je určitě nezaspat, adaptovat se zkrátka na tu dobu, adaptovat se na tu technologii, nebo spíš na ty možnosti, které nám ta technologie

Filip: přináší. Jako přesně, tyhle ty filozofický otázky, jako jestli to bude problém a tak dál, tak je strašně jako super se nad nima zamýšlet a přemýšlet nad tím, ale jako za mě to není argument nepoužívat tu AI v tom vývoji, protože až chceš nebo ne, tak ty, co ji teďka budou používat, tak prostě budou jako násobně rychlejší. A ve výsledku k čemu je kód? Kód není od toho, aby se na něj hezky dívalo a měl jsi z toho krásný požitek jako programátor, když ho čtáš, ale je to k tomu, aby řešil nějaký problém v tom reálném světě, nějakým formou nějakého produktu, nějaký automatizace nebo něčeho takového. A pokud to někdo udělá třikrát rychlejší než ty, tak v kapitalistickém světě se ti to prostě neudržíš.

Jindřich: A možná teda otázka na závěr, která mi napadá, kdyby ti Filipe Tečem bylo patnáct, nebo podobnej věk, vybral by si v aktuální době kariéru vývojáře. Ty kráso. No.

Filip: Asi. Nic mě zaskočil, to jsem nebyl připravený. Není to úplně jednoznačný, koukám. Ne, ne, vůbec, vůbec. Takhle, já si myslím, že jako rozumět tomu, jakým způsobem ty programy, počítače a vlastně jako technologie fungujou, tak ti v současném stavu umělý inteligence dává, trofnu si říct, jako superschopnosti, protože ty si prostě zkrátka dáš jedna a jedna dohromady a chápeš, proč se něco děje a je to jako obrovská výhoda oproti jako netechnickým lidem. Takže jako V dnešní době bych řekl ano, jako má to smysl, bude to těžký, protože tě to bude svádět nechat si to všechno vygenerovat AI, než se to jako naučit, jak se to má jako správně dělat, Věřím, že třeba za tři, čtyři roky by moja odpověď mohla být jiná, protože já si fakt netroufnu predikovat, kam se tohle celé za… Jenom jako za rok. Kde budeme prostě za rok. Protože vědím si, že tady z toho, co řešíme, nějaký orchestrace, AI agenti, tady je rok. To není tak dlouhá doba. – Ani to ne, možná někde

Jindřich: odlete. – ani Možná ne, no. Přesně tak, možná ani ne. Mám pocit, že

Filip: je to tady pořád, ale není, že?

Jindřich: Tím, že člověk tím žije, no. Přesně tak, je neuvěřitelně, jak ta doba letí, samozřejmě. No nic, Filipe. Tvoje znalosti jsou fascinující a mohli bychom se tady bavit ještě dlouho, je opravdu neuvěřitelný, je vidět, že se tomu věnuješ a je neuvěřitelný, kolik informací si o tom AI pochytili relativně za tu krátkou dobu, co tady mezi náma je. Jako co říct závěrem, je to určitě extrémně zajímavé, Na druhou stranu, že je to moc krásné době. Doufám, že alespoň někoho toto tvoje povídání inspiruje a podívá se víc toho, kde je některý z těch use cases, který jsi změňoval. Protože přece jen pokud se někdo na tu technologii skutečně adaptuje, ideálně přijímá ty use cases, se někdo adaptuje, tak mu to dává super schopnosti. Zakončím to tím, co jsi říkal

Filip: sám. Je to tak? No a možná jen taková poznámka pod čarou, pokud se na to díváte a vidíte datum pod videem, že bylo vydané třeba před třemi čtyřmi měsíci, tak je dost možný, že už se tady bavíme o zastaralých věcech, takže tak jako podotýkám, že to tempo toho vývoje je prostě šílený. Nicméně, jo, jakoby doba přeje lidem, který rádi tvořej, rádi jako vlastně mají ten výsledek a za mě žijeme jako v krásné době, no, umožňuje nám tvořit a jednočlenej tým je díky agentickému vývoji, tak prostě, když si vzpomenu na ty hodiny, dny, měsíce, co jsem dělal nějaké svoje hobbyprojekty a po nocích si to kodil, tak dneska to máš prostě za pár dní vystřelené, můžeš vyzkoušet, jestli to funguje, nefunguje. To je prostě jako poží. Tak já bych to zakončil takhle pozitivně. Jo,

Jindřich: je to tak. Každopádně ještě s tím připraveným a cílem vědomým, kdo se chce sdělávat a kdo chce tyto informace hledat a ty technologie využívat. Ale možnosti, jaký máme, jsou fajn. Díky moc. Vidíme se jak s tebou, tak s posluchačem u příští epizody. Díky a

Filip: budu se těšit na další témata. Díky, čau. Díky, čau, čau.