Vzhůru dolů

Odkládání JavaScriptu není optimalizace, ale přesouvání problému

Mon, 21 Sep 2026 00:00:00 GMT

Tohle mě štve. Velké množství dnešních „zrychlovacích“ pluginů má jedno zatržítko, které umí zvednout Lighthouse skóre mrknutím oka.

Odloží totiž spuštění veškerého JavaScriptu až na první interakci uživatele, tedy na scroll, kliknutí nebo dotek.

Tohle je špatně.

Jenže na reálnou rychlost u reálných uživatelů to vliv nemá. Naopak to může rychlost zhoršit nebo poškodit analytiku.

Je to takový malý podvůdek, který celý obor pořád tiše akceptuje.

Tohle je rozšířená verze části článku Falešně rychlé weby: jak se hackuje Lighthouse skóre, který jsem vydal na blogu PageSpeed.ONE. Tady se dívám jen na tuhle jednu techniku a hlavně na konkrétní pluginy, které ji prodávají.

Odkládání všech JS zní jako fikaný tah, tak proč jsme v PageSpeed.ONE zoptimalizovali stovky webů a tuhle techniku jsme klientům nikdy nedoporučili?

Proč je odložení JS špatně, ale na Lighthouse funguje tak spolehlivě?

Lighthouse stránku načte a změří. Nescrolluje, nekliká, obrazovky se nedotkne.

Odložený JavaScript tedy v testu nikdy neproběhne. Z měření tím zmizí Total Blocking Time, tedy metrika s největší váhou v Lighthouse skóre, celých třicet procent. Zlepší se také rychlost načtení (LCP), protože prohlížeč nemá co spouštět.

Skóre vyskočí nahoru, přitom se web nezrychlil. JavaScripty se přesunuly na později, často do nejhoršího možného momentu.

Ilustrace odložení JavaScriptu. Skripty se načtou až po uživatelské interakci. Je to zlo.

V tomhle názoru nejsem sám. Barry Pollard, který se rychlosti webu věnuje v Googlu, tenhle vzorec pojmenoval už dříve:

„A common pattern I see is to delay ALL JS until the user interacts with a page: Great for Lighthouse scores! Often terrible for users.“

– Barry Pollard, Google Chrome

Proč je vlastně odložení všech JS špatné?

Čtyři rizika odložení všech JavaScriptů

Negativní vliv na interakce (INP). Uživatel dorazí na stránku, přečte si nadpis a klikne. V tu chvíli se spustí všechen odložený JavaScript, který se do té doby hromadil. Hlavní vlákno prohlížeče se zablokuje a první kliknutí uživatele čeká.
Negativní vliv na posuny layoutu (CLS). Skripty, které dorenderovávají obsah, tedy karusely nebo personalizace, se spustí pozdě. V Lighthouse testu se přitom žádný posun nezměří, protože se ten kód nikdy nespustil. Skutečnou hodnotu CLS tak nevidíte ani vy.
Funkčnost měření. Analytika, souhlas s cookies, chat, A/B testy a měření konverzí se odkládají spolu se vším ostatním. Data vám pak nemusí sedět a nikdo neví proč.
Znehodnocení Lighthouse skóre. Lighthouse skóre sice není metrika rychlosti webu, ale pro diagnostiku změn je užitečné. Tím, že v něm není žádný JavaScript, měříte úplně něco jiného než svůj web.

U prvního bodu buďme přesní. Veřejná studie z reálného provozu, která by zhoršení INP po zapnutí téhle funkce změřila, neexistuje. Máme mechanismus, popsaný lidmi z Googlu, a přiznání od WP Rocket, že se INP v jejich vlastním testu nezlepšilo. To je silná indicie, ne změřený dopad.

Pojďme nebýt slušní a jmenovat konkrétní hříšníky.

Hříšníci. Které pluginy tohle nabízejí?

Prošli jsme nejznámější optimalizační pluginy pro WordPress a takzvané one-click optimalizátory. U každého jsme hledali tři věci: jak se nastavení jmenuje, jestli je zapnuté ve výchozím stavu a jestli dokumentace zmiňuje rizika.

Plugin	Nastavení	Výchozí stav	Varuje?
WP Rocket	Delay JavaScript Execution	vypnuto	ne
LiteSpeed Cache	Load JS Deferred → Delayed	vypnuto	ano
WP-Optimize	Delay JS	vypnuto	částečně
Perfmatters	Delay all scripts	vypnuto	ne
NitroPack	Delay non-critical resources	zapnuto v Ludicrous	částečně
WP Meteor	Infinite Delay	vypnuto	ano
Autoptimize Pro	Delay JavaScript (timeout 0)	vypnuto	ano
SpeedyCache	Delay All	vypnuto	ano

Poslední sloupec potřebuje vysvětlení. „Částečně“ znamená, že dokumentace varuje jen před tím, že se vám může rozbít web, ale o dopadu na Lighthouse skóre a na uživatele nepíše nic.

Jediný plugin, SpeedyCache, upozorňuje i na to, že se vám rozbije analytika.

Dva řádky si pak zaslouží komentář.

LiteSpeed Cache má dvě cesty ke stejnému výsledku. Přímá je Load JS Deferred nastavené na Delayed: skripty počkají na interakci, ve výchozím stavu je to vypnuté a dokumentace na rizika upozorňuje. Druhá je Guest Optimization — balík maximálních optimalizací pro první návštěvu a boty. Guest Mode, bez kterého Guest Optimization nic nedělá, startuje vypnutý, takže čerstvá instalace tuhle techniku sama nepouští. Jakmile ale Guest Mode zapnete (nebo vám ho zapne hostingový preset), Guest Optimization umí tiše vynutit režim Delayed, i když máte Load JS Deferred na OFF. Autor hlášení tvrdí, že na Hostingeru je to výchozí; Hostinger to ve své dokumentaci nepotvrzuje, takže to berte jako signál, ne jako fakt.

WP Rocket změnil pravidla hry ve verzi 3.9. Do té doby jste museli vyjmenovat skripty, které se mají odložit. Od 3.9 se odloží všechny a vy máte vyjmenovat výjimky. Pro nové uživatele zůstává seznam výjimek prázdný, takže jakmile funkci zapnete, odkládá se úplně vše. Buďme fér: riziko zhoršení INP WP Rocket zmiňuje, ale na jiné, mnohem méně navštěvované stránce nápovědy. Na stránce samotné funkce o něm není ani slovo.

Dobrým ukazatelem poctivosti je timeout. Pluginy, které vynucují časový limit, skript nakonec spustí i bez interakce, takže ho Lighthouse uvidí. Produkty, které timeout nemají nebo dovolí nastavit nulu, čekají na interakci navždy. A přesně to trošku zapáchá optimalizací jen pro test.

Výrobci to vědí. Někteří to i napsali

Nemusíme spekulovat o tom, jestli výrobci vědí, co jejich funkce dělá s testy rychlosti. Někteří to mají černé na bílém ve vlastní dokumentaci.

WP Rocket při vydání verze 3.9 napsal:

„This means the JavaScript files won't be detected by Lighthouse… Is that cheating? Not really if you consider the following points…“

– Blog WP Rocket

LiteSpeed jde ve své dokumentaci ještě dál a přiznává i to, že funkce zamaskuje skutečné problémy webu:

„This setting can greatly improve page speed scores… Additionally, Guest Optimization can 'mask' any real problems your site may have.“

– Dokumentace LiteSpeed Cache

A Frank Goossens, autor pluginu Autoptimize, napsal o možnosti nastavit timeout na nulu tohle:

„Setting the delay to 0 is a bit shady because at that point you are hiding those assets for performance tests.“

– Frank Goossens

Za zmínku stojí i čísla, která WP Rocket zveřejnil při vydání verze 3.7. Na vlastním webu s touhle funkcí vykázal posun mobilního skóre ze 46 na 86 bodů. Zároveň ve svém vlastním testu k metrice INP uvádí, že se hodnota INP nezměnila.

WP Rocket píše jen o výhodách nastavení „Delay JS execution“, ale už nezmiňuje rizika.

Pozor, není každý hříšník, kdo jako hříšník vypadá

Slovo „delay“ se v pluginech používá dost volně a snadno se spálíte. Tyhle funkce odkládání na interakci nedělají, i když to tak podle názvu může vypadat:

Breeze od Cloudways má nastavení „Delay All JavaScript“, ale ve skutečnosti přidává atribut defer a načítá skripty jako moduly.
Jetpack Boost ve funkci „Defer Non-Essential JavaScript“ přesouvá značky <script> na konec dokumentu.
Speed Optimizer od SiteGroundu u „Defer Render-blocking JavaScript“ přidává obyčejný defer.
Rocket Loader od Cloudflare používá stejný trik s přepsáním atributu type, ale skripty vrací do hry po vykreslení stránky, ne až po interakci. Lighthouse je tedy spustí a změří.

Všechny čtyři mohou působit jiné problémy, třeba s pořadím načítání skriptů. Lighthouse skóre ale umělě nenadhodnocují.

Kdy je odkládání naopak v pořádku

Aby to bylo fér: odložit načtení kódu až na interakci uživatele je někdy úplně správné řešení. Rozdíl je v tom, jestli odkládáte jednu konkrétní komponentu, nebo všechno.

Typickým příkladem je takzvaný facade pattern. Místo vloženého videa z YouTube ukážete náhledový obrázek s tlačítkem a skutečný přehrávač načtete po kliknutí. Stejně se to dělá u chatovacích widgetů, map nebo komentářů. Víc o tom píšu v textech o třetích stranách a lazy loadingu.

Nejlépe je to vidět na tom, jak se k oběma technikám staví Lighthouse. Na facade pattern má samostatný audit, který ho doporučuje. Na plošné odložení veškerého JavaScriptu nemá vůbec nic.

Jak špatné odkládání JS poznáte na svém webu?

Pluginy po sobě v HTML nechávají celkem jasné stopy. Nejčastěji přepíšou atribut type u značky <script> na hodnotu, které prohlížeč nerozumí, a původní adresu skriptu schovají do vlastního atributu.

Co hledat ve zdrojovém kódu stránky:

type="text/rocketlazyloadscript" a data-rocket-src – WP Rocket
type="litespeed/javascript" – LiteSpeed Cache
type="pmdelayedscript" – Perfmatters
type="javascript/blocked" – WP Meteor
type="text/plain" s atributem data-src – WP-Optimize

Pokud nechcete číst kód, načtěte stránku s otevřeným panelem Network a nehýbejte myší. Pak myší hýbněte. Když se v tu chvíli spustí dávka požadavků na JavaScript, máte jasno.

