Vibe coding není softwarový vývoj. Je to jen začátek jedné dlouhé škály

Krásný den, vítejte u dalšího dílu podcastu Coffee Break s Filipem. Doufám, že pijete taky něco dobrého, tady mám opět tematicky kávu. A dneska bych se s váma rád zamyslel nad tím, co je to vlastně wipecoding, nad tou definicí toho termínu a jak se liší od AI-asistovaného programování, agentic engineeringu a podobných pojmů. Zkrátka, rád bych tak nějak jednou pro vždy vlastně jako rozdělil tady ty dva světy, protože dneska, když se často mluví o wipecodingu, tak si spousta lidí představí, že přesně takhle nějak jako probíhá ten vývoj toho softwaru a já si myslím, že zatím, neříkám, že za dva roky to nemůže být jinak, ale zatím tyhle ty dva světy jsou jako velice oddělený a když vývojáři a softwarový firmy mluví o tom, že používají AI ve vývoji, tak používají.

Prvky toho vapecodingu vypadá to podobně, ale ten přístup je za mě jako stále diametrálně odlišný. A na to bych se rád dneska podíval. Začnu tím, co je to vlastně wipecoding. Tady ten pojem definoval Andrej Karpaty, což je jeden z předních AI výzkumníků, který byl vlastně hlavní AI výzkumník v Tesla a stojí, nebo byl jeden ze zakládajících členů OpenAI.

A zkrátka na tom poli AI je jako velice uznávaná autorita. A on před rokem a něco, někdy v únoru roku 2025, tak tweetnul na Twitter, nebo teď na Xco, příspěvek, kde říká, že vibecoding je novej styl programování, kdy se člověk ponoří do toho vibe, toho jazykovýho modelu a vlastně úplně zapomene na to, že kód existuje. Jakoby zapomněl, že ten kód existoval. A to je za mě ta definice, která k tomu webcodingu sedí.

Zkrátka, vy vůbec nepřemýšlíte nad tím, že existuje něco jako nějaký kód, že na pozadí té aplikace běží nějaký programovací, nebo je na programu a programovacím jazykem, že tam běží nějaký zdrojový kód a jenom tomu jazykovému modelu člověk říká, co chce, aby udělal, on tu aplikaci vytvoří, spustí, když je tam chyba, řeknu mu, hele, oprav to a takhle to jako funguje. Ten wipecoding tak v dnešní době je jako extrémně populární, ale často když čeká články o tom, jak se mění softwarový vývoj, tak ten wipecoding je, řekněme, na té škále úplně na začátku. Já totiž rád rozděluji tady ty dva pojmy na takovou škálu, kde vlastně Vlevo, řekněme, máme pojem wipecoding a vpravo opět si vypůjčím pojem od Andreje Karpateho, agentic engineering. Já tomu v nějakých svých videích říkám AI-asistovaný programování, což už v době AI agentů nezní tak dobře, takže pojďme používat ten termín agentic engineering.

tak já to vnímám vlastně jako takovou škálu. Kdy jako wipecoding je vůbec mě nezajímá kód, prostě něco si zkouším, dělám apky a tvořím software, ale neřeším, že zatím je nějaká technologie. Ale úplně vpravo ten agenting engineering je, že já mám pořád plnou kontrolu nad tím kódem, vím, jak ten kód vypadá, jak funguje, jaký technologie tam jsou a jenom vlastně nechávám umělové inteligenci, ty AI agenty, aby vlastně ten kód tvořili za mě. A podle mě se to dá jako velice krásně vysvětlit na této škále.

