Ještě programuješ, nebo už jen uklízíš?

Ahoj,

v době, kdy umělá inteligence chrlí kód, opravuje za nás testy a analyzuje výkon webu, se může zdát, že role vývojáře či testera slábne. Opak je ale pravdou. Kdo jiný rozhodne o správné strategii cachování, aby byl web opravdu rychlý? Kdo nastaví pravidla a uklidí nepořádek, který po sobě AI může zanechat? A kdo se zamyslí nad tím, jestli zelené testy skutečně znamenají spokojeného uživatele?

Právě teď je klíčové posunout se z role "toho, kdo píše kód" na "toho, kdo přemýšlí" a řídí stále mocnější nástroje. Tento díl je přesně o tom - o převzetí kontroly, ať už nad cachováním, bezpečnostními praktikami, nebo samotnou AI. Tak neváhej a vrhni se na první video.

Proč je to tak pomalý?

Věčná otázka rychlosti webu má často jednoduchou odpověď: cachování. Místo neustálého stahování dat z druhého konce světa je mnohem efektivnější si je na chvíli nechat po ruce. V přednášce z FrontKonu se dozvíš, že klíčem je rozlišovat mezi měnitelnými (mutable) a neměnnými (immutable) soubory. Zatímco neměnné soubory, jako jsou JavaScript a CSS s hashem v názvu, můžeš bezpečně cachovat na dlouho, u měnitelných souborů, jako je index.html, musíš být opatrnější. Tak neváhej a koukni na video, ať víš jak správně položit základy pro web, co fakt lítá.

Už víš, že cache je základ, ale co když chceš mít nad cachováním absolutní kontrolu a postavit aplikaci, která funguje i offline? Přesně od toho jsou tu Service Workery. Představ si je jako chytrého prostředníka (proxy) přímo v prohlížeči, který zachytává síťové požadavky a rozhoduje, co s nimi udělá. Nejlepší je, že Service Worker funguje skvěle s existujícím cacheováním a hlavičkami. Během své install fáze si může dopředu nachystat všechny potřebné soubory (tzv. pre-caching) a díky tomu pak bleskově servírovat stránky, i když je síť nedostupná. Tímto způsobem můžeš vytvořit robustní offline-first zážitek, který se vyrovná nativním aplikacím.

Měli by programátoři programovat?

Otázka, zda nás AI nahradí, už dávno není sci-fi. Dokonce nás jednu dobu neuvěřitelně děsila. Podívej se na přednášku z Frontkonu, kde se dozvíš, že realita je mnohem zajímavější. Zatímco AI dokáže chrlit kód neuvěřitelnou rychlostí, studie paradoxně ukazují, že vývojáři s ní mohou být pomalejší. Proč? Protože AI sice píše, ale nepřemýšlí. Zanechává za sebou nepořádek, bezpečnostní díry a spoustu práce pro seniory, kteří pak místo mentorování juniorů tráví čas "uklízením". Proto se pojď posunout z role "toho, kdo píše kód" na "toho, kdo přemýšlí". Využívej AI jako nástroj, ne jako náhradu. Protože budoucnost nepatří těm, co umí jen kódit, ale těm, kteří rozumí kontextu, uživatelům a strategii.

Bezpečnost především

Ať jsi tester, vývojář, vibecoder nebo jakkoliv pracuješ ve vývoji. Měl*a bys dodržovat bezpečnost kódu. Jednou z nejzákladnějších pouček je nemít na pevno v kódu hodnoty jako hesla, klíče a další důležité proměnné, které by někdo mohl zneužít. Proto se se extrahují do souborů bokem, který se necommituje. Je nastavený v .gitignore, takže ho git neřeší. Článek je zaměřený primárně na testery, ale je přínosný pro všechny, kteří pracují s kódem.

Autor zmiňuje nástroj dotenv-safe, který jsme vyhodnotili jako trošku pochybnou věc. Jen zaručuje, že env variables jsou definované, ale ne jakého typu. Místo toho bychom chtěli doporučit T3 Env: https://env.t3.gg/docs/introduction.

Nech AI ať kliká za tebe

Model Context Protocol je otevřený standard, který dovoluje AI aplikacím interagovat s jinými aplikacemi, jako je například prohlížeč. V podstatě se vystaví sada funkcí, které AI může používat. S Playwright MCP můžeš s prohlížečem komunikovat pomocí přirozeného jazyka a nechat AI, aby za tebe proklikla, otestovala web, a dokonce sama napsala testovací kód. Zároveň to ale nemusíš používat jen pro testování.

Jenom pozor na to, že zrovna Playwright MCP dává k dispozici fakt hodně toolů, což docela dost žere kontext. Článek je lehce starší (4 měsíce), takže autor nezmiňuje nejnovější modely. Ale to nevadí. MCP nejsou zavislá na modelu.

Co kdyby AI za tebe proklikala web a navíc odhalila i proč je pomalý. Přesně to umožňuje Chrome DevTools MCP. Představ si, že AI v reálném čase dostane přístup k DevTools. Spustí v Chromu hloubkovou analýzu, změří Core Web Vitals a navrhne konkrétní úpravy pro zrychlení stránky. Zároveň to není vše, co Chrome DevTools MCP umí. Tak neváhej a vrhni se na článek. Najdeš tam i porovnání s Playwrigt MCP.

Jak Playwright MCP, tak i Chrome MCP nemusíš používat pouze k testování. Někteří vibecodeři je používají k tomu, aby nemuseli neustále dělat screenshoty a psát “je to hnusný”. Místo toho nechají AI iterovat stále dokola s přístupem k prohlížeči, aby si aplikaci proklikala sama.

Jakou hodnotu testování přineslo

Zelené testy, 100% pass rate, a přesto v produkci zase něco hoří? Tenhle pocit zná asi každý z nás. Podle autorky článku si jako testeři a vývojáři často lžeme do kapsy. (Pozn., redakce: My si myslíme, že to dělá celý tým i management.) Měříme totiž metriky, které sice vypadají dobře na papíře (jako počet spuštěných testů), ale neříkají vůbec nic o skutečné kvalitě, kterou vnímají naši uživatelé. Pojďme zkusit změnit pohled z procesu na dopad. Dostaneme se tím k jiným otázkám.

AI léčí bugy

Opravy E2E testů můžou být občas pěkně otravné. Například se změní název tlačítka a my můžeme upravovat celý test. Proto přichází s myšlenkou samoopravných testů. Kdy dáš AI spoustu informací - testovací script, místo, kde spadlo, chybovou hlášku atd. - a AI se to pokusí opravit a udělá pull (merge) request, který už jen schválíš. V článku je myšlenka vysvětlena, ale trošku nedotažená. Autor opomenul, že ten test bude stále padat, protože se opravil jen jeden řádek. Takže to bude muset znovu běžet skrz self-healing pipeline - kvůli tomu, že nebylo dodáno dostatek kontextu.

Nestihl*a jsi předchozí díly? Máme archiv.

Pokud by sis chtěl*a o některém článku popovídat, rádi tě uvítáme na našem Discordu v sekci diskuzní fórum v tématu JIT.