A nakonec se vždycky podívejte na data od reálných uživatelů. Zelenější laboratorní skóre bez zlepšení uživatelských dat není výhra.

Jedno zatržítko nezastane inženýrskou práci

Rozhodnout, co se má načíst kdy a v jakém pořadí, je inženýrská práce, která vyžaduje znalost konkrétního webu.

Jedno zatržítko, které odloží veškerý JavaScript, tuhle práci nezastane.

Jak to vypadá, když se tímhle směrem vydá celý obor, popisujeme v článku Falešně rychlé weby: jak se hackuje Lighthouse skóre.

Najdete tam i naše pátrání kolem pluginu Website Speedy, u kterého jsme po vypnutí viděli propad skóre z 95 na 60 bodů, aniž by se u uživatelů změřila jakákoliv změna rychlosti.

Narazili jste na tohle zatržítko u klienta nebo ve svém webu? Jak jste to řešili? Napište mi nebo pojďme o tom diskutovat na sociálních sítích.

AI restart. Pět z otázek, které musí dořešit vývojářská komunita

Mon, 14 Sep 2026 00:00:00 GMT

Softwarová vývojařina prožívá krizi. Na jedné straně přinesl agentický vývoj ohromné zefektivnění a daleko zábavnější možnosti práce.

Na straně druhé vidíme úplně jiný přístup k vývoji, znásobení psychické zátěže a „vpád barbarů“, tedy nových, dříve vývojem nepolíbených lidí do vývojářských repozitářů.

No a taky tlak na pracovní místa, propouštění a úvahy o tom, zda vývojářská práce dává vůbec ještě smysl.

Je to mazec, vážení.

Když jsme začali připravovat program pro letošní FrontKon, přemýšleli jsme, jak to uchopit. Už není potřeba váhat, zda AI používat. Řešíme, jak ji používat.

Vím, že vývojáři budou psát stále méně kódu, jestli vůbec nějaký.

Ale za praktickými otázkami a přednáškami se táhnou ještě jiné, daleko znepokojivější a filozofičtější otázky.

Je jich opravdu hodně, ale ty nejdůležitější z nich se pokouším v tomhle článku pojmenovat. Pojďme o nich diskutovat.

1) Když AI píše většinu kódu, co znamená být vývojářem?

V průzkumu JetBrains Developer Ecosystem 2026 mezi více než 15 000 profesionálními vývojáři uvedla více než polovina lidí, že ručně píše méně než 20 % svého kódu. Každý pátý už nenapsal bez pomoci AI vůbec nic. To bylo v první polovině letošního roku.

JetBrains u svých dat schválně používá slovo „coders“. Měří totiž to, jak kód vzniká, nikoliv celý vývoj. Výsledek může navrhnout agent, ale někdo ještě musí vybrat problém, pochopit uživatele, rozhodnout o architektuře a dostat software bezpečně do provozu. Ať to nepadá a je to rychlé a bezpečné.

Z toho nám vyplývají následující otázky:

Když samotné psaní postupně mizí, podle čeho vlastně poznáme vývojáře?
Není čas přestat zaměňovat psaní kódu s tvorbou softwaru, když mluvíme o vývojářích?

Obrázek: Letos chceme v debatě o tom, jak AI mění práci vývojářů, pokračovat.

2) Musíme ještě číst veškerý kód? A co znamená, když jej číst nebudeme?

Průzkum Sonar State of Code 2026 došel k podobným závěrům jako ten předchozí. AI vytvořila nebo pomohla vytvořit 42 % commitovaného kódu. Zároveň ale 38 % respondentů uvedlo, že kontrola AI kódu vyžaduje více práce než kontrola kódu od kolegů.

Tak jasně, známe to všichni. AI-generovaný slop v pull requestech. Nová otravná povinná četba. Jenže… je to vlastně povinné?

Podle stejného průzkumu AI kódu plně nedůvěřuje 96 % vývojářů, jenže před commitem jej pokaždé ověřuje jen 48 %.

Kód vzniká rychleji, jenže lidská schopnost posoudit jeho správnost se nijak zásadně nezrychlila.

Addy Osmani to označuje jako comprehension debt (takže „dluh porozumění“). Jde o rozdíl mezi množstvím kódu v systému a tím, jaké části lidé skutečně rozumí.

V experimentu Anthropic dosáhli lidé používající AI podobné rychlosti jako kontrolní skupina, ale v testu porozumění získali 50 % místo 67 %.

Data Faros AI od 22 000 vývojářů ve 4 000 týmech podle Addyho Osmaniho ukazují, že s vysokým využitím AI vzrostla mediánová délka review o 441,5 %. Ano, zhruba pětkrát. Podíl PR sloučených bez kontroly přitom stoupl o 31,3 %. Ano, o třetinu. Taky vám proběhl takový lehký mrazíček po zádech?

Otázky zní:

Musíme stále kontrolovat každý řádek v pull requestech?
Můžeme si dovolit vznik funkčního softwaru, kterému nikdo nerozumí?
Co když kód neslučujeme bez review záměrně, ale prostě proto, že jej už nestíháme číst?
Co když nám AI neodstranila úzké místo vývoje, ale jen jej přesunula o jeden krok dál?

Obrázek: Tady na lidi žádný pull request od AI nečeká. Snad.

3) Stávají se z vývojářů manažeři agentů?

Addy Osmani píše, co všichni vidíme. Při práci s více LLM agenty už nejde o prompting. Jde o řízení malého týmu. Vývojář vysvětluje záměr, dodává kontext, rozděluje práci, nastavuje hranice a kontroluje výsledek.

Tvůrce Claude Code Boris Cherny spouští pět lokálních agentů a dalších pět až deset v prohlížeči. To bylo zkraje roku. Zeptejte se Borise, kolik agentů mu běží dneska.

Osmani ale zároveň doporučuje omezovat rozpracovanou práci, protože s každým agentem roste fronta výstupů, rozhodnutí a code review.

Znáte to? My vibekodéři jo. Šibe nám z toho.

Takže ty důležité z otázek zní:

Stává se tedy z každého vývojáře manažer agentů? Co to znamená pro lidi, kteří chtěli hlavně v klidu psát kód?
Je deset agentů desetinásobná produktivita, nebo jen deset nových míst, kam musíme přesouvat pozornost?

Obrázek: Řídit konferenci plnou lidí možná bude brzy jednodušší než uhlídat deset agentů.

4) Co AI dělá s učením a hlubokou prací?

Addy Osmani mluví o cognitive outsourcing (takže delegování myšlení) a cognitive surrender (takže rezignaci na myšlení).

Bláznivé, ale reálné. My všichni, kteří LLMka používáme, jsme na hraně propasti hloupnutí. Nechtějte vědět, co to dělá s dnešními teenagery. Mám je doma. Nechte si to vyprávět někde v temném koutě na FrontKonu.

Ale zpět k vývojářům. Ve třech experimentech s 1 372 účastníky lidé v 73 % případů přijali chybnou odpověď AI jako správnou, i když se model mýlil. Přítomnost AI v procesu uvažování přitom zvýšila jejich sebejistotu.

Experiment Anthropic sledoval 52 vývojářů, kteří se učili novou knihovnu. Největší propad u skupiny používající AI nastal v debuggingu, menší také v pochopení konceptů a čtení kódu. Hůře dopadli hlavně lidé, kteří AI pasivně delegovali práci. Lépe ti, kteří se ptali na principy a souvislosti. Byli šťouraví.

Otázky tedy zní:

Jak poznáme okamžik, kdy už neposuzujeme cizí odpověď, ale jen přebíráme její sebevědomí?
Kdy je AI učitel a kdy náhrada učení?
Blbneme?

Obrázek: Zatím není jisté, zda se publikum učí s AI, bez AI, nebo navzdory ní.

5) Změní se identita lidí, kteří dělají vývojáře?

Sám jsem aktivní vývojářskou kariéru ukončil už dávno. Dávno předtím, než mnozí ze čtenářek nebo čtenářů začali.

Dnes jsem webperf expert, produktový člověk, vedu týmy, dělám byznys. Přesto díky agentům znovu zasahuju přímo do kódu PageSpeed.ONE. Jako CEO, který bere práci vývojářům, někdy vytvořím hotovou fíčuru rychleji, než bych připravil zadání.

Osmani rozlišuje práci, kterou lze poslat agentům na pozadí, a práci vyžadující těsnou spolupráci člověka. Architektura, nejasné požadavky a produktové nuance podle něj stále potřebují zkušený úsudek. Zároveň ale někdo musí řídit celý proud agentní práce.

Známý vývojář, spolutvůrce frameworku Django a dlouholetý komentátor vývoje kolem AI, Simon Willison, ve svém článku o vibe-codingu a agentic engineeringu píše, že potřebné dovednosti nevypadají jako kurz promptování.

Však posuďte sami: plánování, testování, dokumentace, verzování, manuální QA, výzkum, odhadování a schopnost poznat, co lze bezpečně delegovat.

Nejsou to náhodou schopnosti zkušených vývojářů, tech leadů, prostě těch, co mají manažerské dovednosti?

Willison odděluje nezávazný vibe-coding od agentic engineeringu. U produkčního softwaru podle něj nestačí, že výsledek vypadá funkčně. Vývojář pořád odpovídá za bezpečnost, provoz, výkon a dopad na cizí data. AI zrychluje realizaci, ale tuto část práce za člověka nepřebírá.

Otázky zní:

Kdo všechno se dnes vlastně může stát vývojářem?
Co to udělá s lidmi, kteří si vývoj vybrali právě kvůli klidu, soustředění a jasně ohraničeným úkolům?
Budeme se ještě učit především syntaxi a frameworky, nebo spíš úsudek, komunikaci a práci s nejistotou?
Vznikne jedna nová role vývojáře, nebo se profese rozdělí na široké orchestrátory a hluboké technické specialisty?
Přijdou „vibe-barbaři“ a nahradí „vývojáře“?

Obrázek: Vývojáři? Manažeři agentů? Vibe-barbaři?

Tak.

Mohl bych pokračovat, trošku jsem se rozjel. Pardon, mám toho plnou hlavu.

Můj názor je, že vývojář jako role nezmizí. Docela jistě ale změní patro v procesu vývoje softwaru. Zcela určitě změní dovednosti. Možná do vývoje přijdou noví lidé a někteří z těch současných, kteří se jen hrabou v kódu, prostě budou muset odejít.

Vývojáři budou méně dělníci kódu, začnou držet více zodpovědnosti. Slovo „zodpovědnost“ je klíč. AIčko vám zodpovědnost nepřebere. Zodpovědnost za produkt, za web, za appku. Tu stále budou v lidských organizacích držet lidé.