Ten vapecoding, když člověk začíná a nechá si něco udělat zčet GPT, nějakou jednoduchou webovku hru, tak je jako úplně na začátku tady té škály. Potom použije nějaké pokročilejší nástroje, jako je Makali, Loveable nebo podobné, tak se trošku posouvá dál na té škále vlastně toho vapecodingu. Ve chvíli, kdy člověk začne tvořit nějaký plán, začne nad tím víc přemejšlet nad tím softwarem, že už to není jenom chci vytvořit aplikaci a dělá tohle a hotovo, ale začne si tvořit nějaký větší plán, já ve videích mluvím často o PRD, product, requirement, document, a zkrátka jako tvoří si nějaký větší plán, tak v tu chvíli už se zase na té škále posouvám trošku víc od toho wipecodingu. Pořád si troufnu tvrdit, že jsem extrémně na začátku v té škále wipecoding, agenting, engineering, ale už se to blíží, už se víc přibližujete té technologii jako takový.

Potom často lidi začínají řešit třeba, v jakých technologiích to bude postavené. Chtějí, aby to běželo třeba jako desktopová appka na všech platformách nebo na webu a už začínají přemýšlet nad těma technologiem a to znamená, že už se to láme z toho, z té hlavní definice toho wipecodingu, kdy vlastně by mě kohot nezajímal, Do toho už si uvědomu, že je tam nějaký kód, je tam nějaká komplexita, a řeším ten kód z nějakého pohledu, aby mě to běželo třeba na všech těch zařízeních atd. Takže zase posouvám se na té škále. Potom přicházejí další věci.

Potřebuji tu aplikaci hostovat, potřebuji mít databázy, potřebuji mít doménu a další věci. A zase se na té škále posouvám dál od toho wipecodingu víc k tomu agentic engineeringu, kde si začínám uvědomovat to, Tvorba softwareu je skládání jako více kostiček dohromady, že to není jenom o tom kódu, jenom o tom programu jako takovým. Tak. A tady už podle mě se začíná lámat ta hranice, kdy vlastně jako webcoding, kdy tohle bych ještě pořád považoval jako ve škatulce webcodingu, protože to jsou za mě schopný dělat i jako netechnický lidi, který nikdy jako neprogramovali a jsou schopný tady to vlastně jako vytvořit.

No a když se to za mě začíná lámat, tak je ve chvíli, kdy začínám řešit to, jak ten kod vypadá a jakou má architekturu. To znamená, začínám řešit, jestli ten kód, co mi ten AI agent píše, je škálovatelný. To znamená, jestli je napsaný dobře, jestli je napsaný použitelně. Zkrátka, jestli s tím kódem můžu dál pracovat a už plně si uvědomuju ten kód, plně se zaměřuju na ten programovací jazyk jako takovej.

Tady už si troufnu tvrdit, že už to jako vyžaduje ten technický skill a už se dostáváme pryč z toho wipecodingu a neříkal bych tomu wipecoding, protože už se prostě jako dostáváme do toho kódu a je potřeba ta technická znalost a tady už mi začíná na té škále se to překlápět vlastně k tomu pojmu agentic engineering. Začínám řešit teda tu architekturu. Potom, když to vztáhnu do té praxe, pro vás, který nejste jako technický, tak já si to pokusím vysvětlit ty procesy, jak to funguje v tom softwarovém vývoji, v tom profesionálním dneska, abyste si udělali jako kompletní obrázek, když pak někdo mluví o tom, že se používá AI jako v profesionálním vývoji, tak jak to vypadá. Ten základ, funguje to vlastně stejně.

Je to ten wipecoding, jenom se k tomu teďka přidává ještě ta architektura, pak se přidávají další kroky. To znamená, když to ten developer tvoří, tak třeba já jak k tomu přistupuji, že nechám AI agenta vytvořit ten kód, zdebagovat, to znamená najít tu chybu, vytvořit tu funkci pomocí nějakých dalších nástrojů. , ale to je jako vedlejší. a nechám toho agenta systavit ten kód, ale co já pak dělám je, že já ten kód kontrolu.

Já ho čtu, koukám se, jak to ten agent udělal a případně buď to ten kód přímo opravím, nebo toho agenta instruu, jak to má udělat. Ten důvod, proč to dělám takhle, je ten, že já potřebuji pořád zaručit tu kvalitu toho kódu, který já doručím, ale zároveň si potřebuji ušetřit ten čas. To je ten důvod, proč nechávám to dělat toho AI agenta a nepíšu to celý ručně. Pak se posouváme dál v tom procesu softwareového vývoje, kdy my potřebujeme dělat takzvaný code reviews.

