Jak řídit tým v době vibe codingu a generativní AI
Jak nastavit tým, code review a odpovědnosti v době, kdy kód stále častěji píše člověk společně s AI?
Pár let zpátky byla největším pomocníkem programátora chytrá nápověda v IDE a dobře zdokumentovaná knihovna. Dnes vývojáři stále častěji neprogramují v pravém slova smyslu, ale spíš vedou dialog s umělou inteligencí. Popisují svůj záměr a AI nástroje jim navrhují řešení: Copilot přímo v IDE doplňuje nebo generuje kód, zatímco agentní nástroje typu Codex už zvládají pracovat i na větších vývojových úkolech. Nastala éra generativní AI a vibe codingu. A ta nejspíš jen tak neskončí.
Proč by to mělo být manažerské téma
Pokud vedeš tým jako team lead, engineering manager nebo CTO určitě vnímáš tuhle zásadní změnu ve vývoji softwaru. V tom, jak se software tvoří, kdo za něj nese odpovědnost a jaká rizika při tom vznikají.
Tým může vyvíjet obrovskou rychlostí, ale bez správného vedení si koleduje o zmatek a bezpečnostní mezery. Ignorovat tento trend je ale jako snažit se v roce 2010 zakázat v týmu Git. Je potřeba ho pochopit, uchopit a nastavit mu pravidla.
Dnes se podíváme na to, co se mění, kde se ukrývají rizika a jak přizpůsobit procesy, aby AI ve vývoji skutečně pomáhala.
Co je to „vibe coding“
Samotný pojem možná zní trochu neformálně, ale dobře vystihuje podstatu změny. Dřív musel vývojář přesně vědět, jak něco naprogramovat. Musel znát syntaxi, algoritmy i specifika dané knihovny. Dnes mu stále častěji stačí vědět, co chce udělat, a popsat to přirozeným jazykem.
Představ si to na jednoduchém příkladu. Dřív by vývojář ručně napsal funkci, která vyfiltruje aktivní uživatele a vrátí jejich e-mailové adresy.
Dnes často stačí napsat komentář:
// funkce vezme pole uživatelů, vyfiltruje aktivní uživatele a vrátí pole jejich e-mailů seřazené abecedně
…a GitHub Copilot nebo jiný AI nástroj navrhne hotové řešení.
V užším smyslu se ale vibe codingem nemyslí jen běžné používání Copilota jako našeptávače, ale spíš práce, kdy vývojář výrazně deleguje tvorbu kódu na AI a sám se posouvá do role zadavatele, kontrolora a iterátora.
Programátor už není ten, kdo nutně píše každý řádek kódu ručně. Stává se spíš člověkem, který AI zadává úkoly, vybírá z návrhů a ručí za finální výsledek. Dopad AI nástrojů na vývojáře se přitom neřeší jenom optikou rychlosti, ale také kvality, kontroly výstupů a celkové zkušenosti s vývojem.
Proč by tě to jako manažera mělo zajímat? Kompletně to mění dynamiku práce v týmu. Mění se potřebné dovednosti, povaha code review, způsob zaučování juniorů i očekávání od seniorů. Produktivita už se neměří v počtu napsaných řádků – to byla vždycky špatná metrika, ale teď už je úplně absurdní. Mnohem důležitější je kvalita zadání a kritické myšlení při přebírání vygenerovaného kódu.
Rychlost na prvním místě, ale za jakou cenu?
Nástup AI nástrojů přináší obrovské zrychlení. Rutinní úkoly, které dříve zabraly desítky minut, jsou dnes hotové za pár sekund.
Kde AI skutečně pomáhá:
- Boilerplate kód: Generování kostry pro nové komponenty, controllery, datové modely nebo konfigurace.
- Jednoduché algoritmy: Potřebuješ funkci na validaci IČO nebo formátování data? AI to zvládne během chvilky.
- Psaní unit testů: AI může pomoct rychle připravit unit testy pro existující funkce. (Sama o sobě ale nezaručí kvalitní testovací strategii ani smysluplné pokrytí.)
- Práce s daty: Transformace datových struktur, parsování JSONu nebo CSV, psaní jednoduchých SQL dotazů.
- Prototypování a učení: Chceš si rychle vyzkoušet novou knihovnu? Zeptej se AI na základní příklad použití.
Tohle všechno zní skvěle. Senioři se můžou věnovat složité architektuře místo otrockého přepisování kódu a junioři se cítí produktivnější. Jenže každá mince má dvě strany. Nově nabytá rychlost s sebou nese vážná rizika, která musíš jako lídr aktivně řídit. Ve vývoji totiž pořád platí, že rychlost bez kontroly kvality může přijít pěkně draho.
Nová rizika, která by se neměla podcenit:
- Problém „černé skříňky“: Vývojář sice dostane funkční kód, ale úplně nerozumí tomu, proč funguje zrovna takhle. Zná výsledek, ale ne cestu. To je obrovský problém ve chvíli, kdy je potřeba kód ladit, optimalizovat nebo rozšířit.
- Halucinace a subtilní chyby: AI modely si občas „vymýšlejí“. Vygenerují kód, který na první pohled vypadá správně, projde základními testy, ale obsahuje skrytou logickou chybu, špatně ošetřuje edge cases nebo má katastrofální dopad na výkon pod zátěží.
- Bezpečnostní díry: AI se učí na obrovském množství veřejného kódu z GitHubu a dalších zdrojů. To znamená, že se učí i na kódu, který je plný bezpečnostních zranitelností. Bez důkladné kontroly může navrhnout třeba zastaralou kryptografickou funkci, slabou validaci vstupů nebo knihovnu se známou zranitelností.
- Nízká konzistence: Když pět různých vývojářů požádá AI o vyřešení stejného problému, pravděpodobně dostanou pět různých řešení. Pokud nemáš pevně stanovené coding standards a nehlídáš jejich dodržování, codebase se rychle promění v nesourodý a neudržovatelný guláš.
Nová éra code review
S nástupem AI se role code review stává naprosto klíčovou a její povaha se dramaticky mění.
Dřív se review často zaměřovalo na formální správnost: dodržení coding style, překlepy v názvech proměnných, zjevné logické chyby. Většinu toho dnes za nás hlídají automatické nástroje jako lintery a statická analýza.
Při použití AI se code review posouvá na vyšší úroveň. Reviewer už není jenom korektor, ale spíš detektiv a architekt v jednom. Jeho úkolem je ověřit, že autor a jeho AI asistent skutečně pochopili zadání a zvolili správné řešení.
Na co se zaměřit při code review generovaného kódu:
- Odpovídá kód skutečně zadání? AI mohla špatně interpretovat záměr popsaný v komentáři. Reviewer musí znát kontext a ověřit, že kód řeší správný byznys problém.
- Proč zrovna tohle řešení? Je vygenerovaný algoritmus efektivní? Není zbytečně složitý? Neexistuje v našem stávajícím kódu už podobná utilita, kterou by šlo použít? Autor pull requestu musí být schopen obhájit, proč je navržené řešení nejlepší.
- Jsou ošetřeny všechny edge cases? AI často generuje „happy path“ kód. Co se stane, když vstup bude null, prázdné pole nebo nevalidní formát? Reviewer musí myslet jako tester a hledat slabá místa.
- Je to bezpečné? Jakákoliv práce s uživatelským vstupem, databází nebo externími API musí projít důkladnou bezpečnostní kontrolou. Právě tady AI často selhává.
- Rozumí autor kódu, který odevzdává? Během review se ptej: „Můžeš mi vysvětlit, jak funguje tahle část?“ Pokud autor nedokáže uspokojivě odpovědět, je to varovný signál, že se na AI spoléhá až příliš a nerozumí kódu, za který nese odpovědnost.
Základní pravidlo musí být jasné a nekompromisní. Vývojář je 100% zodpovědný za veškerý kód ve svém pull requestu, ať už ho napsal sám, nebo mu ho vygeneroval Copilot.
Jak pracovat s juniory v týmu
Pro juniorní vývojáře je generativní AI dvousečná zbraň. Na jednu stranu jim umožňuje být produktivní od prvního dne. Zvládnou úkoly, na které by si dřív netroufli. To posiluje jejich sebevědomí a zrychluje zapojení do týmu. Můžou se rychleji učit tím, že si nechají vysvětlit kus kódu nebo vygenerovat příklady.
Na druhou stranu hrozí obrovské riziko, že se z nich stanou jen „operátoři AI“. Naučí se skvěle psát prompty, ale nenaučí se programovat. Vybudují si závislost a neosvojí si základy algoritmického myšlení, ladění a hlubšího porozumění tomu, jak věci fungují „pod kapotou“. Když pak narazí na problém, kde AI selže nebo vygeneruje příliš komplexní kód, jsou naprosto ztracení.
Jako lídr máš za jejich profesní růst zodpovědnost. Tvým úkolem je zajistit, aby AI používali jako nástroj pro učení, ne jako náhradu za myšlení.
Jak pracovat s juniory v době AI:
- Onboarding s pravidly: Proces onboardingu musí nově obsahovat jasnou kapitolu o používání AI nástrojů. Vysvětli, kdy je vhodné je použít (například na testy) a kdy je naopak lepší psát kód ručně, aby se junior naučil základy.
- Úkoly „bez AI“: Pravidelně jim zadávej menší, dobře definované úkoly s explicitním pokynem, aby je zkusili vyřešit bez pomoci AI. Cílem je budovat jejich schopnost řešit problémy od nuly.
- Párové programování: Spoj juniora se seniorem. Senior mu může ukázat, jak AI efektivně používat, jak ověřovat její výstupy a kdy jí naopak nevěřit. Je to nejlepší způsob, jak předat zkušenosti a kritické myšlení.
- Uč je ptát se „proč“: Veď je k tomu, aby se u každého vygenerovaného bloku kódu ptali: Proč AI zvolila zrovna tuhle knihovnu? Jaké jsou alternativy? Jaké to má výkonnostní dopady?
Praktické kroky pro lídry IT týmů
Aby AI týmu opravdu pomáhala, musíš jednat proaktivně. Nestačí jen doufat, že si s tím tým nějak poradí. Potřebuješ jasná pravidla a upravené procesy.
1. Vytvoř jasné AI guidelines
Sepiš jednoduchý, srozumitelný dokument, který bude sloužit jako firemní standard pro používání AI. Měl by obsahovat:
Povolené nástroje: Definuj, které nástroje jsou schválené – například firemní Copilot, interní model nebo schválený enterprise workspace – a které postupy jsou zakázané, třeba vkládání zdrojového kódu, zákaznických dat nebo API klíčů do neschválených externích AI nástrojů.
Zacházení s citlivými daty: Zlaté pravidlo zní nikdy, za žádných okolností, nekopírovat do externích AI nástrojů firemní zdrojový kód, data zákazníků, API klíče ani jakékoliv jiné duševní vlastnictví.
Definice odpovědnosti: Znovu zdůrazni, že za finální kód je vždy plně odpovědný vývojář.
Doporučené postupy: Dej týmu vědět, na jaké typy úkolů je AI ideální a kde je naopak nutná zvýšená opatrnost (bezpečnost, jádro byznys logiky nebo optimalizace výkonu).
2. Uprav procesy
Code review: Zaveď pravidlo, že v popisu pull requestu musí být jasně označeno, které části kódu byly z velké části vygenerovány AI. To dá reviewerovi signál, aby jim věnoval zvláštní pozornost.
Testování: AI může pomoct napsat spoustu unit testů, ale nesmíš se na ně spoléhat slepě. Dej důraz na integrační a end-to-end testy, které ověřují spolupráci více komponent a dokážou odhalit chyby, které unit testy obejdou.
Dokumentace: Motivuj tým, aby využíval AI k rychlejšímu psaní dokumentace. Zároveň ale trvej na tom, že dokumentace musí být vždy zkontrolovaná člověkem, aby byla přesná a srozumitelná. Důležitější než kdy dřív je dokumentovat záměr a důvody architektonických rozhodnutí.
3. Změň očekávání od jednotlivých rolí
Role v týmu se postupně promění. Komunikuj to otevřeně.
Senior: Jeho hodnota už není v rychlosti psaní kódu. Je v hlubokém porozumění systému, schopnosti navrhovat robustní architekturu, mentorovat ostatní a provádět důkladná code reviews, kde odhalí i chyby AI.
Medior: Stává se klíčovým hráčem v každodenní exekutivě. Měl by vynikat v efektivním používání AI nástrojů, ale zároveň mít dostatečně pevné základy, aby dokázal jejich výstupy kriticky zhodnotit a převzít za ně odpovědnost.
Junior: Jeho hlavním cílem je budovat pevné základy a učit se kriticky myslet. AI je pro něj akcelerátor učení, ne náhrada.
Generativní AI a vibe coding představují novou realitu vývoje softwaru. Jako lídr nemáš na výběr, jestli tuhle změnu přijmeš, ale pouze to, jak se na ni připravíš. Týmy, které se naučí s AI spolupracovat chytře, bezpečně a zodpovědně, získají obrovskou konkurenční výhodu. Ty, které ji začnou používat chaoticky a bez pravidel, si zadělávají na vážné problémy.
Tvoje role se tím posouvá. Už nejsi jen manažer lidí a projektů. Stáváš se manažerem komplexního systému, kde spolupracují lidé a stroje. A vést takovou spolupráci vyžaduje nové dovednosti, nové procesy a nový způsob myšlení. Investice do rozvoje těchto kompetencí, ať už u sebe, nebo u klíčových lidí v týmu, je to nejlepší, co můžeš pro budoucnost týmu udělat.
Autor: Lucie Dvořák