Vývojařina nikdy takovou krizí neprocházela. Je to velké. Možná trochu děsivé, ale zároveň zajímavé a poskytující ohromné možnosti pro ty s hlavou otevřenou.

Pojďte o tom diskutovat na LinkedInu, na X nebo přímo na FrontKonu.

Když něco vedete, jste kapitán. Krátkozraký kapitán

Mon, 17 Aug 2026 00:00:00 GMT

Kapitánem je každý, kdo něco vede. Projekt, tým, produkt nebo firmu.

Roky se sžívám s vedením týmů. Pochopit tu roli, naučit se ji.

Byl jsem 25 let na volné noze, sám sobě pánem. Přechod do vedení je proto docela bolestivý. Ale zároveň je to velká zábava a příležitost hodně se toho naučit.

Pro nás samouky fungují při učení různé příměry. Ale občas si je musíme přiohnout.

Vezměme třeba kapitána lodi. Kapitán určuje, kam to celé pluje. Musí znát každého člena posádky, jeho klady a zápory. Sehnat na cestu prachy, cestou nějaké vydělat a nakonec skončit v plusu. Musí znát technický stav lodi. A tak dále… Nuda. Tohle pro vás nebude nic nového.

Kapitán se usilovně snaží celou tu věc pochopit. Jenže je krátkozraký.

Krátkozraký a dezorientovaný kapitán

Myslím, že zajímavější je dívat se na začínajícího kapitána jako na silně krátkozrakého a dezorientovaného.

Na začátku kapitán ani neví, že má loď. Jen ví, že něco řídí.

Následně pochopí, že řídí loď, ale neví, jakým způsobem ta loď vlastně pluje.

Kapitán zpočátku nevidí, že to modré kolem je moře. A to moře obsahuje nástrahy. Ale také místa, kudy loď propluje snadněji.

Časem toho kapitán spoustu vidí, ale nevidí, že loď obsahuje větší nebo i menší díry. Větší díry někdo vidí a řekne mu o nich, pokud to takhle kapitán nastavil.

Menší díry často nikdo nevidí a krátkozraký kapitán si je musí umět najít. Jinak mu jde loď pomalu ke dnu.

Může tohle kapitána někdo naučit?

Mohli bychom pokračovat. Aby kapitán mohl efektivně udávat směr, musí poznat to, co vlastně vede.

A teď to klíčové. Vše z uvedeného může kapitánovi někdo ukázat. Jiný kapitán nebo škola pro kapitány. Je ale otázka, jak moc toto vzdělávání funguje v situaci, kdy každá loď, každá posádka a každé moře fungují trochu jinak. Lepší je, když se kapitán rychle učí na základě toho, co se děje na jeho lodi.

Je to bolestivý proces. Ale věřím, že vede ke kapitánovi, který sice zůstává krátkozraký, ale zároveň zvědavý a obezřetný.

Baví mě učit se hledat díry, nezakopávat a nevypadnout z lodi.

Dovolená: průvodce pro workoholiky

Wed, 29 Jul 2026 00:00:00 GMT

Pracuju hodně a svoji práci mám rád. Vlastně ji docela miluju. Většinou. Myslím, že zhruba před dvaceti lety jsem o sobě mohl říkat, že jsem workoholik. Teď už jsem na workoholismus příliš starý.

Svou přehnanou lásku k práci jsem v čase cíleně krotil a ovládal, ale jednu věc jsem nikdy moc neuměl. Dovolenou.

Ne, že bych na dovolené nejezdil, ne že bych se na ně netěšil. Ale skloubit delší dovolené, obzvlášť ty rodinné, s prací, to byla pro mě vždycky jedna z největších výzev každého roku.

Nakonec jsem to dokázal vyřešit docela dobře. Myslím. Vlastně dokázali. Kredit zde patří i mojí ženě a našim synům.

Máte podobné trable a jste zvědaví na příběh o krocení práce ve prospěch dovolených? Pojďme na to.

2018: Podělaná dovolená v Řecku

Apartmán číslo 303, hotel Diagoras, Rhodos. Je odpoledne, někdy v létě 2018. Zbytek rodiny je u moře.

Já sedím u počítače. Nespal jsem celou noc. Ráno jsem ženu s kluky nechal jet samotnou na pláž. Vedro na Rhodosu je pekelné, všude samý šutr. Zbytek rodiny miluje moře. Jenže moře je slané a lepkavé. Moře je vlastně celkově hnus. Ale to není můj hlavní problém.

Znal jsem ten pocit z jiných dovolených, v jiných lokalitách. Celkově jsem se tam vždy cítil labilně. Rozhodilo mě daleko víc věcí než normálně. Každý třetí den jsem měl krizičku. Proč se mi to sakra děje, když mám odpočívat?

A přišla nespavost. Na dovolené. Docela psycho, vám řeknu. Proč sakra na dovolené nespím?

Dneska už vím, že spánek si musím zasloužit. Únavou. Třeba z pohybu nebo jinak náročného dne. Za odvedenou námahu pak přichází odměna. Spánek.

A taky už vím, kde byl problém v tom Řecku. Byl jsem na dovolené, ale nebyl jsem přítomný. Nezastavil jsem hlavu. Jela mi tam práce. Plány, klienti, články, strategie… Tentokrát to začalo nevinným: „Pracovat nebudu, ale zkusím promyslet pár kapitol knížky.“

Tělo leželo na Rhodosu u lepkavého moře, mysl byla v mé freelance firmičce. V Řecku mi došlo, že pro věci jako pasivní rodinná dovolená, kde trochu pracuju, nebyla má mysl stvořena.

2019: Únava v Toskánsku mi pomohla spát

Rok poté jsme jeli do Toskánska. To už jsme udělali nějakou menší přípravu. Přípravu Michálka na dovolenou.

Laptop jsem ani nerozbalil. To se mi nestalo od doby, kdy jsem šel na volnou nohu. Cítil jsem se trochu divně.

Nutkání koukat na e-maily přišlo až pátý den. Lehké, snadno ignorovatelné. Do té doby jsem na to vůbec nemyslel. Spal jsem jako mimino.

Tato dovolená byla zaplněná aktivitami, i fyzickými. Kromě pohybu s rodinou jsem tam chodil běhat. Byl jsem unavený, vytížený a nezvládal myslet na práci.

Došlo mi, že když má práce určitou intenzitu, a je jedno, jestli je to kreativní intenzita nebo manažerské vytížení, musí být nahrazená jinou, třeba fyzickou intenzitou.

Pracovat z malého resortu v Thajsku? Boží! Nikdy mi to nefungovalo.

2023: Dobrodružné Thajsko a kdy práce náhle přestala existovat

Rodinný výjezd do Thajska na vlastní pěst proběhl v roce 2023. To už jsme měli pomalu se rozjíždějící firmu. Ale byla to první dovolená, kde jsem to celé ve vztahu k práci naplánoval systematicky. Pardon, naplánovali.

Dva a půl týdne. Pět míst. Bez plánu, jen s koupeným ubytováním v Bangkoku na aklimatizaci. Každý den jsme řešili, kde přespíme, kde se v tom vedru schováme, kde najíme, jak zabavíme kluky a jak přežiju řízení v tom děsivém provozu.

Práce přestala existovat. Byla vytlačena novou, zdravě stresující situací.

Vytlačena. V tom byl klíč.

Dřív jsem si myslel, že problém je ve mně. Že jsem workoholik bez vůle a bez zájmu o rodinu.

Thajsko definitivně ukázalo, že problém je v nastavení té dovolené. Pasivní dovolená mi v mozku nastartuje kreativní část. A ta část chce pracovat. Ne, protože jsem zlej člověk. Prostě z nudy.

Aktivní cestování hlavu zaměstná jinak. Zjistil jsem, že se nemusím unavit fyzicky. To je ostatně zajímavé jen pro mě. Zjistil jsem, že se stačí jen vynechat plánování dovolené a dostat do mírného stresu sebe i celou rodinu. Budete se divit, ale vyhovuje nám to všem. Tmelí nás to a máme mrak rodinných historek.

Jo a taky jsem v roce 2023 zjistil něco o delegaci a výhodách týmové práce. Naši lidi v PageSpeed.ONE to celé zvládli bez mě. Máme docela dobré procesy, role v týmu a systém na předávání dovedností. A taky jsou naši lidi skvělí.

Vrátil jsem se z Thajska ještě trochu roztřepaný, tím zdravým stresem. Ale hned druhý den jsem byl zpátky v tempu. Nadšeně jsem se pustil do práce.

Proč vlastně vůbec jezdit na dovolenou?

Občas slyším, že lidé s mou úrovní lásky k práci prostě na dovolené nejezdí. Já to dříve zkoušel, ale nefunguje mi to. Dovolené potřebuju. (A někdo potřebuje ještě delší pauzu – o tom je třeba podcast se sabatiklem Petra Buriana.)

Je to trochu paradox, ale když pár týdnů nepracuju, v práci mi to pomůže.

Klíč je ve změně kontextu. To znáte všichni. Doma nebo v práci se nám v hlavě melou pořád stejné věci. Praha, kolegové, zprávy, sítě… Na cestách se nám většinou daří většinu z toho vypnout.

Původní agenda naší hlavy by měla být nahrazena co nejvíce rozdílným kontextem. Daleko více prostoru pro rodinu, například. Plánování trasy. Focení a úpravy fotek. Večerní zápisky z toho, co jsme zažili. Nebo třeba upovídaní taxikáři, ty já miluju.

Z toho odstupu přijdou myšlenky, které bych u pražského stolu nevymyslel. V Thajsku mi například došlo, že mi v práci začíná hodně chybět kreativní práce. Začal jsem zase víc psát. Od té doby si podle toho řídím čas. Pomohlo mi to.

Odpočinek vám dá jednu podstatnou věc, energii. Z dobře pojatého odpočinku se vracím s energií a motivací, kterou jsem před odjezdem neměl.

Nejsem výjimka. Popisuje to výzkum.

Mozek potřebuje zhruba tři dny, než se přepne z pracovního režimu. Teorie se jmenuje Attention Restoration Theory (Kaplanovi). Kreativní myšlení se vrátí až po úplném odpojení. Prodloužený víkend tedy nestačí.

Ještě jedno zjištění, méně příjemné. Účinek dovolené vyprchá zhruba do dvou týdnů po návratu (pěkně to shrnuje The Cut o výzkumech Jessicy de Bloom). Trošku depka? Nevadí, protože zážitky zůstanou a přeskládání hlavy vám už nikdo nevezme.

Zní to hezky? A teď ještě, jak to uvést do praxe

Tolik k mojí cestě k dovoleným, které fungují. Pro mě, pro rodinu a taky pro firmu. Teď vám zkusím dát pár tipů na techniky, které jsem si v čase osvojil.

