Tester jako hlavní realizátor projektu

Kontext a vznik projektu 

Celý projekt začal poměrně nenápadně. Při rozhovoru s hráčským manažerem ze Setka Cupu vyšlo najevo, kolik času a energie stojí ruční příprava pingpongových turnajů. Práce se sběrným Excelem, procházení přihlášek a skládání turnajů znamenaly mnoho hodin úmorné práce. Navíc často pod časovým tlakem, což se projevovalo chybami i kolísající kvalitou turnajů. A právě tahle zkušenost se pak stala impulsem pro vznik projektu. 

V minulosti už existoval pokus řešit situaci dodávkou komplexního systému pro správu celé organizace, který by zastřešil všechny její procesy cestou klasického vývoje softwaru. Oslovené softwarové firmy odhadly řešení někde mezi 0,5–1 mil. Kč podle konkrétního rozsahu, což bylo nad možnosti klienta a nějakou dobu pak ležel program u ledu. 

S příchodem tehdy nových vibe-code nástrojů však padl návrh zkusit nástroj vytvořit jinak. S pomocí AI a bez klasického týmu. A zároveň si odpovědět na dvě zásadní otázky. Jde to postavit levněji? A zvládne to vůbec zvládne jeden člověk, který doteď pracoval jen v roli testera? 

Minimální prvotní požadavek byl poměrně jednoduchý, tím byl polo-automatizovaný generátor losu. Jakmile však řešení prokázalo svou funkčnost, začaly se postupně přidávat další a další funkcionality. Zpočátku ne nějak plánovaně dopředu, spíš přirozeně podle toho, co zrovna dávalo smysl. Postupně se z MVP stal nástroj, který dnes pokrývá větší část operativy a postupně se rozšiřuje směrem ke kompletnímu řešení správy turnajů, jaké bylo původně poptávané u softwarových dodavatelů. A přitom za zlomek původní ceny. 

Hypotéza a očekávání 

Na začátku byla poměrně jasná hypotéza: pokud má být v menším projektu s podporou AI jedna role nositelem celého vývoje, je právě tester na nejvhodnější role? 

Ne kvůli tomu, že by byl dobrý programátor nebo architekt. Ale kvůli tomu, jak přemýšlí. Tester je zvyklý řešit věci v kontextu, a ne jen jednu konkrétní část. Přirozeně se pohybuje napříč celým SDLC a hlavně si průběžně ověřuje, jestli to, co vzniká, dává smysl. Má tedy představu o tom, jak mají vypadat vstupy a výstupy jednotlivých fází a jak udržet kvalitu napříč celým procesem vývoje. 

Cílem tedy nebylo jen dodat funkční aplikaci, ale ověřit, jestli tenhle přístup funguje i v praxi. Jestli tester zvládne zastat roli analytika, projektového manažera, UX designera i developera a jestli právě jeho přístup nepovede ve výsledku k lepšímu řešení než klasické rozdělení rolí v týmu. 

Technické řešení 

Aplikace běží jako SaaS na platformě bolt.new, frontend v Reactu, backend v Node.js, programovací jazyk TypeScript, databáze Supabase. Prostě standardní webový stack pro vibe-code projekty. 

Tester tady nefunguje jako někdo, kdo přijde na konci a „zkontroluje výsledek“. Spíš jako někdo, kdo ten výsledek průběžně formuje. Zadává kontext, sleduje, co AI vrací, a hlavně rozpoznává, kdy to dává smysl a kdy ne. V praxi to znamená, že kvalita se neřeší až na konci, ale v každém kroku. 

Vývojový proces 

Vývoj běžel iterativně v měsíčních sprintech. Ne proto, že by to byl nějaký dogmatický Scrum, ale čistě z praktických důvodů. Hlavně kvůli práci s tokeny, tedy jejich měsíčnímu resetu a rovněž pak kvůli rozdělení práce do menších celků. 

Každá iterace měla v zásadě stejný průběh. Nejprve pochopit problém, navrhnout řešení, které splňuje klientovu představu a rovněž dává smysl z pohledu uživatele, nechat AI vygenerovat implementaci a hned ji ověřit v praxi.  

Zásadní změna ale přišla ve chvíli, kdy AI přestala být používaná jen jako „generátor kódu“. Na začátku fungoval přístup typu „udělej tohle“. Výsledek často nějak fungoval, ale vedl k většímu počtu iterací, oprav a občas i slepým uličkám. 

Postupně se ukázalo, že mnohem lepší přístup je AI zapojit do celého SDLC. Nejen do implementace, ale už do samotného přemýšlení nad problémem, návrhu řešení a následné validace. Najednou začal výstup víc odpovídat tomu, co bylo původně zamýšlené. Ubývalo iterací i rollbacků a celkově se zvýšila kontrola nad tím, jak produkt vzniká. 

Měřitelné přínosy projektu 

Nejviditelnější přínos je u samotné přípravy losu. Původně šlo o zhruba 12 - 16 hodin práce rozdělené ve dvou dnech. Dnes se ten samý výstup zvládne za 2 - 4 hodiny. 

Důležité ale je, že nejde jen o absolutní čas. Původní proces vyžadoval souvislou koncentraci a byl hodně citlivý na chyby. Jakmile se člověk práci na chvíli přerušil nebo ztratil kontext, často to znamenalo zdlouhavé navazování na ztracenou nit. Dnes je ten proces mnohem flexibilnější. Manažer ho může v jakékoliv fázi přerušit, vrátit se k němu později a kombinovat ho se svými dalšími povinnostmi. 