To je proces, kdy člověk něco naprogramuje a teď sám se na to podíval, sám zhodnotil, jak to vypadá, ale je ještě fajn, aby nějakej jiný kolega zkontroloval ten kód po něm, co udělal, a ten cíl je eliminovat potenciální chyby, nehezký kody, to, že člověk něco přehlednul a tak dál. Tady se dá zapojovat opět AI, opět AI agenti, kdy vy vlastně pošlete ten kód na tu kontrolu a nejenom, že to kontroluje ten lidský kolega, ale ještě předtím to zkontroluje AI agent a připraví tomu lidskému kolegovi nějaký feedback. Takže typicky ta smyčka může vypadat tak, že já zadám AI agentovi práci, on udělá, já ji po něm zkontroluji, Tudle tu práci pak zkontrolovanou, opravenou dám na to Code Review, to znamená na tu kontrolu. Tam se spustí delší AI agent, jiný, nezávislej, který provede tu kontrolu, dá mi zpětnou vazbu.

Já tu kontrolu můžu zapracovat, nebo to tam nechám, to záleží, jak je to v té firmě nastavené. A pak přijde vlastně ten kolega, který to má kontrolovat a on vidí ten můj kód, co já jsem udělal, zkontroloval potom mým AI agentovi, vidí tam výstup z té analýzy toho kódu od toho vlastně jako kontrolovacího AI agenta. a dodělá to finální review. To znamená, dá si to dohromady, dodělá tam nějaké poznámky, já je zapracuji a pak se to kolečko točí a je výsledný produkt.

Tady už se dostáváme víc na tu škálu toho agentic engineeringu. To znamená, že už opravdu to je klasický programátorskej proces, který jenom dostává to AI do toho workflow, aby ho zefektivnil. Samozřejmě Tohle je jenom začátek toho, jak vypadá AI v tom profesionálním softwarovém vývoji. Když to posuneme zase trošku dál, tak on i ten pojem agentic engineering, který říká, že inženírujeme, spravujeme agenty.

Takže když to posunu dál, tak my můžeme nechat ty agenty být proaktivní. To znamená typické dvě věci. Ta proaktivita už se ukázala v Code Reviews, v kontrole, že automaticky ten agent to zkontroloval. ale my to můžeme napojit i na další systémy, to znamená, máme uživatelskou podporu a ta typicky, když přijde nějaký uživatel s nějakou chybou, tak zakládá tzv.

Ticket. To je prostě tudučko, kartička, která popisuje tu chybu a zadává jí na vývoj, aby ji opravil. No a my už tady zase opět můžeme nasadit AI agenta, který udělá nějakou triáž, to znamená, on se podívá, jaký to issue je, jak je závažný, jestli má všechny podklady, aby to nasimuloval, protože někdy zase ty chyby jsou popsané moc obecně, to znamená, že ten agent je schopný toto odhalit a vrátit to třeba na tu podporu, aby doplnili nějaké údaje. udělá tady tu triáž.

To je základní věc. A pak můžeme to zase rozšířit o kousek dál, kdy si to vezme nějakej další programovací agent, který tady tu kartičku vezme, spustí si nějaký virtuální prostředí, ve kterém si spustí Cloud Code a probíhá to vlastně úplně stejně, jako kdybych já přišel, vzal popis toho issue, dal to do AI agenta a řekl mu, hej, prosím, zkus najít chybu a opravit jí, tak jenom se tohle stane automaticky někde na servru a on pak vytvoří to ten pull request, to je to code review. To je vlastně ta část, když jsem něco udělal s agentem, nechával jsem to kontrola kolegu, tak tady to jenom jako vyřadí mě z toho procesu a ten AI agent udělá rovnou ten návrh té změny a já už pak jenom jako ten VUEF přijdu, podívám se, jestli to je korektní, jestli to opravdu opravuje tu chybu, jestli tam není nějaká jiná chyba zanesená atd. A pokud ano, tak to nasadím, prostě je hotovo, pokud ne, tak já si to vezmu k sobě, dodělám a vlastně jako můžu to zase Typicky, když tam něco dodělám, tak to dávám na Code Review zase na kolegu.