Třeba je použijete. Nebo to vidíte jinak a napíšete mi.

Odpojit se. Ale fakt.

Půlka lidí říká, že jsou offline. Možná s sebou nemají počítač, ale zároveň mají v kapse telefon, který každou chvíli blikne. To není odpojení.

Před každou dovolenou mám tenhle očišťovací rituál. Zní to ezo, ale já prostě jen mažu:

Počítač si beru jen pro případ nouze. Většinou ho použiju jen na objednávání lístků. Pracovní věci už dokážu ignorovat.
Slack jakožto symbol akutní práce jde z telefonu úplně pryč.
Sociální sítě jakožto zdroj zpráv odjinud si smažu všechny, protože časové zámky a limity na mě nefungují.

Výjimku mám jen Gmail a Instagram, a i ty držím na uzdě.

Na Instagram dávám storíčka pro rodinu a kamarády, to je fajn. Ke konzumaci je ale zrádný. Chci si třeba odpočinout od politiky a on mi ji stejně nacpe do feedu. Takže odhlašuju odběry těmto zdrojům a po dovolené si je zase postupně přidávám. S Instagramem je potíž v tom, že jej používá starší syn a i během dovolené občas přiběhne s další kauzou Filipa Turka. Šmarjá, exoty na dovolené fakt řešit nechci! Další krok tedy spočívá ve výchově syna.

Hledání tátova počítače. Ne, kecám. Nikdo na něj nemá pomyšlení. Ani táta.

Do Gmailu kouknu jednou za týden. Smažu nerelevantní, archivuju zbytek, něco odložím a pokud něco blokuju, přehodím to na kolegy, ať to nestojí. Občas odepíšu, ať to neblokuju. Toto se ale třeba letos týkalo přesně jednoho e-mailu. Má to velkou výhodu v tom, že mě po návratu nečeká velká darda mailů. Prostě jsem většinu z nich promazal už na dovolené. (Běžný provoz mi drží Inbox Zero.)

Ale je možné to udělat jen za předpokladu, že vás v mailu nečekají strašáci, průsery nebo jiné emoční pasti. To se u mě naštěstí nestává. Důležité je, že za většinu toho, co řídím, je zodpovědný někdo jiný.

Deleguj, pokud máš komu

Dřív jsem si myslel, že delegování je o tom rozdat úkoly před odjezdem. Není. Je to o tom vybudovat tým, který mě nepotřebuje. To je rozdíl mezi „odjíždím, ale budu na příjmu“ a „odjíždím a nemusím řešit nic“.

V PageSpeed.ONE máme jasné role, docela funkční procesy a obstojný systém na předávání znalostí. Když jsem byl v Thajsku, firma běžela dál beze mě, tam mi to došlo. A právě tohle vědomí, že to bez vás pojede, je podmínka skutečného odpojení. Bez něj budete mít hlavu v práci, ať jste kdekoliv na světě.

Vybírám termín, kdy vypnou i klienti

Nejhůř se odpočívá, když víte, že se vám mezitím kupí práce. Proto má smysl volit dobu, kdy zpomalí i okolí. Červenec, srpen, prosinec, leden. V těchhle měsících je i většina klientů v útlumu a nikdo nečeká odpověď do hodiny.

Není to jen o klidu v hlavě během cesty. Je to i praktické. Vrátíte se do menšího nepořádku, protože se toho za tu dobu tolik nenakupí.

Fade-in před dovolenou a fade-out po ní

Většina lidí před dovolenou zrychlí. Nabírají úkoly, zůstávají déle v práci, chtějí „všechno dodělat“.

Výsledek? Odjíždíme vyždímaní a první tři dny na dovolené a první tři dny po dovolené se jen vzpamatováváme. Dělám to jinak. Mentálně si dovolenou prodlužuju o pár dní předem i poté.

Fade-in znamená práci před odjezdem naopak ubírat. Poslední dny před cestou jsou u mě nejklidnější, ne nejhektičtější. Udělám opravdu vše důležité, ale nevymýšlím nic navíc. Trochu to souvisí s uměním říkat NE – hlavně sobě a vlastním nápadům „ještě to dodělám“.

Fade-out je ta samá věc po návratu. První den doma je oficiálně pracovní, ale ještě v něm nepracuju. Vybalím, přerovnám fotky, projdu si kalendář, naladím se. Teprve druhý den se jdu ohlásit kolegům do Slacku naplno. Ten jeden nárazník mezi cestou a prací mi ušetří týden rozladěnosti.

Odbavuju to průběžně

S pomalým nájezdem po dovolené souvisí i to průběžné promazávání inboxu, o kterém jsem psal výše.

Nejhorší je nechat si všechno na příjezd. Když se vrátíte a čeká vás pět set mailů, tři sta fotek a napůl napsané recenze na ubytko, odpočinek je rázem pryč.

Totéž co pro Gmail výše platí i pro agendu z dovolené – fotky, recenze a zápisky. Dělám je už během dovolené. Kousek po kousku, ne naráz po dovolené.

Návrat je pak měkký a po nájezdu pracovní agendy si s sebou netáhnu frustraci, že jsem nestihl dokončit fotky z dovolené.

A vy?

Shrnutí pro netrpělivé workoholiky, kteří přeskočili rovnou na konec:

Pracovat na dovolené mi nefunguje. Pasivní plácnutí těla na pláž mi nefunguje.

Funguje mi chaos a fyzická nebo jiná únava. Funguje naladění rodiny na jednu věc. Nejde to bez dobrého systému pro dovolenou a dobrého systému v práci.

Jste taky ten typ, co si na dovolené „jen na chvíli“ otevře pracovní mail? Soudy nevynáším. Každému funguje něco jiného a rád si přečtu vaše příběhy.

Napište mi to na LinkedIn, Facebook, X nebo Threads.

Vývojáři, víte, proč vám váš CEO bere práci, a proč je to dobrá věc?

Mon, 15 Jun 2026 00:00:00 GMT

Stále více se cpeme do vašeho kódu. My, markeťáci, produkťáci, šéfové firem. Prostě netechničtí lidé. Občas z toho máte bolehlav, to je jasné. Ale nevyhnete se tomu.

V tomto textu jdu nastínit, co je naší motivací a proč vám můžeme být prospěšní.

Jak už víte, k právě probíhající AI revoluci mám střízlivý přístup. Nemyslím si, že zahubí SaaS. Nemyslím si, že vývojáři skončili. Nemyslím si, že nastává konec světa.

Některé věci se ale brutálně mění, například vývoj produktů.

Na meetupu Frontendisti.cz jsem ukazoval, proč vám váš CEO bere práci. Nepadlo tam ale vše, co padnout mělo, takže to teď jdu článkem doplnit a obohatit o širší kontext.

Další hyperproduktivní vajbící manažer

Jsem ten typ CEO, který chce chápat a umět to zásadní, co se ve firmě řeší. A když je potřeba pohnout, vyhrne si rukávy a jde makat. Myslím v kódu, více ode mě nečekejte. Navíc ještě donedávna aktivně weby vyvíjel.

Pomocí vibe-codingu, nebo agentního vývoje chcete-li, jsem vytvořil několik aplikací, které můžu sám používat a šetří mi čas. Tohle je asi jasné.

Nyní ale ve firmě máme za sebou první úspěšné pokusy pustit mě přímo do kódu našeho hlavního produktu v PageSpeed.ONE.

V rekordním čase a s rozumnými náklady máme nový web, připravili jsme novou aplikaci na měření rychlosti webu a tak dále. Není to dokonalé, ať už jde o výstupy navenek nebo v kódu a proces samotný, ale hlavní cíle to plní a extrémně to zrychluje iterace.

Náš krásný nový test rychlosti webu, který vrací skóre rychlosti u reálných uživatelů.

Proč je často nejlepší varianta, abych appku, rozšíření webu nebo fíčuru udělal já?

Ten hlavní argument je efektivita. Během času, který by mi zabralo vytvoření zadání a management dané věci, tu danou věc vyrobím.

Ale jsou tady i další argumenty.

Proč si myslím, že účast netechnických lidí v kódu je pro vývojáře dobrá věc?

Když vám CEO, produkťák, markeťák leze do kódu dobře, vývojářům to může přinést mnohé:

Hmatatelný prototyp místo dlouhého zadání.
Rychlejší rozhodnutí a méně komunikačního ping-pongu.
Méně „překladů“ kontextu přes mnoho lidí.

A pak je tu ještě jeden důvod. Jsou to přesahy.

Jako CEO bych měl vědět, co chtějí klienti, protože jsem s nimi v kontaktu. Vím, kde máme argumentační mezery, znám celý kontext našeho produktu. Mám povědomí o marketingu nebo jej sám částečně dělám. Dělám sales, accounta, trošku finance, docela hodně produkt, musím umět naší specializaci, takže oblast rychlosti webu… A to je kombinace, která mi umožní generovat kód prospěšný produktu.

Nejsem nejlepší, co se týká kvality kódu, to obstarají jiní (a dobře nastavené procesy), ale do kódu předávám pohled, který tam předtím mohl chybět.

Do velké míry to souvisí se specializací nebo jejím opakem, takže budováním znalostí spíše do šířky než do hloubky. Jako CEO musím být generalista.

Hloubka vs. šířka znalostí lidí v týmech

Na tomhle obrázku/grafu je jednoduchá manažerská metafora pro hloubku vs. šířku znalostí:

Co vidíte na obrázku?

Svisle je hloubka znalostí, takže jak moc jdete do detailu v jedné disciplíně.
Vodorovně je šířka znalostí, takže kolika sousedním oblastem rozumíte natolik, že se v nich neztratíte a umíte je propojit do výsledku.
Pokud jste „I-shaped“, rozumíte skvěle jedné věci, ale ty ostatní vám unikají. Pokud jste „T-shaped“, rozumíte skvěle jedné věci, ale zároveň máte obecné povědomí i o těch ostatních. A tak dále.

V malých týmech se obvykle lépe uplatní lidé s více přesahy, ale obecně zde není žádná definice dobrého nebo špatného „tvaru dovedností“. Je úkolem každého člověka (a jeho manažera) své dovednosti znát nebo posunovat tak, aby dobře fungovaly v daném týmu.

Extrémní příklad I-shaped může být člověk specializovaný čistě jen na frontendový vývoj. Nebo ještě hůř – jen na CSS, ehm… Nastínil jsem to na obrázku tady:

I-shaped frontendista. Dneska docela rizikové portfolio dovedností. Zdroj grafu: appka SkillShaper.

CEO firmy je druhý extrémní příklad, protože ten by naopak neměl být specialista, ale mít co nejširší záběr dovedností. Na svém příkladu jsem to ukazoval takto:

CEO musí být multi-skill. Zdroj grafu: appka SkillShaper.

Pro to, aby vznikl jakýkoliv digitální produkt, je potřeba něco vědět nejen o produktu, UX a vývoji, ale také o vedení a strategii firmy, lidech v ní, financích a nejlépe i marketingu.

Všechny tyto dovednosti a kontexty musejí ve firmách probublat přímo k lidem, kteří mají konečné zhotovení produktu na starosti, tedy k vývojářům.

Obvykle se to děje pomocí různých zadání, dokumentací, firemních strategií, ale také schůzek nebo méně formálně, v hospodě či firemní kuchyňce.

To, že celý ten kontext máte v hlavě, znamená, že když dostanete možnost snadno konkrétní věc vyrobit, budete velmi efektivní.

No a tou možností se stala AI revoluce, která komoditizuje a tedy brutálně zlevňuje některé části vývojařiny.

Produkt mám hotový v čase, který je nižší než čas na zadání a management…

Agentní vývoj je dneska tak daleko, že když se to udělá opatrně (a CEO je bývalý vývojář), funguje to velmi dobře. Tohle jsou přesně důvody, proč se kód začíná otevírat i lidem mimo engineering:

Prototypování je dneska dostupné prakticky všem a skoro zadarmo.
Zlevnila se realizace některých částí aplikací.
Není potřeba tolik zadávání, handoffů a feedback koleček.

…ale když se dobře nedomluvíme, můžu celý produkt zničit

Ale jasně, vývojáři, slyším vás. Špatně nastavené procesy nebo jejich nedodržování těmito netechnickými lidmi může přinést katastrofu:

Obcházení procesů (PR bez code review).
Změny bez znalosti architektury, které jdou proti ní.
Sahání na místa, kde může vzniknout nebezpečná úprava.

Tohle je jedna z výzev, kterým nyní čelí produktové, ale i agenturní týmy. Změna pracovních postupů a technologického stacku, která umožní, aby se netechničtí lidé mohli zapojovat do práce na produktech.

Myslím si ale, že Pandořina skříňka je otevřená a zavřít ji už nemůžeme. Příspěvky netechnických lidí do kódu se dít budou a vývojáři se s tím budou muset vypořádat.

Děje se vám to ve firmě taky? Jak to řešíte? Diskutujme na LinkedInu, na X, na Threads nebo na Facebooku.

WebExpo 2026: Switch Angel, Daniel Cuthbert, Mike Kus & FrontKec

Mon, 18 May 2026 00:00:00 GMT

WebExpo letos připadá na konec května (27. – 29. 5.) a já už mám samozřejmě pražskou Lucernu v kalendáři.

Prošel jsem program a vybral čtyři přednášky, na které bych šel v paralelním vesmíru, kde těsně před přednáškou nepotkám někoho z vás a nezapovídám se.

Na výběru frontendových přednášek jsem se podílel i u FrontKonu. Naše tipy mají širší záběr. Tady je můj zkrácený osobní výběr.

Čtyři přednášky, které bych nerad minul

Switch Angel: Patterns for restarting the world
Keynote na úvod. Známá streamerka, live coding hudby ve Strudelu a elektronický pop v reálném čase. Na to se těším.
Daniel Cuthbert: From HAL to Replicants
Agenti, platby, bezpečnost — svět, kde AI nejen píše commit message, ale i rozhoduje za vás. Myslím, že to nebude sci-fi povídání, ale tvrdá realita.
Michal Kessel Shitrit: Don't trust the bot
Jak neposlat uživatele do pekel AI generovaným microcopy. UX writing s rozumem — přesně to, co teď řeším v práci.
Mike Kus: Design like no-one is watching
Design bez strachu ze šablon od AI. Velké jméno UX scény volá po kreativním instinktu. Kde to podepsat?

Natáčení FrontKecu ve středu: diskuze nad tématy prvního dne WebExpo

Po prvním dni, těsně před 18:00, zalezu s Robin Pokorným do malého kina v Lucerně a natočíme živý díl FrontKecu.

Shrhneme den, pokecáme o přednáškách. Jako obvykle i s vámi v publiku. Neformálně, stejně jako ostatní díly — jen s materiálem z konference v hlavách.

Doražte nás pozdravit.

Slevičku ze zahrádky…?

Kód MICHALEK26 vám na vstupenku ušetří 1000 Kč (konferenční i bundle).

Premium workshopy se do slevy nepočítají, jen pro jistotu.

Uvidíme se v Lucerně?

Podcast FrontKec: prvních 10 dílů na jednom místě

Mon, 20 Apr 2026 00:00:00 GMT

Asi už víte, že po 59 dílech podcastu ze Vzhůru dolů pokračujeme s Robinem Pokorným v novém formátu pod názvem FrontKec pod hlavičkou komunity Frontendisti.cz.

Už jsme natočili deset plných epizod a spoustu témat od produktu a AI až po DX a výsledky anket State of JS a React. Tohle je krátké shrnutí s praktickým rozcestníkem na už natočené díly.

Pojďte s námi poslouchat FrontKec

Ještě než se pustíte do výběru dílu, tady je video pozvánka na nový podcast:

Kde FrontKec sledovat?

Spotify: FrontKec podcast
YouTube (playlist všech videí): Podcast FrontKec
Apple Podcasts: FrontKec
Web: frontendisti.cz/frontkec
RSS: Anchor feed

FrontKec patří ke komunitě Frontendisti.cz, kde najdete i možnost přihlásit se k newsletteru nebo sociálním sítím.

Všech 10 dílů podcastu FrontKec v jedné tabulce

Náhledy jsou standardní obrázky z YouTube CDN (název dílu je uveden v alt pro přístupnost).

Náhled	Díl	Odkazy
	01: Podcast ze Vzhůru dolů končí, FrontKec začíná Tomáš Kout vyzpovídá Martina s Robinem o historii podcastů, Frontendistech a cestě k nové značce. Nejlepší start, pokud chcete pochopit kontext změny.	Spotify YouTube
	02: Diskuze na WebExpo 2025 Záznam diskuze s publikem po prvním dni WebExpa: AI a budoucnost UI, reakce na přednášky a otevřené otázky. Zvuk je syrovější, atmosféra naopak hodně autentická. Na WebExpo 2026 natáčíme další díl na místě.	Spotify YouTube
	03: Marek Prokop: AI Overviews vs. SEO, psaní kódu s AI Prakticky a bez paniky: co znamenají AI Overviews pro SEO a jak Marek používá AI při psaní kódu. Dobré, pokud řešíte dopady LLM na práci i webový byznys.	Spotify YouTube
	04: Jirka Helmich: AI vs product management Zkušenost z růstu Mews a role „transformation coach“: produkt, AI a firmy, které ztratily kontakt se zákazníkem. Hodně konkrétních tipů i širší souvislosti.	Spotify YouTube
	05: Daniel Steigerwald: Local First a Evolu Framework Evolu a myšlenka Local First: vlastnictví dat, svoboda uživatele a architektura mimo „jen další SaaS“. Rozhovor, který jde do hloubky, ale nezůstane jen u kódu.	Spotify YouTube
	06: Marek Velas: sebevzdělávání v době AI Kariéra a soft skills: jak LLM mění učení, co je hodnota práce a otázka „co jsem, když odečtu kód?“. Vhodné i mimo čistý frontend.	Spotify YouTube
	07: Ondřej Ilinčev a Pavel Ungr: AI a juniorní pozice Dopady AI na znalostní práci, seniory i nábor juniorů: ostré téma a dost přímočará diskuse. Pokud řešíte „co bude s juniory“, tady je hodně podnětů.	Spotify YouTube
	08: Honza Hrubý: Developer Experience DX v měřítku Mews: kultura, procesy a srovnání build nástrojů (Webpack, Rspack, Vite, Oxc). Praktické pro týmy, které řeší rychlost a spokojenost vývojářů.	Spotify YouTube
	09: Nowwwinky: CSS Grid Lanes, Temporal, Interop 2026, MCP Speciál s Tomášem Koutem: rychlé novinky z frontendové scény, MCP, AI a hromada odkazů v show notes. Jeden díl pro „co se teď děje“.	Spotify YouTube
	10: Riki Fridrich: State of JavaScript a React 2025 Data z anket: TypeScript, nálada kolem Next.js a realita kolem Vite/Vitest. Skvělé pro orientaci v trendech a pro stacková rozhodnutí.	Spotify YouTube

Děkujeme, že nás posloucháte!

A klidně nám napište, který díl se vám líbil nejvíc a jaké další hosty bychom si měli pozvat.

AI prý zabije SaaS. Zamysleme se nad tím ještě jednou

Fri, 06 Mar 2026 00:00:00 GMT

Žijeme ve světě, kde jedna temná AI předpověď střídá druhou. Zároveň je ale dobré si uvědomit, že my lidé jsme naprosto excelentní v jedné věci – přeceňování svých znalostí u oblastí, kterým nerozumíme.

Tahle lidská iracionalita se vztahuje o to víc na ty z nás, kteří milují pozornost spouštěnou temnými předpověďmi.

Pobavme se zde zcela konkrétně, a to o „SaaSpocalypse“, apokalypse SaaS firem. Akcie softwarových akcií padají, protože SaaS aplikace (Software as a Service) už nebudou potřeba. Každý si je může s AI napsat sám.

My, iracionální lidé, a AI katastrofy

Ano, AI mění pravidla hry. Ale ne každá změna pravidel znamená konec hry.

Podívejte se na příklady:

Junioři už nebudou potřeba. Kdo se o ně postará?!
Říkají to všichni a poptávka po juniorech opravdu klesá. Jenže neklesá jen vinou AI, ale ekonomiky jako celku. A taky vinou toho, že jde o odloženou poptávku. Nárůst produktivity stávajících zaměstnanců díky AI nebude nekonečný.
Zanikají pracovní místa. Jsme bez práce všichni!
Jako třeba když bývalý majitel Twitteru, Jack Dorsey, z firmy Block vyhodil 4 000 lidí. Katastrofa, všichni přijdeme o práci! Až na to, že to je celé trochu jinak, a Block potřeboval zeštíhlení jako sůl. To je prostě AI washing jak vyšitý.
„SaaS čeká největší zkouška za posledních 20 let. A asi to nedá!“
… píší jiní. Musí to být pravda. Napsali to v Hospodářských novinách, kde tomu článku dal editor titulek „Nastala doba digitálního kanibalismu. Umělá inteligence začala požírat software zevnitř“. Osobně bych chtěl, aby AI požírala spíše editory, kteří vymyslí takový titulek. Ale k věci – právě k SaaSpokalypse se v tomhle textu chci vyjádřit.

