Jak proměnit AI ve skutečného partnera ve vývoji — zkušenosti Mykoly Remeslennikova, Payments Core Team Leada v GR8 Tech

Zavádění AI v prostředí regulovaném PCI DSS, které zároveň musí splňovat vysoké nároky na výkon, není o slepém následování trendů. Tato cesta začala spíše skepsí. Postupně se proměnila v řízené experimenty a dnes je běžnou součástí každodenní inženýrské praxe.

Foto: Alexandra_Koch / pixabay.com

V GR8 Tech jsme si položili konkrétní otázku: může AI reálně zlepšit způsob, jakým navrhujeme, ověřujeme a dodáváme komplexní systémy — aniž bychom slevili z bezpečnosti a kvality? Klíčovou roli v tom sehrál Mykola Remeslennikov, vedoucí Payments Core týmu, který k AI nepřistupoval jako technologický nadšenec, ale jako architekt hledající ověřitelná a praktická řešení.

Když se ohlédneš zpět — co tě přivedlo k prvním experimentům s AI nástroji v každodenní práci v GR8 Tech?

„Ještě před osmi měsíci jsem byl k AI nástrojům pro programování dost skeptický. Vnímal jsem je jen jako pokročilejší autocomplete a nevěřil jsem, že zkušení vývojáři něco takového potřebují. Navíc se mi nechtělo platit za něco, co — jak jsem si myslel — nepřinese reálnou hodnotu. Zlom přišel ve chvíli, kdy jsme se rozhodli AI nástroje v GR8 Tech skutečně otestovat. Kvůli PCI DSS jsme nemohli používat libovolná veřejná řešení — potřebovali jsme enterprise nástroj, který nevyžaduje dodatečnou infrastrukturu. Tak jsme se dostali k Amazon Q Developer. V té době jsem byl zahlcený code review a nainstaloval jsem ho spíš z nutnosti než ze zvědavosti. Ze začátku to dopadalo přesně podle očekávání — review bez znalosti doménového kontextu často končilo komentářem typu ‚Looks good to me‘. Co mě ale překvapilo, byla schopnost asistenta pracovat s nástroji jako glab konzole a fungovat poměrně autonomně. Místo toho, abych to zavrhl, jsem se rozhodl naučit se s tím pracovat správně.“

Kdy sis uvědomil, že AI může být skutečným partnerem ve vývoji, a ne jen nástrojem na zvýšení produktivity?

„Přicházelo to postupně. AI začala navrhovat lepší názvy metod, upozorňovat na null reference a generovat testy, které by mě samotného nenapadly. Skutečný zlom přišel s prací založenou na specifikaci pomocí Amazon Kiro. Popisoval jsem problém a AI navrhla přístup, vytvořila návrh architektury a po doladění vygenerovala i technickou dokumentaci. Bylo to jako strukturovaná diskuse o architektuře. Když jsme se shodli, dokázala připravit i detailní plán implementace krok za krokem. Tehdy mi došlo, že se něco zásadního změnilo. Nejde o nahrazování vývojářů — jde o spolupráci. Jsou momenty frustrace, ale i chvíle, kdy máš opravdu pocit, že pracuješ s partnerem.“

Často mluvíš o přístupu „fail fast“ — jak v tom AI pomáhá?

„Fail fast znamená rychle ověřit nápady, než do nich investujeme větší množství zdrojů. V rané fázi architektonických rozhodnutí je těžké odhadnout dopady — a tady je AI hodně užitečná. Proof of concept nemusí být dokonalý, hlavní je, aby fungoval. Nedávno jsem chtěl ověřit, jestli nová cache strategie zlepší odezvu API. Místo několika dní práce jsem požádal AI o rychlý prototyp. Za půl hodiny jsem měl funkční řešení, které jasně ukázalo zlepšení výkonu. Díky tomu jsme mohli pokračovat s větší jistotou. AI jednoduše snižuje cenu experimentování.“

Mnoho inženýrů naráží na „prázdnou stránku“ při startu nového projektu — změnila to AI?

„Rozhodně. Začátek projektu bývá vyčerpávající kvůli všem těm věcem okolo: logging, metriky, health checky, autorizace, kontejnerizace, konfigurace databáze. Než to všechno připravíš, jsi unavený. Dřív pomáhaly šablony, ale rychle zastarávají. AI tenhle problém výrazně zmírňuje. To, co dřív trvalo dvě až tři hodiny, teď zvládnu za 15–20 minut. AI vygeneruje základ logování, autorizace, konfiguraci kontejnerů i práci s databází — a já se můžu soustředit na byznys logiku. Výrazně to omezuje prokrastinaci a pomáhá rychleji se dostat do pracovního flow.“