A ten důvod, proč se tohle dělá, tak je, že vlastně jako ubíráte ty friction, tomu jako problému, kdy když je nějaký jako backlog, to je vlastně jako soubor těch kartíček, těch zadání, těch tudůček, ať už z provozu nebo jiných, tak jako prohrabat se tím a každý jako developer vám řekne, že tohle ho fakt nebaví, takže vy necháte tu AI předchroustat tady ty věci, připravíte a vy už jenom přijdete a řeknete fajn, tohle vypadá dobře, tohle taky, taky, ne, ne, ne a máte odbavený nohem rychlejc. Takže tohle je vlastně jako delší ten step. A dá se to posouvat dál. Může se to napojit na různé chybové hlášení.

Nemusí to hlásit jenom podpora, ale jsou různé nástroje, které zachytávají chyby v tom softwaru, takže na to se dají napojit AI agenti. Můžou se napojit i na produktové tikety, když se zadá nějaká změna větší, takže se to zanalizuje ten agent a dá se tady to kompletovat. Potom ten agenting engineering se posouvá jako dále. Tohle byla nějaká formaty automatizace, ale pořád tam máme toho jednoho agenta.

A teď jako nástroje, jako třeba klotko, tak přidávají takzvaný agent teams. To znamená, že vy můžete nechat spustit tým agentů, který, každej ten agent je vlastně jako specializovaný na něco jinýho. Ten důvod je jednoduchý. Za první můžete ty agenty specializovat, můžete jim nastavit to chování přesně pro tu doménu, ve které oni mají fungovat.

To je to důležitý, protože blbě se nastavuje jeden velkej globální agent. A druhá věc je, že mají vlastní kontext. To znamená, že ve chvíli, kdy vy vlastně jako zadáte nějaký velkej úkol, tak když ho rozdrobíte mezi malý podagenty, nebo ten agentní tým, tak oni jsou schopný vlastně jako mít vlastní kontext a nezaplevelovat si to kontextové okno, ty instrukce, to zadání, vlastně jako s jinýma nerelevantníma věcmi, protože Byť máme jako modely, který mají obrovský kontextový okná, dvěstě tisíc tokenů, milion tokenů, teďka se mluví o dvou milionovém UGPT čtyřsi, pět, pětky nebo něco takovýho. teda pardon, pětečka pětky nebo něco takového, mluví se zkrátka o dvou milionovým okně, tak jsou studie, které ukazují, že ta efektivita těch modelů a agentů roste čím více kontextu, ale ve chvíli, kdy se to kontextové okno třeba z třetiny, z poloviny zaplní, tak ta efektivita pak zase a přesnost jde extrémně dolů.

Pravidlo toho context engineeringu je, chcete co nejrelevantnější kontext, co nejvíc toho nejrelevantnějšího kontextu a musí být relevantní. Nemůže to být balast mimo, protože tím ten model vlastně jako směřujete trošku mimo. Takže to je ten context engineering kolem toho a vlastně nějaká orchestrace těchto agent teams. Delší výhoda tady těch podagentů, nebo oni to nejsou subagenti, já nechci, aby se to pletlo, subagenti byli v cloud kodu předtím, teďka tam jsou agent teams, A další obrovská výhoda je, že tyhle agenti v těch týmech spolu umějí komunikovat.

To znamená, že oni si můžou zadávat úkoly, které jsou navzájem blokované, můžou si předávat informace, že čekají, než jeden agent něco dokončí, aby mohli pokračovat celý ten tým dál. A zkrátka jsou schopní si mezi sebou povídat a mají nějakého řídícího agenta, toho týmlídra. A zároveň v těch agentech můžete použít různé modely. To je taky důležité, protože O tom agetic engineeringu není to jenom o tom, že to orchestrujete, ale je to i o té ceně.

