AI programátoři zvládnou zadání, ale hotový kód často vyžaduje člověka

Test z reálných požadavků

Benchmark Co-Design Bench vznikl jako pokus přiblížit testování AI agentů skutečné práci na softwaru. Autoři z Alibaba a několika asijských univerzit nevzali jen sadu uměle vytvořených programátorských úloh. Vycházeli z požadavků, které lidé zadávali během skutečných vývojářských sezení.

Výzkumníci prošli 37 463 unikátních požadavků z 26 314 vývojářských relací. Z nich vybrali 273 úloh. Každá začíná existující aplikací, která funguje, a požadavkem na její změnu. Agent musí upravit hotový projekt, zachovat nesouvisející části a dodat výsledek, který funguje v prohlížeči.

Úloha může být zdánlivě jednoduchá. Například vytáhnout částku z účtenky a propsat ji do všech navazujících součtů. Jindy musí agent změnit rozvržení, doplnit interakci, upravit obsah a zároveň pracovat s videem, zvukovou nahrávkou nebo dokumentem.

To je podstatný rozdíl proti úloze, kde model dostane prázdný soubor a krátké zadání. V existující aplikaci musí nejdřív pochopit, jak jsou propojené komponenty, data a obrazovky. Pak musí provést změnu tak, aby nerozbil něco, co už fungovalo.

Nejlepší výsledek stále znamená nedokončenou práci

Podle výzkumné práce zveřejněné na arXiv dosáhl nejlepší z deseti testovaných modelových endpointů průměrně 69,9 % splněných kritérií. Všechna kritéria však splnil jen u 26,4 % úloh.

Rozdíl mezi těmito dvěma čísly je důležitější než samotné pořadí modelů. Agent často odvede většinu práce. Změní stránku, doplní tlačítko a zapojí část logiky. Chybí ale jeden detail, který zadání také vyžadovalo. V profesionálním projektu může jít o nefunkční stav po obnovení stránky, špatně přepočítanou hodnotu nebo komponentu, která se rozbije při jiné velikosti obrazovky.

Hodnocení proto nebylo založené pouze na tom, zda se v souborech objevila očekávaná změna. Hotovou aplikaci nejdřív ověřoval jeden AI hodnotitel v prohlížeči. Druhý systém potom pozitivní výsledek znovu kontroloval a hledal například makety, natvrdo vložené hodnoty nebo funkce, které pouze vypadají hotově.

V multimodální části benchmarku dosáhl GPT-6 Astra plného dokončení u 41 % úloh. U úprav celých repozitářů to bylo méně než 18 %. Jde o výsledek konkrétního testu a konkrétního pracovního prostředí, nikoli o univerzální pořadí všech nástrojů dostupných vývojářům.

Starší benchmarky už rozdíly neukazují

Autoři upozorňují, že některé starší testy jsou pro dnešní agenty příliš snadné. Modely v nich dosahují výsledků nad 99 %, protože mohou kód spustit, zkontrolovat a případně opravit v prostředí, které přesně odpovídá testu.

U Co-Design Bench se výsledky propadly o více než 35 procentních bodů. Neznamená to, že se schopnosti modelů náhle zhoršily. Test pouze měří jinou věc. Místo izolované opravy sleduje, zda agent zvládne dokončit změnu v existující aplikaci s více podmínkami.

To je podobné rozdílu mezi jízdou na polygonu a cestou v běžném městě. Na polygonu lze přesně připravit zatáčku, povrch i překážky. Ve městě se přidají semafory, chodci, výluky a řidič, který změní směr bez varování. Výsledek z prvního prostředí nemusí předpovědět chování ve druhém.

Více typů změn dělá agentům problém

V testu se výkon všech deseti modelů zhoršoval, pokud úloha kombinovala více druhů úprav. Nejčastěji šlo o strukturu stránky, vizuální styl, interakce a obsah. U rozsáhlejších úkolů repozitáře se přidává také práce s komponentami, routami, stavem aplikace a datovým tokem.