Kolik takových katastrof, které za pár let zničí celá odvětví, jsme zde měli jen za posledních 10 let? Elektromobily do pěti let do každé domácnosti. Blockchain vše změní. Kryptem budou platit i dělníci ze šroubárny. Průlomy v energetice.

Sejdeme se v Metaverse, kde budeme sledovat konec Evropy způsobený Green Dealem.

Svět se mění a měnit bude, ale možná trochu jinak, než hlásají věrozvěstové.

Zpět k SaaSu.

SaaSpocalypse

Provozujeme SaaS. Proto mě tohle téma docela zajímá. AI má na vše v tomhle oboru velký vliv. Používáme AI, strategicky sledujeme vše co se děje. Je to velké jako prase.

Ale zároveň vidím, že se lidé nechovají racionálně. Investoři už vůbec ne. Ilustrujme si to na nyní velmi trendujícím obrázku, který ukazuje pád akcií softwarových firem.

Zde vidíme výsledek hlasování odborníků na SaaS, AI a budoucnost.

Vychází to z toho, že softwarový vývoj prochází tektonickou změnou. Vibe-coding otevřel vývoj softwaru širokým masám.

Každý druhý CEO leze do kódu.

Z designérů se stávají „builders“.

Naše kočka by si stavěla vlastní SaaS. Kdybychom nějakou kočku měli…

Lecjaký AI konzultant křičí, že Cursor, z pohledu interface docela tenká nádstavba nad vývojářským editorem VS Code, je „nejlepší software, jaký byl kdy vytvořen“.

Nadšení chápu. Ale jak to nadšení, tak ty temné předpovědi a nakonec i pohyb ceny akcií ukazuje na neznalost oboru softwarového vývoje.

Pojďme si to ilustrovat na smyšleném příkladu.

U dvanáctého postu na LinkedInu jsem se naštval. A vymyslel Pepíka.

Pepík a jeho fakturační software

Byl jednou jeden Pepík. Pepík je marketér a trochu AI konzultant. Pepík je smyšlená postava, aby bylo jasno.

Pepík si dodnes platil fakturační SaaS službu. Ale včera si „navajbil“ hypotéční kalkulačku, propadl nadšení, a dneska se rozhodl, že přestane platit SaaS a udělá si vlastní udělátko na fakturace. Protože na internetu psali, že vývojářů už nebude potřeba.

Den první – nadšení

Pepík otevírá Cursor, vytvoří jakés takés zadání a po několika iteracích má řešení. Naťuká data, má fakturu, dokonce v PDF a dokonce hezčí, než nabízela původní služba. Hned běží na síť X napsat: „Za dvě hodiny práce jsem si vytvořil stejnou aplikaci, jako je ta, za kterou jsem platil 3 000 Kč ročně. SaaS je mrtvý!!!“

Vítej v krásném novém světě, kde si všichni mohou naprogramovat cokoliv, Pepíku!

Den druhý – co je git?

Jiný klient. Jiná faktura. Je potřeba přidat další kolonky. Prostě zadá prompt, aby to Cursor upravil. Něco se tam ale přitom rozbije. Už nefunguje ani původní vystavování faktur. Pepík nerozumí hláškám v terminálu.

Rád by se vrátil k původní verzi. Slyšel, že existuje něco jako git. Ale není čas to studovat. Nakonec to nějak hackne, ale přišel o dvě hodiny práce, ve kterých chtěl psát o tom, jak vibe-coding mění svět.

Vítej ve světě verzování, Pepíku.

Den třetí – divné hlášky v terminálu

Pepík se celé dopoledne učí git. Na síti X psali, že nově to musí umět i marketéři. Umí tedy verzovat a když se mu něco rozbije, udělá krok zpět. Jde tedy řešit ty divné hlášky v terminálu.

Po dvou hodinách se mu to povede, ale vlastně pořádně neví, jak. Ztratil přitom sice přehled o čase, neudělal analýzu pro klienta, ale už je z něj vlastně kromě marketéra i programátor. Vždyť programátoři jsou ti, kteří řeší divné hlášky na displeji.

Vítej ve světě vývojářských základů, Pepíku.

Den čtvrtý – cože, faktura v Eurech?

Další den je potřeba poslat fakturu slovenskému klientovi. V Pepíkovi hrkne, protože to znamená přidat možnost mít fakturu v Eurech. To je nakonec v Cursoru hračka, ale… hele, jak je to s kurzem a přepočtem měny…? Pepík jde studovat, za hodinu to má i s výsledkem.

Nakonec mu ale klient stejně fakturu vrací, prý kvůli špatnému „vypořádání přenesené daňové povinnosti“. Pepík je zaskočen a v dokumentaci SaaS appky, kterou před pár dny přestal platit, hledá detaily. Nakonec to po třech hodinách zvládne a je připraven vystavovat faktury na Slovensko.

Vítej ve světě managementu know-how a produktových fíčur autorů SaaSových aplikací, Pepíku.

Den pátý – „Co si to dovolujete“?

Pepíka to už trošku štve, protože toho za posledních několik dní moc neudělal. Ale už chystá post na síť X ve stylu „co jsem se naučil vývojem vlastního řešení na fakturaci?“.

Vleze mu toho ale mail od klienta, kterému před čtyřmi dny vystavil svou první fakturu. Jeho předmět zní „Co si to dovolujete?“. V Pepíkovi hrkne, ale bude to ještě horší. Klient přiložil screenshot z jeho fakturační aplikace. Místo vymazleného, AI-generovaného loga Pepíkovy konzultační firmy tam je prostě… eh… porno obrázek.

Poté, co Pepík ukazoval své faktury na síti X, si s tím někdo trochu pohrál.

Vítej ve světě online bezpečnosti, Pepíku!

Pepíkova cesta.

A co se stane den šestý, milé čtenářky a milí čtenáři?

Pepík si jde obnovit předplatné SaaS služby.

Ať už si o reálnosti příběhu myslíte co chcete, díky němu snad už máte v hlavě alespoň základní strukturu toho, co poskytuje většina SaaS služeb.

SaaS je zpoplatněné převzetí zodpovědnosti

SaaS totiž není jen software.

SaaS je často velmi komplexní technická infrastruktura (někdy zkusím naznačit, co vše obnáší testování rychlosti webu v PageSpeed.ONE). SaaS je doménová znalost problému. SaaS je know-how, které jako autor appky získáváte. SaaS je produktová vize, komunikace s cílovkou a nacházení problémů, které si vajbkodér neumí představit. SaaS je řešení stability, bezpečnosti a rychlosti řešení.

SaaS je převzetí zodpovědnosti za váš problém. Fakturoid do určité míry přebírá zodpovědnost za vaši fakturaci a část finančního řízení. My v PageSpeed.ONE do určité míry SaaSem přebíráme zodpovědnost za řešení rychlosti vašich webů.

Sebelepší AI za nic nepřevezme zodpovědnost.

Programování není jen psaní kódu. Proto všechny programátory nenahradí AI.

SaaS není jen naprogramovaná appka. Proto všechny SaaSy nenahradí AI.

Na co jsem zapomněl, co mám špatně? Napište mi e-mail nebo komentujte na sociálních sítích: na LinkedInu, Facebooku, X.

Vibe Coding: Přes 25 let dělám weby, ale poslední dva měsíce úplně jinak

Tue, 10 Feb 2026 00:00:00 GMT

Vibe coding je revoluce jako prase. Způsobuje deflaci psaní kódu u vývojářů. Širokým masám zase nebývale zpřístupňuje tvorbu webů nebo jiných digitálních produktů.

Vibe coding je ale taky trochu past. Je to past pro lidi, kteří si myslí, že se obejdou bez vývojářů nebo vývojářského myšlení. A pro vývojáře? Pro některé velká příležitost, pro jiné bolení.

Myslel jsem si, že Vzhůru dolů je skoro mrtvé, ale vibe coding jej vzkřísil. Nejen technicky, ale i obsahově. Pokud mám letos na blog napsat jen jeden článek, musí to být tenhle.

Zkusil jsem tenhle článek koncipovat jako koláž motivace, malých esejí a praktických tipů.

Co se tématu týče, jsem aktuálně ve fázi explodující hlavy. Berte mě tedy s rezervou, ale musíme tím začít.

U vytržení

Přes 20 let jsem aktivně vyvíjel webové aplikace, kolem webových technologií se točím už 27 let. Ale něco takového jsem v oboru nezažil. A nejsem sám:

„Teď jsem si sedl k Windsurfu a mám za tři dny novou verzi, která toho za týden práce bude umět víc než moje dílo za 9 měsíců. Je to fakt šílený.“

– Petr Pixy Staníček

Vibe-coding demokratizuje technologie a vývojařinu. Zpřístupňuje ji všem:

„Sedl jsem k Wix Vibe a za 2 hodiny je hotový volební web včetně CMS. Dříve tohle bylo několik týdnů práce po večerech ve WordPressu.“

– Michal Berg

Vývojáři a technologicky zdatní lidé ale nejsou bez práce. Mají výhodu a náskok. Když nezaspí. Okno příležitosti už je otevřené, a to dokořán.

Ale OK. Kromě nadšení zkusme být i střízlivější:

„Když přesně víte, co chcete, a víte i to, jak to nejlíp udělat, ušetří vám AI hodně práce. Když nevíte, výsledek může být hodně špatný.“

– Marek Prokop

„Vajb… cože?“

Nejdříve to zkusme definovat:

Vibe-coding je způsob programování, kdy popisujete záměr v přirozeném jazyce a AI generuje kód za vás. Místo psaní jednotlivých řádků komunikujete s modelem o tom, co chcete udělat.

Název pochází od Andreje Karpathyho:

„…you fully give in to the vibes, embrace exponentials, and forget that the code even exists.“

– Andrej Karpathy

Hlavním nástrojem je pro mě Cursor – editor postavený nad VS Code s integrovanou AI. Existují i další: Windsurf, GitHub Copilot, teď letí Antigravity od Googlu a spousta dalších. Společné mají to, že AI chápe kontext vašeho projektu a umí v něm pracovat.

Cursor v režim Agent je boží hlavně pro vývojářský způsob myšlení. A rozhraní znáte z VS Code.

Cursor má režim Agent, kdy AI pracuje autonomně. Sám spouští terminál, čte soubory, instaluje knihovny, píše do více souborů najednou. Vy to schvalujete nebo korigujete směr.

Rozdíl oproti tradičnímu vývoji? Neřešíte syntaxi, negooglíte dokumentace, nepíšete boilerplate. Řeknete, co chcete, a AI to napíše. Vy pak kontrolujete, opravujete, směřujete.