, tak to bude extrémně nákladný provozovat. , Haiku atd. Nebo prostě úplně jiný modely. To nemusí být jenom Já teď používám hodně příklad z Cloud Codu, protože s ním pracuji denně, ale ten princip obecnej platí v Open Code, platí v Cursoru, Antigravity, všude možný.

To máme agent teams. To je ta orchestrace agentů na základě nějakého úkolu. Když zpracováváme jeden úkol, tak se vytvoří ten tým agentů na ten daný úkol. Potom je další level.

Zase se dostáváme na tu samotnou hranu toho agentic engineeringu, co se dneska řeší, tak to je orchestrace více těch sessions dohromady. To znamená, abych já měl nějaký přehled o tom, kde ty agenti běží, kolik času na tom strávili, na čem pracují a obecně orchestrace více agentních týmů dohromady. A to je teďka úplně nejvíc cutting-edge věc, která se řeší. To znamená to nejzajímavější.

A tam už vůbec, troufnu se tvrdit, nejde o wipecoding atd. A to je prostě takový nový DevOps, protože dřív vysvětlím DevOps, když jste spustili nějakou aplikaci velkou webovou, tak jste museli zprávovat, kde poběží na serveru, kde budete mít databázy a teď, když se tam připoje hodně lidí, tak ty servery chcete mít různě po světě, nebo mít nějaké cashování. Spousta věcí pro netechnický lidi. Zkrátka, nasadit webovou aplikaci pro milion lidí je mnohem větší oříšek, než jenom ten kód, který ji pohání.

Celá ta infrastruktura okolo toho. A úplně stejně mi to teď přijde s těma agentama, s tím AI, kdy my už jsme na dobrý úrovni, kdy ty agenti dokážou produkovat dobrý kód, Ale teď už je to jako o tom, jak ty agenty, ideálně jim dostat co nejlepší kontext, pospojovat je dohromady a pomalu vyštípat toho člověka jako z toho procesu, teď to znamená vlastně jako negativně vyštípat, ale jako dostat toho člověka z toho procesu co nejvíc pryč, protože často ten bottleneck, ta brzda je právě ten člověk a nechat ty agenty pracovat a toho člověka tam jako přizývat jenom v případech, kdy je potřeba, udělat nějakou kontrolu nebo supervizi. A zároveň ale poskytnout těm lidem, aby to nebyl black box, že tady je prostě nějaký počítač a tam si AI agenti běží a dělají si, co chtějí a my nevíme, co, tak aby byly nějaké dashboardy, nějaké kontrolní panely, kde my vizuálně vidíme, co se děje, kdo na čem pracuje, kolik to stálo. Prostě mohli jsme to řídit.

Stejně jako projektoví manažeři, tak dneska mají prostě různý nástroje, aby řídili lidský týmy, tak my potřebujeme podobné nástroje, abychom řídili tyhle agentní týmy. To je takový zajímavý... Přístup, nebo jako zajímavá věc, podle mě, na diskuzi. Doufám, že to dalo nějak smysl, kde je vlastně ten webcoding a že opravdu ta jako tvorba těch aplikací jednoduchých, kdy si vytvoříte nějakou jednoduchou webovou apku nebo něco takového, nějaký web, tak jako fakt malenkej začátek tady, ale celá ta škála toho AI v tom softwarovém vývoji je jako neuvěřitelně široká a řeší se tam fakt jako strašně zajímavý problémy.

Takže to je podle mě důležité ilustrovat. Co to znamená pro tu budoucnost? Já si myslím, že ta hranice toho vapecodingu tady se bude i nadále posovat. To znamená, že ta vstupní bariéra do nějaký architektury a nějaký kontroly kódu se bude víc a víc zpřístupňovat i méně technických lidem.

