Codex připravil změnu, doplnil testy a shrnutí vypadá přesvědčivě. Pro vývojový tým je to užitečný výsledek. Ještě to ale není automatický souhlas s nasazením. Čím rychleji dokážeme kód vytvářet, tím důležitější je mít srozumitelný způsob jeho převzetí. Kontrola nemusí pokrok brzdit. Může rozhodnout, zda se rychlost promění v přínos, nebo jen v rychleji vznikající problémy.
Příkladem může být úprava, která má zabránit duplicitnímu založení požadavku. Agent přidá kontrolu a test druhého kliknutí na stejné tlačítko. Test projde. Dva současní uživatelé ale mohou stále vytvořit dva záznamy, protože jejich požadavky přijdou jinou cestou. Implementace i test tak souhlasí. Jen společně ověřují menší část problému, než potřebuje firma.
To není důvod přestat AI využívat. Je to důvod oddělit zadání, implementaci a ověření tak, aby se stejný chybný předpoklad nemohl pohodlně potvrdit sám. Zelený výsledek testů má význam pouze ve vztahu k tomu, co testy skutečně zkoušejí.
Převzetí začíná u změněných souborů
Souhrn od agenta pomáhá s orientací. Nenahrazuje však kontrolu konkrétních rozdílů. Odpovídá úprava zadání? Nezměnila veřejné rozhraní, způsob ukládání nebo oprávnění? Nevznikla nová závislost kvůli úkolu, který ji ve skutečnosti nepotřeboval?
Stejnou pozornost zaslouží věci, které ze změny zmizely. Odstraněný test může být správnou součástí úpravy, ale také nenápadným způsobem, jak dosáhnout zeleného výsledku. Převzetí proto potřebuje vysvětlení důležitých změn, nejen seznam nových funkcí.
Pro tým je výhodnější dostat menší, logicky uzavřený celek. Když jedna dodávka současně opravuje chybu, přepisuje strukturu projektu a mění formát dat, kontrola se zbytečně komplikuje. Rychlost generování není argument pro spojování nesouvisejících změn do jedné velké zásilky.
Ověření má vycházet z provozního scénáře
U našeho příkladu s duplicitami patří do ověření běžné vytvoření, opakované podání i souběh dvou požadavků. Podle způsobu integrace může být důležitý také přerušený přenos, kdy není jasné, zda cílový systém zápis provedl. Kromě odpovědi aplikace sledujeme skutečný stav dat.
Podobně u oprávnění nestačí ověřit, že správná role operaci provede. Potřebujeme vidět i odmítnutí nesprávné role. U formuláře zase nestačí jedna vyplněná ukázka. Zajímá nás prázdný vstup, delší obsah nebo rozpracovaný případ. Ne proto, abychom vytvořili nekonečný seznam kontrol, ale abychom pokryli význam změny.
Agent může pomoci s návrhem testovacích scénářů i kontrolou kódu. Jeho druhý pohled je užitečný signál, nikoli záruka nezávislosti. O přijetí změny má rozhodnout proces, ve kterém je jasné, kdo posoudil výsledky a která omezení zůstávají.
Nasazení je samostatná část práce
Správně fungující změna v testovacím prostředí ještě potřebuje bezpečnou cestu k uživatelům. Patří sem konfigurace, potřebná oprávnění, návazné služby a kontrola po nasazení. Pokud úprava mění data, musí se řešit i jejich převod a možnost obnovy. Vrácení předchozí verze kódu nemusí samo vrátit předchozí stav databáze.
Pro běžnou práci s agentem má proto smysl omezit přístup na to, co konkrétní úkol potřebuje. Produkční prostředí není vhodné místo pro volné experimentování jen proto, že by se tím ušetřilo jedno předání. Oddělené prostředí a schválený postup pomáhají chránit jak provoz, tak samotný vývojový tým.
V Evenaut vnímáme kvalitu jako součást rychlosti dodání, ne jako její opak. Oprava, kterou lze převzít, vysvětlit a bezpečně nasadit, je užitečnější než větší množství neověřeného kódu. AI může proces zrychlit. Jeho konečným výsledkem však stále musí být důvěryhodně fungující aplikace.
Chcete nastavit ověřování změn vytvářených s AI? Ozvěte se na customers@evenaut.com.