Vedle toho došlo i k dalším posunům. Část podpůrných činností, na kterých se dřív podíleli další lidé, se automatizovala. Zlepšila se průměrná kvalita jednotlivých turnajů, a to hlavně díky tomu, že se začal zohledňovat rating a H2H hráčů v raných fázích tvorby losu, takže zápasy pak začali být mnohem vyrovnanější a zajímavější. Tento detail bylo při manuálním zpracování takřka nemožné vzít v potaz. 

Zároveň je důležité zmínit, že od nasazení se neobjevil žádný zásadní produkční incident. Především díky kladenému důrazu na kvalitu v každé fázi vývojového cyklu, detailní test analýze, přípravě testovacích scénářů již v raných fázích vývoje a důkladnému testování. Tento fakt pak dovolit plynulejší postupné přidávání dalších funkcionalit, které práci uživatele čím dál více zjednodušovaly a automatizovaly. 

Výzvy a omezení přístupu 

Tento přístup má samozřejmě svoje limity. Nejvíc se to ukázalo ve chvíli, kdy aplikace začala růst. 

Architektura, která vznikala postupně a spíš organicky, přestala být přehledná. A to nejen pro člověka, ale i pro AI. V jednu chvíli už bylo jednodušší část věcí přepsat než se snažit dál stavět na něčem, co se začalo rozpadat. 

Výsledkem toho bylo jedno téměř kompletní přepsání codebase a architektury programu, rozdělené do několika menších refaktoringů. Jejich cílem bylo hlavně zlepšit orientaci. A to nejen aby se v tom dalo dál smysluplně pracovat a aby AI byla schopná efektivně generovat požadované změny. 

Specifická je i samotná práce s AI. Člověk si rychle uvědomí, že to není čistá exekuce. Často jde spíš o hledání správného způsobu, jak věc popsat. Občas to připomíná spíš brainstorming než zadávání úkolu. Někdy to vede k frustraci, ale většinou to skončí tím, že člověk postupně zpřesní kontext a výsledek se výrazně zlepší. 

Zároveň platí, že čím komplexnější problém, tím víc roste náročnost na řízení celého projektu jedním člověkem. Proto tento model dává největší smysl u menších a středně velkých projektů. 

Srovnání s klasickým vývojem 

Klasický vývoj má svoje silné stránky. Hlavně ve své škálovatelnosti, robustnosti, kvalitě kódu a rozdělení odpovědností. Pořád je to nejlepší volba u větších a komplexních systémů, kde se bez specializace jednotlivých rolí projekt neobejde. 

Tento projekt ale ukazuje, že existuje i jiný přístup. Rychlejší, flexibilnější a s nižší vstupní investicí. Cena za to je, že kód není vždy ideálně strukturovaný a část technického dluhu se řeší zpětně. 

Z pohledu uživatele ale v tomto případě kvalita neutrpěla. Program je již několik měsíců v produkci, funguje, UX dává smysl a systém je stabilní. To je do velké míry dané tím, že celý vývoj byl od začátku řízený QE myšlením, tedy průběžnou validací a hledáním slabých míst již v raných fázích projektu. 

Klíčová zjištění 

Nejzajímavější zjištění z celého projektu není to, že AI umí generovat kód. To už dneska není překvapení. Ale mnohem zajímavější je, kdo ten proces dokáže nejlépe řídit. 

Ukázalo se, že tester má v tomhle kontextu přirozenou výhodu. Ne proto, že by byl nejlepší v každé jednotlivé roli, ale protože se přirozeně pohybuje mezi nimi. Vnímá souvislosti, hlídá kvalitu průběžně a dokáže včas zachytit, když se řešení začíná odchylovat od původního záměru. 

Developer by pravděpodobně vytvořil technicky čistší řešení, ale nemusel by včas zachytit problémy z pohledu uživatele. Analytik nebo projektový manažer by dobře definovali problém, ale hůř by kontrolovali samotnou implementaci a limity AI. Tester stojí někde mezi. A právě tahle pozice se v AI-assisted vývoji ukazuje jako klíčová. 

Druhé důležité zjištění se týká samotné práce s AI. Největší přínos nepřichází ve chvíli, kdy AI dostane konkrétní úkol, ale když se zapojí do celého procesu vývoje. Od pochopení problému, přes návrh řešení až po validaci. V tu chvíli se výrazně zlepšuje kvalita výstupu a zároveň klesá potřeba neustálých oprav. 

Závěr 

Tenhle projekt není důkaz, že klasický vývoj je špatně nebo zbytečný. Spíš ukazuje, že vedle něj existuje alternativní model, který dává smysl v jiném kontextu. 

Konkrétně tam, kde: 

• je dobře definovaný rozsah projektu 
• není potřeba řešit složitou škálovatelnost 
• a důležitá je rychlost, flexibilita a kontrola nad výsledkem. 

V takovém prostředí se kombinace zkušeného testera a AI nástrojů ukazuje jako překvapivě efektivní. Ne jako náhrada za klasický tým, ale jako jiná cesta, která v určitých situacích funguje lépe, než by se mohlo na první pohled zdát.