To znamená, že víc a víc bude demokratizace toho vývoje. Zároveň si ale myslím, že ještě extrémně dlouhou dobu potrvá, se stane to, že bysme mohli říkat celýmu tady tomu procesu jako wipecoding a že vy jenom agentovi řeknete, já bych chtěl tady tu aplikaci, co umí XYZ pro milion lidí, udělej od A do Z. To si myslím, že jsme jako extrémně daleko. Třeba se mýlim, ale fakt si myslím, že jsme jako fakt ještě jako hodně daleko a byť jako různý AI agenti jako OpenCLO a podobný, tak jako vytvářejí tu iluzi, Toho, že je vlastně jako všechno možný, tak je nutný říct, že jsou extrémně chybový.

Je to takový prototyp a mají skvělej wow efekt, ale mají spoustu ostrej hran, o který se dá fakt pořezat. Takže myslím si, že následující roky budou ve znamení. Jasně, budou se zlepšovat AI modely, budou se zlepšovat ty scaffoldingy kolem nich, to určitě, ale čem si myslím, že to bude kritický, tak bude právě tady ta orchestrace a to vlastně jako vokolo. Tak co to znamená pro nějaký juniori, nebo pro lidi, co do toho odvěd výjdou?

Myslím si, že to bude zároveň obrovský benefit, že najednou člověk může tvořit víc, ale zároveň to je výzva se do toho dostat, protože i pro mě samotného, byť jsem v AI každej den, jsem každej den v softwarovém vývoji pořád a oba tyhle světy mám jak z té hobby, tak i z té profesní stránky a věnuji jim enormní množství času, tak stejně takhle nestíhám všechno zkoušet. Jako držet ten krok s tím vývojem, jak se nesložítej, open claw, tak konečně ho mám rozjetý na Macu, konečně ho používám, strávám se na něm dva víkendy celý. Plus nějaký dny během týdne. Teďka zase řeším víc tu orchestraci, jakým způsobem líp orchestrovat agenty na svým Macu, ty programovací agenty, zadávat jim úkole, abych byl efektivní.

Opět, enormní množství času. Tak držet tady ten krok s tím, si myslím, že je extrémně složitý. A paradoxně, byť AI snižuje tu vstupní bariéru do toho vývoje, tak ji podle mě ale snižuje na tom začátku, toho webcodingu. Ale u orchestrace si myslím, že ta vstupní bariéra je pořád poměrně velká, protože to vyžaduje i ten software engineering a to myšlení zatím, nebo to je to znalost těch technologií.

Pro seniory tak si myslím, že to je vlastně obrovská příležitost, kdy programátoři musí přesedlat na to, že jsme teď pasáci AI agentů. To znamená, že musíme zadávat tu práci, musíme s nimi pracovat. A tohle je ten směr, byť se nám to líbí nebo ne. A spoustu znám vývojářů, kterým se to nelíbí, protože rádi píšou ten kod, mají rádi to řešení těch dělčích malých problémů, ale já jsem přesvědčený, že tato doba už je Pro někoho bohužel, pro lidi jako já třeba bohu dík, protože já jsem spíš ten produktový člověk za náma.

A prostě tyhle dílčí části, ať chceme nebo ne, tak bude dělat AI. ten softwareový vývoj k tomu tíhne. Já si nemyslím, že to znamená, a teď to je taková mesič, hlavně pro vás třeba netechnicí, který máte firmy a máte tam jako developery nebo přijímící, jestli je budete potřebovat. Pokud nejste vyloženě softwareová firma, tak nutně toho developera třeba nemusíte potřebovat a spoustu interních nástrojů si spíchnete sami.