Je to jako mít juniora, který píše rychle a hodně, ale potřebuje vaše vedení.

Vibe-coding vs. vibe-engineering

Ne každá vývojářská práce s AI je stejná. Pracovně zde zkusíme rozlišit alespoň dvě úrovně.

Vibe Coding – neřeším kód vůbec. Sednu ke Cursoru nebo třeba Macaly, popíšu, co chci, a nechám to jet. Tohle je ideální pro prototypy a ukázky (když pak ten kód zahodíte), jednoduché weby a landing pages nebo jednorázové nástroje. Pojem „Vibe Coding“ tady používám i pro širší pojmenování celé téhle oblasti.
Vibe Engineering – Inženýrský přístup nad rámec Vibe Codingu. Tady už nejde o to „nechat to jet“, ale o vědomou spolupráci. Vy navrhujete architekturu, rozkládáte problém na podproblémy, AI implementuje podle vašich specifikací. Ale i ty specifikace tvoříte spolu. Vývojářské a architektonické myšlení zůstává na vás. AI je nástroj, ne náhrada mozku.

Můžeme se hádat o definici, ale nechce se mi do toho. Jsou to jen slova. Uvádím je proto, aby ti z vás, kteří se neorientují, uměli v základu odlišit různé typy „vajbení“ kódu.

Poznámka bokem: vždycky jsem se snažil pojmy překládat, ale tady na to peču. Ten obor se tak rychle vyvíjí, že je možné, že tohle všechno je jen zastávka na cestě k ještě větší autonomii AI.

Co je ale podstatné, to vyznačím opět citací od Marka Prokopa:

„Dávejte si na to pozor a učte se programovat. Je to potřeba i v éře AI.“

– Marek Prokop

Tohle je klíčový rozdíl mezi vibe-codingem a vibe-engineeringem. Vibe-coding zvládnete i bez hlubokých znalostí – pro prototyp nebo jednoduchou landing page to stačí. Ale jakmile jde o něco složitějšího, potřebujete být inženýr. Rozumět tomu, co AI dělá. Umět ji opravit, když se splete.

Čím začít, když jsem nováček?

Jindra Fáborský to hezky rozřadil do levelů podle složitosti projektu:

Level 0 – jednorázové nástroje a vychytávky
Level 1 – landing pages
Level 2 – celé weby
Level 3 – prototypy aplikací
Level 4 – interní nástroje
Level 5 – produkční aplikace

Čím vyšší level, tím víc potřebujete inženýrský přístup. Na Level 0–2 stačí vibe-coding. Od úrovně 4 a výš už musíte být vibe-inženýr.

Pro vývojáře skvělá zpráva. Pro laiky? Nepusťte se rovnou do přepsání vaší appky, která vám vydělává peníze. Prosím, nedělejte to.

Já a vajbení: čtyři příklady

Teorie je fajn, ale pojďme k tomu, co jsem reálně udělal za poslední dva měsíce.

Příklad první: prototyp webu FrontKon

V týmu konference FrontKon diskutujeme nový web. Mám na to docela jasný názor a vizi. Abych lidem v týmu snadněji ukázal svůj záměr, jdu udělat prototyp.

Jeden den práce, včetně skoro finálního obsahu. Kód neřeším, zahodí se, je to prototyp. Dříve jsem takové prototypy dělal týdny. Ručně. Pak se to často zahodilo, což je u prototypů dobře.

První exploze Máchalovy hlavy. Ale taky první zjištění, že vibe-coding je málo. Že musím zapojovat vývojářskou část své hlavy. Že je potřeba číst, co Cursor říká a trošku mu v tom šťourat.

Příklad druhý: web pro syna

Šetnáctiletý syn chce dělat s kamarádem dělat první byznys, stříhání reels z videí.

Sedmeme spolu ke Cursoru. Čekám, že to bude složitější. Hádky o vzhled a tak, znáte to… puberťák. Prompt o dvou větách. Výsledek se mu nelíbí, tak jasně.

Zeptám se Cursoru, jaký styl by se mohl líbit Gen Z. Dá mi na výběr čtyři. Honza vybere jeden, Cursor to předělá a Honza je nadšený.

Web Clipcut hotový za 15 minut. Styl vybraný podle doporučení Cursoru pro Gen Z.

Hotové je to za 15 minut. Propadám přitom hysterickému smíchu. Syn se ptá, zda jsem v pořádku. Já říkám, že ano, ale tohle jsem desítky let dělal dny až týdny. A klienti neměli šanci to tak snadno změnit.

Bastliči malých webů jsou mrtví. Macaly nebo něco takového zvládne kdokoliv, kdo umí popsat, co chce.

Příklad třetí: úpravy textů v PageSpeed.ONE

Miluju psaní. Jdu dělat úpravy textů do naší nápovědy v PageSpeed.ONE. Cursor přesně chápe kontext, umí napodobit konkrétní styl psaní. Řeknu mu jen, co chci zhruba napsat a zhruba kam. Markdowny mi upraví, přidá odkazy, udělá kontrolu.

Jak říká parťák Michal Matuška: „Všichni musíme být full-stack.“ I autoři obsahu. I CEO firmy.

Vibe writing pro Vzhůru dolů – Cursor chápe kontext, umí napodobit styl psaní, doplnit zpětné odkazy a celkově skvěle iterovat podobně jako při vývoji software.

Příklad čtvrtý: migrace Vzhůru dolů z PHP na Astro

Už dva roky chci zahodit starý devstack na Vzhůru dolů. Běží to na zastaralém PHP a CMS Perch, které už nikdo nespravuje. Je tam stará databáze a celkově je to nebezpečné tak, že se na to bojím i podívat.

Chci moderní devstack, chci to všechno naházet do Markdownů, mít to v jenom repozitáři a dát na Github.

Ve „starém světě“ by to pro mě ale znamenalo obětovat několik víkendů nebo investovat minimálně 50, ale spíše 100 tisíc Kč do někoho, kdo to obstará. Nic z toho nechci.

Tohle už je relativně složitý projekt. Napoprvé to s Cursorem nevyšlo. Vzal jsem staré PHP repo a chtěl po něm předělávku do nového. Utopil se v kontextu dvou různých technologií.

Ukazuje se, že se musím naučit ten nový devstack, že Cursoru musím dávat dobrý zadání a že ho musím hlídat, co reálně dělá. Být ten architekt, ne jen divák.

Mohl jsem být divák a mohl to mít rychleji. Ale nebylo by to dlouhodobě udržitelné a to já nechci.

Nakonec je to hotové. Celkově 2-3 dny práce, vlastně pořád skvělé. Je to postavené na Astro, dostupné na Githubu a od konce ledna fičí na živo.

Migrace Vzhůru dolů na Astro. Hotovo za 2–3 dny práce.

Vývojáři bez práce?

Vývojáři se kvůli AI musejí bát o práci, říkali. Prdlajs. Vývojáři mají velkou budoucnost, právě díky AI, říkám já.

Ano, někteří se bát musí. Kódeři, šudlalové, prasiči, copy-pasteři… Ti všichni o svou stávající práci mohou přijít.

Pak tu ale máme skutečné vývojáře. Vývojáře s inženýrským myšlením, znalostí technologie, zkušenostmi. Architekty. Vibe-inženýry.

Ti mají ohromnou výhodu – algoritmický způsob přemýšlení. Schopnost rozpadnout problém do podproblémů. Navrhnout architektonické řešení. Technicky oponovat AI, vylepšit jeho řešení.

Nenechat se vybullshitovat od Cursoru.

Stačí si na chvilku sednout vedle někoho, kdo tohle nemá. Koukat se, jak zadává prompt. A trpět, raději tiše.

Dva typy vývojářů

Když to hodně zjednoduším, vývojáři se dělí podle motivací:

Jedni rádi tvoří produkty – weby, appky, službu lidem.
Druzí rádi píší kód, mazlí se s ním. Milují konkrétní technologii.

Aktuální vlna AI velmi podporuje první skupinu a může dostávat pod tlak tu druhou.

Bude stále těžší být naplňován jen psaním krásného kódu a budeme se více soustředit na výsledek, který nám technologie přináší.

S LLM můžete dělat skvělý produkt, být velmi technický, i ten kód můžete mít kvalitní, ale nenapsat přitom ani řádku kódu. A myslím, že tohle bude pro řadu lidí v té druhé skupině těžké přijmout.

Musíte být vývojáři nebo se jimi postupně stávat

Když jsem dělal prototyp nového webu FrontKonu, Cursor mi chtěl udělat server-side rendering pomocí vlastního generátoru z headless Chrome, kde běželo SPA. Technicky to fungovalo. Prakticky to byl nesmysl – existují mnohem lepší řešení.

Kdyby tenhle návrh dostal někdo bez zkušeností, asi by ho přijal. A měl by problém.

Pokud chcete „vajbit“produkty, dříve či později se musíte stát člověkem, který chápe vývojářské řemeslo.

„Software is eating the world“

Ano, velkou část malinkých aplikací si sami udělají CEO's, markeťáci, samotní klienti… Těch aplikací, které by inženýři sami dělat nechtěli.

Ale software je nenažraný, celý svět ještě zdaleka nesežral. Přijde ohromná vlna softwaru, který dříve vzniknout nemohl, protože to bylo drahé. Tohle vývojáře neohrozí.

Ano, vždycky může přijít průlom, který nevidíme. Ale teď se to neděje. Vývojáři o práci nepřicházejí, minimálně ne hromadně a naráz.

Několik konkrétních tipů ke Cursoru

Pojďme k tomu, jak z vibe-codingu vytěžit maximum.

Režimy v Cursoru

Cursor má čtyři hlavní režimy:

Režim	Změny v kódu	Autonomie	Kdy použít
Agent	Ano (víc souborů)	Maximální	Nová funkce od nuly, refaktoring
Plan	Nejdřív návrh	Střední	Složitá integrace, chcete kontrolu
Debug	Ano (cílené)	Vysoká	Oprava chyb, logy
Ask	Ne (jen text)	Nulová	Konzultace, pochopení kódu

Agent je nejmocnější, ale taky nejdražší na kredity.

Pro běžnou práci často stačí Plan nebo Ask. Osobně vždy novou fíčur začínám s Plan. Iterujeme nad zadáním a pak teprve pouštím Agenta.

Kontextové zkratky

Cursor má užitečné zkratky pro práci s kontextem, které umí zpřesnit to, o čem s modelem mluvíte:

@Codebase – prohledá celý projekt, nejlepší pro komplexní úpravy
@Files / @Folders – cílený kontext, šetří tokeny
@Docs – vložení URL dokumentace
@Web – hledání na internetu

Úplně killer je možnost pustit si v Cursoru prohlížeč a tam vyznačovat konkrétní elementy, které chcete změnit.