Při tolika AI nástrojích — jak si vybíráš ten správný přístup?

„V zásadě jde o volbu mezi agenty integrovanými v IDE a samostatnými nástroji. Preferuji ty integrované — vidím, co generují, a můžu hned kontrolovat diffy. V GR8 Tech jsem pracoval hlavně s Amazon Kiro a VS Code s Copilotem. Obvykle mám jedno okno s ‚monologem‘ AI a druhé s diffy souborů. Když něco nefunguje, proces zastavím, upravím prompt a začnu znovu. Jedno důležité pravidlo: vždy používat verzování. Začínat z čistého Git stavu a commitovat změny před spuštěním AI. Dává to jistotu i pohodlí při iteraci.“

Jak důležitá je práce s kontextem u větších systémů?

„Zásadní. Příliš mnoho kontextu — model ztrácí fokus. Příliš málo — nepochopí zadání. Velké monorepo se stovkami tisíc řádků kódu jsou pro AI stále výzva. U systému s více než 250 tisíci LOC a mnoha závislostmi jsem nedokázal získat smysluplné výsledky. Naopak v menších, dobře vymezených částech nebo u greenfield projektů funguje AI velmi dobře. Pracuji s menšími úseky, jasně určím, které soubory lze upravovat, začínám od high-level architektury a postupně jdu do detailu. Používám i sady pravidel pro zachování konzistence. AI potřebuje jasné hranice — myšlenky nám číst neumí.“

Jak vypadá spolupráce, když AI udělá chybu?

„AI má problém se složitější byznys logikou, optimalizací výkonu a edge case scénáři. Jednou vygenerovala SQL dotaz, který vypadal správně, ale byl neefektivní — načítal data v cyklu místo použití joinů. Když jsem vysvětlil rozdíl mezi očekávaným a skutečným chováním, opravila to na jednu optimalizovanou verzi. Při debugování jasně popisuji problém, přikládám stack trace, vysvětluji očekávání a kriticky hodnotím návrhy. A důležitá věc — AI si nepamatuje kontext trvale, takže klíčové poznatky se vyplatí dokumentovat a znovu používat.“

Jak hodnotíš silné stránky a limity AI z pohledu kvality a testování?

„AI je skvělá v dodržování existujících vzorců. Hlídá konzistenci pojmenování, používá standardní přístup k práci s výjimkami a generuje solidní unit testy včetně mocků a edge case scénářů. Ale správnost byznys logiky, bezpečnost, výkon a architektonická rozhodnutí zůstávají na člověku. AI má také problém s integračními testy a komplexními end-to-end scénáři, protože vyžadují hlubší porozumění systému.“

Náklady a bezpečnost jsou v enterprise prostředí zásadní — jak k tomu přistupujete v GR8 Tech?

„ROI je poměrně jasné — měsíční předplatné AI často stojí méně než několik hodin práce vývojáře, zatímco přínos na produktivitě je znatelný. Největší výzvou je ale bezpečnost dat. Pro firmu v režimu PCI DSS, jako je GR8 Tech, nepřipadá v úvahu posílat vlastní kód na veřejné servery. Proto jsou enterprise nástroje s garantovanou ochranou dat nutností. Jsou dražší, ale odpovědný přístup to vyžaduje.“

Na závěr — jak by měly týmy AI zavádět do své inženýrské kultury?

„Je to spíš kulturní než technologická změna. Má smysl začít s menší pilotní skupinou motivovaných vývojářů, nastavit jasná pravidla pro práci s prompty a citlivými daty a brát AI jako juniorního developera — rychlého, technicky zdatného, ale bez znalosti domény. Code review by se měly víc soustředit na architekturu a byznys logiku než na syntaxi. Důležité je sdílet zkušenosti — jak úspěchy, tak slepé uličky. AI eliminuje rutinní práci a dává inženýrům prostor soustředit se na řešení složitějších problémů.“

V GR8 Tech není AI vnímána jako zkratka ani náhrada, ale jako zesilovač schopností. V kombinaci s odpovědným přístupem k architektuře a kritickým myšlením urychluje experimentování, omezuje každodenní tření a vytváří prostor pro informovanější technická rozhodnutí. Jak ukazuje zkušenost Mykoly, skutečná hodnota nespočívá v tom psát méně kódu — ale v rychlejším ověřování nápadů, jistější iteraci a smysluplném využívání AI jako nástroje, který posiluje pevné inženýrské základy.