Právě taková kombinace je běžná při zadání typu „udělej z této stránky dashboard, přidej filtr, načítej data z nového zdroje, uprav mobilní zobrazení a zachovej současné chování“. Každá část může být pro model zvládnutelná samostatně. Potíž vzniká při jejich propojení.

Benchmark obsahuje dvě hlavní části. Multimodální úpravy tvoří 100 úloh. Agenti v nich dostávají existující stránku a mohou k požadavku obdržet obrázek, zvuk, video nebo dokument. Úpravy repozitáře zahrnují 173 úloh s koordinovanými zásahy do více souborů.

Za modelem GPT-6 Astra se v celkovém pořadí umístily Claude Opus 5 a Qwen3.8-Max. Na posledním místě z deseti testovaných endpointů skončil Grok 4.6. U větších přestaveb se menší Qwen3.8-27B posunul na druhé místo. Autoři z toho ale nevyvozují obecnou výhodu menšího modelu.

Další výpočetní výkon sám o sobě problém nevyřešil. GLM-5.2 při menších změnách spotřeboval téměř šestkrát více tokenů než GPT-6 Astra, přesto dosáhl výrazně horšího výsledku. Více času na přemýšlení tedy automaticky neznamená lepší opravu.

Výsledek ovlivňuje i pracovní prostředí

Model není jediná součást AI programátora. Důležitý je také takzvaný harness, tedy programové prostředí, přes které agent čte soubory, upravuje kód, spouští příkazy a kontroluje výsledek. V praxi jde o sadu nástrojů a pravidel, která modelu určují, co může dělat.

Výzkumníci proto některé modely spustili v různých prostředích. Qwen3.8-27B dosáhl u rozsáhlejších úprav podle použitého prostředí 75 %, nebo jen 56 %. Změnilo se také pořadí některých modelů.

Žebříček samotných modelů proto ukazuje jen část obrazu. Firma, která vybírá AI nástroj pro vývoj, by měla testovat model společně s konkrétní sadou nástrojů, oprávnění a kontrol. Stejný model může mít odlišný výsledek podle toho, jak vidí repozitář, jak spouští testy a zda dokáže ověřit změnu v prohlížeči.

To má význam i pro české vývojáře. Co-Design Bench není nabídka produktu ani placená služba pro český trh. Neříká tedy, zda je konkrétní agent dostupný v češtině, kolik stojí v evropském API nebo jak se chová v českém projektu. Výsledky se týkají schopnosti testovaných endpointů v přesně popsaném prostředí.

Benchmark také nepoužíval běžný dialog, ve kterém vývojář agentovi průběžně vysvětluje další podmínky. Každá úloha měla jeden pevně daný požadavek. Následné otázky, opravy zadání ani doplnění kontextu během práce součástí testu nebyly. Hodnoticí systémy navíc mohou udělat vlastní chybu.

Co z výsledků plyne pro používání AI při vývoji

Výsledek podporuje opatrnější způsob práce s programovacími agenty. Mohou připravit návrh změny, projít více souborů a zrychlit rutinní části úkolu. Hotový výstup však vyžaduje kontrolu funkcí, testů i chování v aplikaci.

To není pouze otázka stylistiky kódu. Vývojář musí ověřit, zda agent splnil celé zadání, zda nepoužil pevně zadané hodnoty, zda zachoval existující funkce a zda změna funguje v různých stavech aplikace. U firemního softwaru se k tomu přidává bezpečnost, práce s přístupovými údaji a kontrola datových toků.

Podobný rozdíl mezi laboratorním skóre a přijetím v praxi ukázala také studie organizace METR. Přijetí kódu vedoucími projektů bylo zhruba o 24 procentních bodů nižší než výsledek ve známém benchmarku SWE-bench Verified. Výsledky testů proto nelze číst jako přímý odhad množství kódu, který firma bez úprav nasadí.

Co-Design Bench přidává další měřítko. Neptá se jen, zda agent vyřešil izolovaný programátorský problém. Sleduje, jestli dokáže dodělat konkrétní změnu v existující aplikaci, kde se několik požadavků potkává na jednom místě. V tomto testu zůstává lidská kontrola potřebná u většiny úloh.

FAQ