Vibe Rules

Tři pravidla pro efektivní práci, které se ze všech pravidel hodí nejvíc:

Dekompozice. Nechtějte vše najednou. Postupujte po malých funkcích a iteracích.
Cursor Rules Vytvořte si .cursorrules v rootu projektu. Trvalé nastavení „vibe“– např. „Piš v TypeScriptu, mluv česky, používej tento styl kódu.“
Sniper vs. brokovnice Pro drobné úpravy použijte Ctrl+K (inline edit) místo přepisování celého souboru přes Composer.

Modely

S modely nemám potřebu moc experimentovat, protože mi krásně vyhovuje výchozí Composer-1, ale občas to přehodím, asi takto:

Default (Composer): Rychlý, pro běžnou práci. Stačí mi v 80 % případů.
Claude Sonnet: Chytřejší, zapnout když se default „zacyklí“. Killer na texty.
Gemini: Pro práci s obrovským kontextem (celý repozitář najednou). Přepínám jen výjimečně.

Flow not found… a nebo tam nakonec je?

Tohle mě překvapilo nejvíc. Bál jsem se, že během vajbení přijdu o radost z tvorby, ale hluboká práce tam je, jen najednou vypadá jinak.

Není to o leštění kódu. Není to o ladění středníků a zavináčů. Je to o směru, architektuře, kontextu. O tvorbě výsledného produktu.

Zadám úkol a čekám. Pak kontroluji, opravuju, směřuju dál. Méně ťukání, více přemýšlení.

A víte co? Překvapivě nechybí hluboká práce a flow. Pořád se dostanu do stavu, kdy nevím o světě a jsem ponořený v problému. Jen ten problém je jiný – není to „jak napsat tuhle funkci“, ale „jak tohle celé navrhnout, aby to dávalo smysl“.

Tohle ale nebude vyhovovat lidem, kteří až tak neprožívají finální produkt, který z nich leze, ale baví se mazlení se s kódem.

Tohle je velké, ale lidi potřebujeme

AI není náhrada vývojářů. Je to multiplikátor.

Lidi pořád potřebujeme. Lidi ovládají a budou ovládat stroje. Doufám.

Lidi potřebujeme pro schůzky, hovory v kuchyňce, celý offline kontext, který je stále obrovský. Pro zodpovědnost a bezpečnost. Pro rozhodnutí, která vyžadují pochopení širšího kontextu firmy a týmu.

Vibe-coding demokratizuje technologie. Vývojáři a technologicky zdatní lidé mají výhodu. Ale musí ji využít.

Na co jsem zapomněl, co mám špatně? Co u vibe-codingu pomáhá vám? Napište mi e-mail nebo komentujte na sociálních sítích: na LinkedInu, X.

Můj rok 2025: podnikatelský, strategický, úspěšný, ale taky úzkostný a hledající formu

Tue, 06 Jan 2026 00:00:00 GMT

Můj rok 2025 byl obratový, takže zásadní. A kdyby byl jen pozitivní, není o čem psát, není se z čeho učit a byla by s tím rokem strašná nuda.

Trošku úzkost ze světa tam venku

Začnu s tou úzkostí v názvu. Určitě ten rozpor někteří z vás zažívají taky, hlavně vy starší. V osobní rovině máte krásný život, vlastně čím dál krásnější, ale stále více vás přepadají chmury nebo dokonce úzkost z dění ve světě, v geopolitice, v širší společnosti.

Začalo to napadením Ukrajiny, pokračuje druhým Trumpovým obdobím, ledy ve společnosti se silně hýbou i u nás. Světlo na konci tunelu je stále slabší. Můj otec na tyhle situace vždycky říká „svět se v prdel obraca“. Smál jsem se, ale teď to sedí. Nebudu se tomu zde dále moc věnovat, ale snažím se tu být upřímný a tohle zarámování mi tady nemůže chybět.

Pojďme raději zaměřit na to, co jsem loni zažíval v osobní a hlavně pracovní rovině.

Z freelancera podnikatelem

Předně jsem se nejspíš už proměnil z freelancera na podnikatele.

Neberte mě špatně, je to jen jedna z mých rolí. Dále zůstávám autorem obsahu, nadšencem do performance a webu, šéfem a spolumajitelem firmy, produkťákem, komunitním týpkem a hlavně tátou od rodiny.

V roce 2025 se u mě proměnilo vnímání sebe sama z pohledu vydělávání peněz. Na volné noze jsem strávil hodně přes dvacet let a setrvačnost tohodle mindsetu je velká.

Být podnikatel na volné noze a podnikatel s vlastní firmou a lidmi v ní je ovšem úplně jiná liga. Mentální a dovednostní přerod z prvního do druhého u mě zabral odhadem pět let.

Pravidelně jsem si během téhle doby pokládal otázku: Co budeš dělat, pokud tvoje podnikání selže nebo tě prostě přestane bavit?

Vždycky jsem si odpovídal, že se prostě vrátím na volnou nohu. Až do druhé poloviny roku 2025, kdy jsem si začal odpovídat, že v takovém případě začnu hledat tvořit podnikání. Slušný, tohle bych do sebe neřekl.

PageSpeed.ONE: poradenství skvěle jede, ale chceme více máknout na produktu

Podnikání, to je pro mě samozřejmě PageSpeed.ONE, skvělý tým lidí, kteří pomáhají firmám zrychlovat jejich weby a zlepšovat tím konverze nebo třeba návštěvnost.

Loni jsme měli výborný rok, kdy jsme i díky novému kolegovi Tomášovi šli i směrem k poradenství ohledně backendu, infrastruktury (trošku nás potrápili v Cloudflare) nebo konkrétně WordPressu. Hodně jsme se zaměřovali i na další platformy, hlavně Shoptet nebo Shopify.

Já se přitom velmi zaměřoval na sales, což vidíme na číslech. A překvapilo mě, jak mě to dokáže bavit.

Pracovali jsme odhadem pro dalších 30-40 nových klientů, nově mezi nimi je například Česká spořitelna, více jsme také loni makali pro Heureku nebo Datart. Boží.

Zároveň jsme budovali naší SaaS službu monitoringu rychlosti. Ten jsme vývojově hezky posunuli, ale neměli jsme na něj tolik času, kolik bychom chtěli. Nejsme první, kdo bolestně zjišťuje, že čas a pozornost je jen jedna a přerod z agenturního na produktové fungování je vždy velmi těžký. Tohle bude hlavní cíl na rok 2026.

FrontKon a Frontendisti.cz: od komunitního k firemnímu uvažování

Další velkým mentální přerod proběhl u Frontendistů. Hodně jsme řešili, jak zajistit budoucí fungování komunity i konference FrontKon, které dosud stálo na velkém dobrovolnickém vkladu mě, Tomáše a Břetíka a mnohých dalších. Řeknu upřímně, že v prvním kvartále jsem byl jednou nohou na odchodu, minimálně z organizace FrontKonu. Zde byla ale potřeba změna mindsetu.

Dostali jsme myslím nový drajv, minimálně já, hlavně do dalších ročníků FrontKonu, který se v roce 2025 stal vlastně větším než celí Frontendisti. Je to akce, která už teď přerůstá komunitu. V hlavách máme věci, které to budou v příštích letech stále více ukazovat. Teda doufám!

Pod Frontendisty jsme s Robinem dostali i náš podcast, a to pod novým názvem FrontKec. Tématicky i strategicky patří ke komunitě, zatímco projekt Vzhůru dolů postupně utlumuju, jak jste si už určitě všimli.

To je samý přerod, samý růst, samé změny a řešení náročných manažerských úkolů. To by bylo divný, kdyby nepřišla nějaká krizička, že? Přišla, to si pište, že jo.

Krizička

Zpětně vidím, že krizička trvala téměř polovinu roku. Krize z přetížení, příliš velkého množství velký témat (nejen pracovních, ale i osobních), nedostatku hluboké práce, následné zvýšené nespavosti, což jsou alarmy, které když bzučí, je potřeba rychle něco měnit.

Už jsem to v kariéře zažil několikrát, obvykle v době svých různých freelancerských přerodů. Bylo to například v době, kdy jsem začal prodávat školení, psal jsem některou z knížek nebo když přišel covid a velkou část mé obživy přizabil.

Vím, že vždy existuje cesta ven (meta pohled na svůj čas, sebeanalýza s knížkami v ruce, změna způsobu organizace, razantní ukončení některých činností), ale tentokrát jsem reagoval docela pomalu, takže jsem se trápil zbytečně dlouho. Nevím proč, ale řekl bych, že tentokrát to přetížení bylo tak velké, že blokovalo alarmy. Jo, a taky už jsem pěkně starej.

(Ne)forma

Když se dívám na to, co jsem chtěl v roce 2025 změnit, posunout nebo čeho dosáhnout, můžu být hodně spokojený. Až na jednu věc a to je moje fyzická forma.

Stres dělá svoje, věk taky, metabolismus už není co býval a moje klasické údržbové aktivity (kratší běhání, chůze do práce a z práce) evidentně přestaly stačit.

Toto budu letos muset taky vyřešit, takže jsem se poprvé v životě přidal k haldě trapáků, kteří chtějí od ledna zhubnout a zlepšit si formu.

Mimochodem, pokud vás zajímají kulturní tipy na četbu, poslech nebo třeba koukání, mrkněte se na moje osobní nebo pracovní doporučení za roku 2025.

„Rok 2025 byl skvělý!“

Jeden z projektů roku bylo dostat staršího syna na střední školu. Pokud nemáte děti na konci základky nebo nejste v Praze, neumíte si představit, co to obnáší. Zájemců o gymply je hodně, míst velmi málo.

Nakonec to dopadlo skvěle, dostal se na školu druhé volby, je tam hodně spokojený a taky prošel jakýmsi přerodem, když se tam velmi dobře chytl a je celkově z pohledu přípravy na školu samostatný.

Na Silvestra ráno se Honza probudil a volá „Rok 2025 byl skvělý!“. Se ženou na sebe mrkneme. To je fakt super, domýšlíme si, jak to celé dokáže ocenit. Jak dokáže ocenit, že se s vypětím svých i našich sil dostal na gympl, i to, že si tam docela dobře vede.

„Rok 2025 byl skvělý“, volá znovu a dodává: „…protože jsem začal konečně chlastat a hulit trávu!“

Takže i vám, milé čtenářky, milí čtenáři, do roka 2026 přeju, abyste si vždy plnili sny svoje a ne sny jiných lidí.

Chcete komentovat, vynadat mi nebo mě pochválit? Pište ideálně k postu na LinkedInu, na X nebo na Facebooku. Díky!