Umělá inteligence píše kód, jiná umělá inteligence jej kontroluje a člověk řeší především rozhodnutí, na kterých se agenti nedokážou shodnout. Takovou budoucnost vývoje softwaru představuje Qodo. Nejde přitom jen o rychlejší kontrolu změn. Podstatou je zachytit zkušenosti vývojářské organizace a zpřístupnit je agentům ještě během práce.
Na OpenAI DevDay 2026 popsal Itamar Friedman, generální ředitel Qodo, systém, který doplňuje Codex o organizační kontext, průběžnou revizi a přehled o vztazích uvnitř softwaru. V rozhovoru s Danielle z týmu Developer Experience se opakovaně vracel k jednoduchému problému: změna může vypadat správně v jednom souboru, a přesto poškodit jinou část systému.
Za nejdůležitější posun považuji změnu otázky, kterou si vývojový tým klade. Nestačí zjistit, zda je nový kód sám o sobě v pořádku. Je potřeba vědět, zda odpovídá zkušenostem organizace, respektuje závislosti a skutečně dokončuje zamýšlenou funkci. Právě v tomto širším pohledu se setkávají automatická revize kódu, lidský úsudek a dlouhodobá paměť týmu.
Obsah
- 🤝 Qodo doplňuje Codex o kontext, který v kódu chybí
- 🧠 Od inteligence ke zkušenosti: co znamená „wisdom base“
- 🔍 Správná lokální změna může způsobit problém jinde
- 🗺️ Mapa softwaru se připravuje i mimo aktuální úkol
- ⚙️ Od zadávání pokynů přes pracovní postupy k týmům agentů
- 🛡️ Více agentů potřebuje jasné hranice a důkazy
- 📉 Jak poznat, že automatická revize skutečně pomáhá
- ⚖️ Kdy má neshoda agentů dorazit k člověku
- 🚨 Shoda agentů ještě neznamená správný výsledek
- 🏦 Velká finanční instituce a znalosti rozptýlené mezi lidmi
- 🌐 Skryté vztahy mezi mikroslužbami komplikují kontrolu
- 📦 Budoucí jednotkou práce nemusí být jeden pull request
- 🔗 Pracovní balíček má propojit související změny
- 🧩 Jak začít navrhovat vlastní kontrolní systém
- 💰 Náklady rozhodují o praktickém využití
- 👤 Poslední lidská revize znamená jinou roli člověka
🤝 Qodo doplňuje Codex o kontext, který v kódu chybí
Friedman popisuje Qodo jako blízkého pomocníka Codexu. Jeho úlohou je shromažďovat neformální technické znalosti organizace, předávat je programovacímu agentovi a současně kontrolovat jeho práci. Revize tedy nemá být pouze poslední zastávkou před schválením změny. Má vznikající řešení ovlivňovat už během psaní.
V tomto přístupu rozlišuji tři vzájemně propojené oblasti. První je získávání kontextu a budování mapy softwaru. Druhá je využití tohoto kontextu při generování kódu. Třetí je kontrola, která zkoumá, zda navržená změna odpovídá širším potřebám systému. Každá oblast má jiné nároky, ale jejich hodnota roste, když spolupracují.
Cílem je připravit od začátku přehledný a kvalitní pull request, tedy návrh změny určený k začlenění do projektu. Dlouhodobější ambice sahá dál: Qodo má tvořit vrstvu pro řízení vývoje, která ukazuje strukturu softwaru i to, jak se tato struktura postupně mění.
Samotný výkon modelu tak není celým řešením. Stejně důležité je, co model ví o konkrétní organizaci. Obecně schopný programovací agent nemusí znát důvod starého architektonického rozhodnutí ani zkušenost, kvůli které tým určitou změnu považuje za nebezpečnou. Qodo se snaží tuto mezeru zmenšit.
🧠 Od inteligence ke zkušenosti: co znamená „wisdom base“
Jedním z hlavních pojmů rozhovoru je wisdom base, tedy báze zkušeností. Friedman ji odlišuje od pouhého úložiště informací. Jeho úvaha postupuje od surových dat přes informace a znalosti k inteligenci. Další krok, který označuje jako moudrost, spojuje především se zkušeností.
V softwarovém týmu taková zkušenost vzniká postupně. Vývojáři poznávají, jak se systém skutečně chová, co funguje při růstu zátěže a kde mají zdánlivě malé zásahy nečekané následky. Část těchto poznatků je v dokumentaci, část v diskusích a část pouze v paměti lidí.
Pro mě je důležité nepovažovat bázi zkušeností za další název pro vyhledávání v repozitáři. Smyslem je zachytit význam rozhodnutí, nejen najít související text. Agent potřebuje rozumět tomu, proč je určitá souvislost podstatná pro právě řešený úkol.
Friedman tento požadavek spojuje s představou softwarové továrny. Pokud mají agenti zvládat větší část vývoje samostatně, člověk se může více věnovat pravidlům a řízení jejich spolupráce. To ale předpokládá, že zkušenosti organizace nezůstanou dostupné jen několika seniorním vývojářům.
Nejde tedy o nahrazení zkušeností obecnou inteligencí. Jde o jejich zpřístupnění. Silnější model může lépe uvažovat nad dodaným kontextem, ale nemůže automaticky znát všechny historické důvody a provozní zkušenosti konkrétní firmy.
🔍 Správná lokální změna může způsobit problém jinde
Nejkonkrétnější příklad se týkal zákazníka Qodo, který poskytuje služby milionům malých a středních podniků. Jeho platforma umožňuje velmi flexibilní práci a některé možnosti se přibližují přímému přístupu k databázím. Mnoho změn v kódu proto zasahuje právě databázovou vrstvu.
Taková změna může při místní kontrole působit bezproblémově. Kód dává smysl a v bezprostředním okolí úpravy není vidět zjevná chyba. Jakmile se ale zohlední navazující služba, může vyjít najevo riziko závažného výpadku. Problém není nutně v samotné úpravě, ale v jejím dopadu na další část systému.
Tento rozdíl považuji za jádro celé debaty o automatické revizi kódu. Posouzení jednoho místa a posouzení celého softwarového prostředí jsou dvě různé úlohy. Programovací agent pracující na konkrétním zadání nemusí mít dostatek kontextu, aby druhou z nich spolehlivě zvládl.
Friedman zároveň upozorňuje, že nejde o slabinu vyhrazenou AI. Podobné souvislosti obtížně hledají i lidští kontroloři. Člověk může velmi dobře porozumět jedné části kódu, ale procházet rozsáhlou síť závislostí je jiný druh práce.
Přínos Qodo má spočívat právě v propojení místního nálezu s celkovou mapou systému. Uvedený příklad není doprovázen statistikou úspěšnosti, proto jej chápu jako vysvětlení zamýšlené hodnoty produktu, nikoli jako důkaz, že podobná rizika vždy odhalí.
🗺️ Mapa softwaru se připravuje i mimo aktuální úkol
Aby bylo možné hodnotit širší dopady změny, nestačí začít hledat souvislosti až při otevření pull requestu. Friedman popisuje práci, která běží na pozadí a průběžně vytváří mapu či graf softwaru. Programovací agent potom může využít kontext připravený předem.
Zaujalo mě rozdělení práce podle času. Jedna část systému reaguje na právě řešený úkol. Jiná část mezitím zpracovává širší prostředí a aktualizuje jeho reprezentaci. Výpočetní práci mimo bezprostřední interakci Friedman označuje jako „sleep-time compute“.
Nejde o tvrzení, že agent během nečinnosti automaticky vyřeší všechny souvislosti. Podstatná je architektura pracovního postupu: náročné zjišťování vztahů nemusí být pokaždé celé opakováno až v okamžiku, kdy vývojář potřebuje odpověď.
Mapa přitom nemá sloužit pouze generování kódu. Má také pomáhat sledovat vývoj systému v čase. Jestliže se mění vztahy mezi službami a jejich využití, mění se i kontext pro další rozhodnutí. Proto Friedman spojuje mapování s řízením softwaru, nikoli jen s jednorázovou kontrolou.
Za důležitou považuji tuto návaznost: kontext pomáhá vytvořit změnu, revize ověřuje její dopady a dlouhodobá mapa zachycuje proměnu systému. Bez propojení těchto částí by každý agent mohl pracovat s jiným obrazem stejného prostředí.
⚙️ Od zadávání pokynů přes pracovní postupy k týmům agentů
Technologický vývoj Qodo Friedman rozděluje do tří etap: prompt engineering, flow engineering a swarm engineering. V češtině je chápu jako navrhování pokynů, navrhování pracovních postupů a navrhování spolupráce skupiny agentů.
První etapa stavěla především na tom, jak modelu položit otázku nebo zadat úkol. Friedman ji spojuje s možnostmi modelů v roce 2023 a s využitím při programovacích soutěžích. Pozornost se soustředila na jednotlivé vstupy a odpovědi.
V roce 2024 Qodo představilo práci AlphaCodium, která zdůraznila význam celého pracovního toku. Místo ladění jedné instrukce šlo o návrh procesu podobného tomu, jak postupuje vývojář. Pro bližší technický kontext doporučuji původní výzkumnou práci o AlphaCodium a návrhu pracovních postupů.
Současný posun podle Friedmana vychází z toho, že schopnější modely už dokážou část vlastních postupů sestavovat samy. Hodnota návrhu se proto přesouvá na vyšší úroveň: jak uspořádat více agentů, aby společně dokončili konkrétní práci.
- Pokyny: jak modelu srozumitelně zadat jednotlivý úkol.
- Pracovní postup: jak propojit kroky potřebné k jeho vyřešení.
- Skupina agentů: jak rozdělit odpovědnosti, nástroje a pravidla mezi více spolupracujících rolí.
Tyto etapy nevnímám jako důvod zahodit vše předchozí. Spíše ukazují, že se hlavní konstrukční problém postupně rozšiřuje od jedné odpovědi k celému systému práce.
🛡️ Více agentů potřebuje jasné hranice a důkazy
Friedman varuje před představou, že nejlepším řešením je nechat agenty bez omezení vytvářet další agenty a samostatně hledat nástroje. Takový přístup označuje za stále raný a potenciálně nehospodárný. Zvlášť problematický je u produktu, jehož hlavním příslibem má být důvěryhodnost.
U každé role proto zdůrazňuje předem promyšlené cíle, nástroje, ochranné mechanismy a pravidla. Nejde pouze o počet agentů. Důležitější je, zda každý z nich dostává vhodnou práci a zda lze jeho závěry spojit s konkrétními podklady.
V případě revize kódu je to zásadní. Upozornění bez opory v datech může vývojáři přidat práci místo toho, aby ji ušetřilo. Kontrolní agent má nejen něco namítat, ale také ukázat, proč námitka souvisí s upravovaným systémem.
Za praktický princip považuji rozdělení odpovědností podle typu úlohy. Agent připravující kontext potřebuje jinou roli než agent píšící kód. Kritický kontrolor má zase záměrně zkoumat předpoklady a výsledky programovacího agenta.
Oponentní kontrola není soutěž o přesvědčivější odpověď. Smyslem je společně dojít k výsledku podloženému důkazy. Pokud mají agenti jen rozdílné názory bez dohledatelného kontextu, vzniká další diskuse, ale nemusí vzniknout lepší software. Právě proto Friedman klade takový důraz na návrh celé spolupráce.
📉 Jak poznat, že automatická revize skutečně pomáhá
Otázka měření přínosu vede Friedmana k další změně perspektivy. V ranější fázi automatizace nástroj přidává zjištění na stránku pull requestu a vývojář je musí jednotlivě zpracovat. To však stále ponechává velkou část koordinační práce člověku.
Friedman předpovídá, že do roku 2027 může tento způsob působit zastarale kvůli mentální zátěži. Jde o jeho odhad, nikoli o jistý vývoj. Směr je ale zřejmý: kontrola má vracet připomínky už během programování a nejprve je řešit přímo s programovacím agentem.
Člověk by měl dostat především situace, které spolupracující agenti nedokážou uzavřít. Namísto neustálého zadávání dalších instrukcí se tak vývojář dostává do role člověka, kterého systém oslovuje kvůli potřebnému rozhodnutí.
Jako základní ukazatel Friedman navrhuje sledovat, kolikrát musel být vývojář požádán o zásah, aby vznikl kvalitní pull request. Pro mě je na této metrice zajímavé, že neměří množství komentářů ani aktivitu nástroje. Sleduje, kolik lidské pozornosti bylo potřeba k dokončení práce.
Současně v jeho formulaci zůstává podmínka kvality. Menší počet dotazů sám o sobě nestačí, pokud výsledná změna není dobrá. Úspora lidských zásahů má význam až ve spojení s kvalitním výsledkem, nikoli jako izolovaný cíl automatizace.
⚖️ Kdy má neshoda agentů dorazit k člověku
Programovací agent a kontrolní agent se nevyhnutelně někdy rozejdou. Friedman vysvětluje jejich neshodu především rozdílným kontextem. Jeden může vědět něco, co druhý nemá k dispozici. Podobně se liší informace vývojáře a člověka, který nakonec schvaluje pull request.
Odvolává se přitom na teoretickou představu, že rozumní účastníci se stejnými informacemi by měli dojít ke stejnému závěru. V praxi ji chápu jako motivaci ke sdílení podkladů, ne jako záruku, že se různé modely vždy shodnou.
Podstatné je ukotvení tvrzení v důkazech. Pokud jeden agent upozorňuje na dopad do jiné služby, potřebuje druhému předat relevantní souvislost. Stejný podklad pak potřebuje i člověk, pokud spor pokračuje.
Z rozhovoru si odnáším tři otázky, které mají při takové neshodě význam:
- Na jakých informacích stojí navržená změna?
- Jaký konkrétní podklad podporuje námitku kontrolního agenta?
- Liší se závěry kvůli rozdílnému kontextu, nebo zbývá rozhodnutí, které musí udělat člověk?
Není to zveřejněná specifikace rozhraní Qodo, ale praktické shrnutí důrazu na důkazy. Lidský zásah má být informovaným rozhodnutím. Pokud člověk dostane pouze dva protichůdné závěry, musí si celý kontext znovu sestavit sám a přínos automatizace se zmenšuje.
🚨 Shoda agentů ještě neznamená správný výsledek
Danielle v rozhovoru otevřela zásadní slabinu: co když se programovací a kontrolní agent shodnou, ale oba se mýlí? Friedman připouští, že chyby budou vznikat. Ani následný souhlas vývojáře a lidského kontrolora nevylučuje problém po nasazení do produkce.
Za nejdůležitější proto označuje schopnost neopakovat stejnou chybu. Pokud vznikne incident nebo hlášení chyby, musí se získaná zkušenost promyšleně vrátit do báze znalostí a zkušeností.
Vnímám zde důležitý rozdíl mezi dvěma cíli. Jeden by sliboval bezchybnou automatizaci. Druhý buduje systém, který se dokáže průběžně zlepšovat na základě skutečných výsledků. Friedmanův popis stojí na druhém z nich.
Nejde jen o archivování incidentu. Záznam má být použitelný při budoucím vývoji, aby relevantní zkušenost ovlivnila další podobné rozhodnutí. Současně Friedman připomíná potřebu poznatky později prořezávat, pokud už nejsou aktuální.
Shoda je tedy užitečný signál koordinace, nikoli důkaz bezpečnosti. Z představeného přístupu nevyplývá, že revize agentem odstraní potřebu všech ostatních kontrol. Vyplývá z něj požadavek propojit vývoj s následným učením. Právě zpětná vazba z reálného provozu může doplnit kontext, který při přípravě změny ještě nikdo neměl.
🏦 Velká finanční instituce a znalosti rozptýlené mezi lidmi
Druhý výrazný příklad se týkal velké finanční instituce se stovkami repozitářů a mnoha mikroslužbami. Každá služba má jinou odpovědnost a tým za dobu provozu nasbíral rozsáhlé zkušenosti s tím, co funguje ve velkém měřítku.
Problémem bylo, že část těchto znalostí zůstávala u seniorních vývojářů. Někteří z nich už odešli. Organizace přitom chtěla postupovat k větší automatizaci vývoje, ale nemohla přehlížet rizika spojená s chybnými změnami.
Qodo v takovém prostředí podle Friedmana prochází roky vývojářských diskusí. Zmiňuje GitHub, GitLab a Bitbucket i komunikaci ve Slacku a Teams. Účelem je znovu zachytit neformální znalosti a převést je do podoby využitelné pro další práci.
Za podstatné považuji, že zdrojem nejsou jen hotová rozhodnutí v oficiální dokumentaci. Důležitý kontext může být v debatě o tom, proč určitý postup nefungoval, nebo v diskusi o dopadu změny na jinou službu.
Tento příklad zároveň ukazuje, proč báze zkušeností nemá být jen doplňkem programovacího agenta. Je také odpovědí na problém kontinuity organizace. Pokud znalost existuje pouze v paměti několika lidí, jejich odchod mění schopnost týmu bezpečně zasahovat do systému. Zachycení těchto zkušeností může pomoci zachovat kontext i pro další vývojáře.
🌐 Skryté vztahy mezi mikroslužbami komplikují kontrolu
U rozsáhlých systémů nemusí být vztah mezi službami přímo vidět v kódu. Friedman upozorňuje na komunikaci prostřednictvím datových proudů. Skutečný způsob využití může určovat obsah přenášených dat, nikoli jen zjevný odkaz mezi dvěma částmi programu.
Právě tady vidím hranici čistě místní analýzy. Pokud kontrolor pracuje jen se změněným souborem, nemusí rozpoznat význam úpravy pro službu, která data zpracovává jinde. Historická diskuse může přitom obsahovat zkušenost, která tuto souvislost objasní.
Qodo se podle Friedmana snaží takové informace promítnout do mapy softwaru. Báze zkušeností a mapa závislostí tak nejsou dva oddělené archivy. Jedna pomáhá vysvětlit význam vztahů, druhá je zasazuje do struktury systému.
Neznamená to, že pouhé připojení komunikačních nástrojů vyřeší správnost interpretace. Rozhovor nepřináší podrobný popis ověřování každého odvozeného vztahu. Jasně ale pojmenovává cíl: z historických poznatků získat kontext potřebný k hodnocení dnešních změn.
Pro automatickou revizi kódu je to širší zadání než hledání chyb v syntaxi nebo místní logice. Kontrolor má rozumět dopadu změny v prostředí, které se skládá z mnoha služeb, datových toků a dřívějších rozhodnutí. Teprve potom může být jeho oponentura opravdu užitečná.
📦 Budoucí jednotkou práce nemusí být jeden pull request
V závěrečné části Friedman přesouvá pozornost od kvality modelů k definici úkolu. Předpokládá, že modely budou schopnější a agenti zvládnou delší práci. Pokud se tento předpoklad naplní, bude podle něj potřeba přehodnotit, co vlastně považujeme za dokončený úkol.
Dnes je přirozenou jednotkou často pull request. Tento formát odpovídá nástrojům i způsobu, jakým týmy rozdělují a kontrolují změny. Nová funkce však může vyžadovat více návrhů změn v jednom repozitáři nebo napříč několika repozitáři.
Friedman uvádí, že k jednomu výsledku může patřit dalších pět nebo patnáct pull requestů. Z pohledu uživatele je podstatná hotová schopnost produktu, nikoli jednotlivý návrh změny. Samostatná revize každé části proto nemusí nabídnout úplný obraz celého úkolu.
Pro základní orientaci v dnešním procesu lze využít dokumentaci GitHubu k revizím pull requestů. Friedmanova úvaha tento známý mechanismus rozšiřuje o koordinaci více souvisejících změn.
Vnímám to jako další podobu stejného problému s kontextem. Stejně jako jeden soubor nemusí stačit k posouzení služby, jeden pull request nemusí stačit k posouzení nové funkce. Kvalita jednotlivých částí a kvalita jejich společného výsledku nejsou totožné otázky.
🔗 Pracovní balíček má propojit související změny
Qodo v této souvislosti představilo plán označovaný jako work package triage, tedy třídění a posuzování pracovních balíčků. Friedman jej během rozhovoru avizoval jako chystané vydání v následujících dnech. Samotný rozhovor nepotvrzuje následné zpřístupnění, proto jej chápu jako oznámený směr produktu.
Základní myšlenka je srozumitelná: ukázat, jak spolu jednotlivé pull requesty souvisejí při dokončování jednoho úkolu, a umožnit revizi jejich celku. Jednotkou posouzení by tak nebyla jen izolovaná změna, ale soubor změn směřujících ke společnému výsledku.
Pro mě je tento návrh významný tím, že nezůstává pouze u silnějšího modelu. Mění uspořádání práce. Pokud mají agenti realizovat větší zadání, potřebuje odpovídající rozsah i kontrola a rozhodování lidí.
Friedman přitom netvrdí, že jednotlivé pull requesty okamžitě zmizí. Jeho argument míří k tomu, že nejsou vždy vhodným místem pro diskusi o celé nové schopnosti produktu. Mohou zůstat částmi pracovního toku, aniž by byly konečnou jednotkou hodnocení.
Úspěchem má být dokončená funkce od začátku do konce. Tento důraz spojuje plán pracovních balíčků s představou softwarové továrny: nejde jen vyrábět více změn, ale sladit jejich vznik, kontrolu a společný účel.
🧩 Jak začít navrhovat vlastní kontrolní systém
Praktické doporučení pro vývojáře staví Friedman na rozdělení úkolu. Nejprve je potřeba určit, čeho má systém dosáhnout, a potom zadání rozčlenit na pracovní oblasti. Pro každou z nich se navrhuje vhodná skupina agentů.
Může jít o několik rolí, například dvě, tři nebo pět. Jejich počet není hlavní cíl. Každá má mít jasný účel a vhodný model. Závěrečný důraz proto neleží na jednom univerzálním agentovi, ale na promyšleném uspořádání spolupráce.
Z jeho doporučení si sestavuji následující postup:
- Vymezit výsledek. Popsat, jakou celou práci má systém dokončit.
- Rozdělit pracovní oblasti. Oddělit získávání kontextu, tvorbu řešení a jeho kritické posouzení.
- Navrhnout role. Každému agentovi určit cíle, nástroje a pravidla.
- Zvolit modely. Přizpůsobit schopnosti modelu konkrétní odpovědnosti.
- Vyžadovat podklady. Spojit důležité závěry s relevantními informacemi.
- Určit lidský zásah. Vyjasnit, kdy má neuzavřená otázka dorazit k vývojáři.
- Vracet zkušenosti zpět. Zajistit, aby další práce využívala poznatky z chyb a incidentů.
Tento seznam není hotová technická architektura. Je to shrnutí zásad, které Friedman zdůrazňuje. Za užitečné považuji, že začíná výsledkem práce, nikoli výběrem modelu. Teprve podle potřeb jednotlivých rolí dává smysl řešit jejich konkrétní obsazení.
💰 Náklady rozhodují o praktickém využití
Ekonomika podle Friedmana patří přímo do návrhu systému. Pokud automatizace skutečně pomáhá dokončovat úkoly, zákazníci ji budou chtít používat často. Právě proto musí být nákladově efektivní.
Neznamená to automaticky použít nejlevnější model pro všechno. Friedman doporučuje promýšlet vhodný model pro každého účastníka navržené spolupráce. Rozdílné pracovní oblasti mohou mít rozdílné nároky na schopnosti i rychlost.
Tento bod propojuji s jeho varováním před nekontrolovaným vytvářením dalších agentů. Více aktivity nemusí znamenat lepší výsledek. Pokud systém vykonává zbytečnou práci, obtížně se obhajuje i tehdy, když jednotlivé odpovědi působí kvalitně.
Rozhovor neobsahuje cenové srovnání ani konkrétní provozní výsledky. Nabízí spíše konstrukční princip: optimalizovat spolupráci podle úkolu a používat odpovídající modely tam, kde přinášejí hodnotu. Nákladová efektivita zde není doplněk po dokončení produktu, ale podmínka jeho širšího využívání.
👤 Poslední lidská revize znamená jinou roli člověka
Název „Poslední lidská revize kódu“ zní jako příslib úplného odstranění člověka z kontroly softwaru. Obsah rozhovoru je ale opatrnější. Friedman opakovaně počítá s lidským rozhodováním, připouští chyby a na závěr připomíná potřebu dalšího vzdělávání vývojářů.
Za hlavní zprávu proto považuji přesun lidské pozornosti. Rutinní připomínky mají agenti řešit mezi sebou. Člověk má dostávat otázky, pro které je skutečně potřebný, a přitom mít k dispozici podklady pro rozhodnutí.
Ústřední myšlenky Qodo na sebe navazují: zachytit zkušenosti organizace, připravovat mapu softwaru, kontrolovat změny během jejich vzniku, podkládat námitky důkazy a vracet provozní poznatky do další práce. K tomu se přidává širší pohled na úkol, který může spojovat více pull requestů.
Budoucnost revize kódu tak nevnímám jako otázku, zda AI dokáže napsat přesvědčivý komentář. Důležitější je, zda pomůže vytvořit správnou změnu ve správném kontextu, s menší zátěží pro člověka a se schopností poučit se z výsledku. Právě podle toho bude dávat smysl hodnotit nejen Qodo, ale i další systémy pro vývoj softwaru s AI.