Jenom prosím, nedabívejte dojmu toho, že se vytvořím úplně všechno a nemusím za ně splatit. Na to si uděláme nějaký jiný podcast, kde se povíme o tom, že wipecoding může být i taková jako slepá ulička trošku. A zároveň ale, pokud ty vývojáře máte a děláte nějaký softwareový produkt, tak je pravděpodobně, podle mě, budete pořád potřebovat, jenom budete potřebovat ty správný vývojáře, který mají ten AI mindset a vlastně jsou ochotný z toho psaní kódu přesedlávat na tady ten jako vyšší stupeň, vyšší stupeň, vyšší stupeň abstrakce, chci říct, jako orchestrace těch agentů. Pro firmy to je vlastně jako to samé, že ta message, jako stejně jako pro ty foundry, prostě tohle je ten směr Já to osobně třeba ze svýho pohledu teďka vnímám tak, že jako věnuju tomu enormní množství času a vlastně ve výsledku mě to třeba, byť jako na tom klasickým vývoji, jo, ale někdy třeba neušetří tolik času, protože to musím proskoumat, tak ale Zároveň vlastně je to ten směr, protože ty nástroje se budou vyvíjet a ta hranice se pořád posouvá a je dobrý s tím držet krok, pokud si to chcete dělat sami, a nebo pokud teda nechcete držet krok, což chápu, protože je to extrémně náročné časové, tak pak jsou fajn různý konzultace nebo lidi, kteří vám to jako pomůžou nasadit.

Já třeba teď se tady do toho segmentu taky posouvám a radím jako jednotlivcům a firmám, jak tady to začít a jak s tím jako pracovat nejenom ve wipecodingu, ale obecně AI agenti a AIčko, ale jako spousta dalších jako konzultatů a firm, který se tím jako zabývají. A to si myslím, že jako pro firmy bude extrémně důležité, protože Zcela upřímně, ten čas, který člověk to musí věnovat, aby si s tím pohrál, vyskoušel, tak je šílený. Ale je to zábava, takže pokud vás to baví a chcete se tomu víc do detailu porozumět, jenom to nasadit, tak mega doporučuji jít tou cestou, že si tu cestičku vyšlepete sami, protože je to zajímavý, je to zábava a naučí vás to strašně moc. To bylo k tomuhle dílu všechno.

Doufám, že to splnilo účel. Chtěl jsem dvě zásadní věci. Definovat wipecoding, agentic engineering, že je to nějaká škála, na který se posouváme. A zároveň tak nějak objasnit to, že když se mluví o vývoji softwaru a AI, tak to není ten wipecoding, jaký si spousta netechnických lidí představí, že jenom říkám AI něco dělá, nezajímá mě kod.

A ono se to prostě děje. To je fakt jen malý začátek, který je dobrý na malé weby, malé aplikace. ale není škálovatelný velký software. Vlastně možná poslední message pro různý foundery, který si nechávají vyvíjet software na míru.

Ano, AI zefektivňuje vývoj, ale nejsme v té fázi, kdy můžete nemít programátory nebo místo deseti mít jednoho a on to zvládne. Pořád ten efektivity boost je obrovský na začátku pro malé věci, pro malé weby, malé interní následky, to je neuvěřitelné. Tam ten efektivity boost jsou tisíce procent, si to doufnu tvrdit. Ale čím větší je ten software, tak ten effectivity boost prostě klesá a jsou to pak třeba desítky procent toho effectivity boostu.

Čistě jako hrubě, nemám to spočítané, ale čistě jako pocitově. Takže to je takové finální sdělení. Doufám, že jste si užili dnešní podcast a pochutnali si na kávěk, čaj nebo cokoliv, co pijete. Budu se na vás těšit, buď to, nebo takhle, ještě dejte mi vědět do komentáře, kde vy se třeba na té škále nacházíte, jak to vnímáte, jak k tomu přistupujete.

No a budu se na vás těšit, buď to na kanále AI s rozumem na YouTube u dalšího videa, nebo u dalšího dílu podcastu Coffee Break s Filipem, no a nebo u nás v Discord komunitě, Discord komunita AI s rozumem, kde zase jako diskutujeme podobný věci, můžete se tam na cokoliv zeptat a je to prostě zcela zdarma komunita a zároveň tam postojí různý, jak už obecný AI novinky, tak i technický novinky tady toho rázu, různý orchestrce a další věci, o kterých se tady bavíme. To je ode mě pro dnešek všechno, díky moc, že jste poslouchali, nebo jste se dívali. Budu se na vás těšit u dalšího videa, nebo u dalšího dílu podcastu. Mějte se krásně, užijte si, sluný dny začíná nám jaro, tak běžte se trošku provětrat.

Ahoj.