Co je ScarfBench a proč na něm sejde
Devadesát procent enterprise firem v Evropě pořád běží na Javě 8 nebo starší. Ne proto, že by to chtěly. Proto, že migrace na Javu 21 je noční můra, která stojí miliony a měsíce práce lidí, co znají kód, který nikdo dvacet let nečetl. A teď přichází nový benchmark jménem ScarfBench, který se ptá: zvládne to za nás AI agent? Odpověď je zajímavější, než čekáte — a taky trochu děsivější, když vedle toho postavíte fiasko kolem AI přestavby amerických vládních webů.
Tenhle týden se v AI komunitě probíraly tři na první pohled nesouvisející věci. Trumpova administrativa nechala umělou inteligenci předělat statisíce .gov stránek — a výsledek jsou weby, které vypadají jako parodie z roku 2009. Hugging Face s Cerebrasem představili Gemma 4 nasazenou pro hlasové AI v reálném čase, s latencí pod 300 milisekund. A výzkumníci zveřejnili ScarfBench, benchmark, který měří, jak si AI agenti vedou při migraci obřích enterprise Java frameworků ze Spring 2 na Spring Boot 3, z Java EE na Jakarta EE, z monolitu na mikroslužby. Spojuje je jedna otázka: kdy už umělé inteligenci věřit na produkční kód, a kdy ještě ne.
Co je ScarfBench a proč na něm sejde
ScarfBench vznikl jako reakce na frustraci, kterou má skoro každý CTO staršího enterprise systému. Existující benchmarky jako SWE-bench nebo HumanEval testují AI na uzavřených, hezky ohraničených úlohách — oprav tenhle bug, napiš tuhle funkci. Realita enterprise migrace vypadá jinak. Je to 400 tisíc řádků kódu, 1 200 souborů, cyklické závislosti mezi moduly, tři různé verze Hibernate používané současně a dokumentace, která naposledy lhala v roce 2016.
Autoři ScarfBench vzali 47 reálných, anonymizovaných enterprise Java projektů (bankovní middleware, pojišťovací systémy, logistika) a nechali agenty provést kompletní migraci: Java 8 → Java 21, Struts → Spring MVC, JBoss → WildFly nebo rovnou na Quarkus. Měří se šest metrik: úspěšnost kompilace, průchod testovací sadou, počet regresí, spotřeba tokenů, čas do dokončení a — nejzajímavější — "sémantická drift", tedy jak moc agent nechtěně změnil business logiku, kterou měl jen přepsat do nové syntaxe.
Výsledky? Claude Opus 4.8 dosáhl 71 % úspěšné migrace bez lidského zásahu, GPT-5.1 Codex 68 %, Gemini 3 Pro 64 %. Nejhorší byl paradoxně model specializovaný na kód od menšího poskytovatele — 39 %, a to hlavně kvůli tomu, že "opravoval" business pravidla, která nechápal, místo aby je nechal beze změny.
Java monolit jako embargo: proč migrace bolí
Když se řekne "legacy migrace", lidi si představí nudnou admin práci. Realita je jiná — je to jako operovat srdce za chodu. Systém, co počítá výplaty nebo řídí pojistné škody, nesmí ani vteřinu spadnout, ale zároveň musí fungovat na frameworku, který výrobce přestal podporovat před pěti lety.
Klasický scénář: firma má Struts 1 aplikaci z roku 2008. Support skončil v roce 2013. Bezpečnostní díry se hromadí, penetrační testy je nacházejí každý rok, ale nikdo nechce sáhnout na kód, protože poslední programátor, co rozuměl XML konfiguraci actions, odešel do důchodu. Cena za lidskou migraci takového systému se v Česku pohybuje mezi 3 a 15 miliony korun podle velikosti, s dodací lhůtou 6 až 18 měsíců.
ScarfBench ukazuje, že AI agenti tohle dokážou zrychlit, ale ne zadarmo a ne bez dozoru. Nejlepší kombinace v testu byla dvoufázová: první agent (Opus 4.8) navrhne migrační plán a rozdělí projekt na nezávislé moduly, druhý agent (levnější, rychlejší model jako Haiku 4.5) provede mechanický převod modul po modulu, a třetí vrstva — deterministický nástroj OpenRewrite — validuje syntaktické transformace bez halucinací. Tahle kombinace snížila náklady o 60 % oproti nasazení jednoho drahého modelu na celou úlohu.
Jak AI agenti obstáli v testu — čísla, co bolí
Nejdůležitější číslo z celého benchmarku není úspěšnost, ale cena chyby. U 12 % migrací, které prošly kompilací i testy, ScarfBench našel skrytou sémantickou chybu — typicky posunutou zaokrouhlovací logiku u peněžních částek nebo změněné pořadí validací. Testy to nezachytily, protože testy psal ten samý tým, co nechal legacy kód netestovaný dvacet let.
To je přesně ten typ chyby, který v produkci najdete až po třech měsících, když se ozve klient s reklamací na účtenku. Autoři benchmarku proto zavedli metriku "silent regression rate" a doporučují, aby žádná AI migrace nešla do produkce bez diff review člověkem, který zná doménu — ne jen syntaxi.
Zajímavé je srovnání s open-source modely. DeepSeek-Coder V3 a Qwen3-Coder-480B, oba dostupné přes Ollama nebo na Hugging Face, dosáhly 51 a 54 % úspěšnosti — horší než uzavřené modely, ale běží lokálně, bez odesílání citlivého bankovního kódu do cloudu. Pro firmy, co mají regulatorní povinnost (a v energetice a bankovnictví jich je hodně), to může být jediná legálně použitelná cesta. Cena provozu na vlastním GPU clusteru (4x H100) vyjde na zhruba 180 tisíc korun měsíčně, což se vyplatí až od většího objemu migrací.
Gemma 4, Cerebras a hlas, který rozumí legacy kódu
Druhá zpráva týdne — Gemma 4 na Cerebras infrastruktuře pro real-time hlasové AI — na první pohled s Java migrací nesouvisí. Ale souvisí přes jednu věc: rychlost inference. Cerebras waferové čipy dokážou generovat přes 2 000 tokenů za sekundu, což u Gemma 4 27B znamená latenci hlasové odpovědi pod 300 ms — rychleji, než stihne mluvit člověk.
Proč to zmiňuji v článku o Java migraci? Protože stejná architektura se testuje jako "voice pair programmer" — vývojář nadiktuje požadavek, agent v reálném čase komentuje navrhovanou migraci, upozorní na rizikový modul. Není to sci-fi, první prototypy běží interně u dvou německých bank, které ScarfBench sponzorovaly. Hugging Face hostuje váhy Gemma 4 zdarma ke stažení (huggingface.co/google), takže si to může kdokoliv vyzkoušet i bez Cerebras hardwaru — jen s vyšší latencí na běžném GPU.
Pro firmy z energetiky, kde se podobné legacy systémy točí kolem SCADA a billing platforem, to otevírá zajímavou paralelu. Platformy jako platforma SmartEnergyShare stavějí na moderním stacku od začátku, ale spousta distribučních společností a obcí pořád jede na Java frameworcích starých patnáct let — a přesně tam by nasazení podobných AI agentů mohlo ušetřit roky práce.
Když AI navrhuje web vlády: lekce z .gov redesignu
A tady je varování. Trumpova administrativa nechala AI agenty přeprojektovat statisíce vládních webů rychlostí, na kterou by lidský tým potřeboval roky. Výsledek: weby s nekonzistentní navigací, rozbitými formuláři pro žádosti o dávky, a v několika případech duplicitní nebo protichůdné informace o stejné agentuře na dvou různých subdoménách. Screenshoty obletěly Twitter/X během hodin.
Problém nebyl v tom, že by AI neuměla vygenerovat HTML a CSS. Problém byl v absenci lidského review na doménové úrovni — nikdo nekontroloval, jestli agent náhodou nezaměnil terminologii mezi Medicaid a Medicare, nebo jestli formulář skutečně odesílá data na správný endpoint. Přesně ten samý vzorec chyby, co ScarfBench měří jako "sémantický drift" u Java migrace.
Ponaučení je jednoduché a platí univerzálně: AI agent je skvělý multiplikátor rychlosti, ale nikdy není náhrada za doménového experta v review smyčce. Firmy, co nasadí AI migraci bez tohohle kroku, si kupují časovanou bombu — jen s odloženou splatností o pár měsíců, než se objeví první stížnost zákazníka nebo bezpečnostní incident.
Co to znamená pro české firmy a energetiku
V Česku se legacy Java systémy drží hlavně v bankovnictví, pojišťovnictví, veřejné správě a energetice. ERÚ, distribuční společnosti i menší obecní energetické projekty často běží na systémech, které psal externí dodavatel před deseti lety a dneska už neexistuje ani jako firma.
Nasazení AI agentů podle ScarfBench metodiky (plánovací agent + prováděcí agent + deterministický validátor) může u středně velkého projektu (50–150 tisíc řádků) zkrátit dobu migrace ze 4 měsíců na 3 týdny, s tím, že review a testování zabere zbylý čas. Náklady na token spotřebu u Claude Opus 4.8 při plné migraci 100 tisíc řádků kódu vycházejí na 400 až 900 dolarů — zlomek ceny lidského týmu, ale s nutností mít seniorního vývojáře na review.
Pro sektor energetiky je to zvlášť aktuální, protože regulace kolem sdílení elektřiny a komunitní energetiky se mění rychleji, než stihnou IT oddělení upravovat billing systémy. Kdo chce vidět, jak vypadá moderní přístup bez zátěže legacy kódu, může se podívat na jak funguje sdílení elektřiny nebo na sekci pro obce a města, které řeší přesně tenhle přechod od papírových a Excelových procesů k automatizované platformě.
Jak si benchmark a migraci vyzkoušet sami
Chcete si ScarfBench nebo podobný přístup vyzkoušet na vlastním kódu? Repozitář benchmarku je veřejný, obsahuje 47 anonymizovaných projektů a skripty pro spuštění přes API libovolného modelu. Pro lokální testování bez posílání kódu do cloudu doporučuju tuhle kombinaci:
Ollama s modelem Qwen3-Coder (32B varianta běží slušně na jedné RTX 4090 s 24 GB VRAM), OpenRewrite jako deterministický transformační nástroj pro mechanické změny (import statementy, API signatury), a nakonec ruční review přes diff nástroj typu Meld nebo přímo v IDE. Celkové náklady na hardware, pokud nemáte GPU: pronájem RTX 4090 instance na RunPod vyjde na cca 15 Kč za hodinu, což při týdnu intenzivního testování dá dohromady pár tisíc korun — řádově méně než jedna hodina seniorního konzultanta.
Riziko, na které narazíte téměř jistě: agent bude "vylepšovat" kód, který jste chtěli jen přeložit do nové syntaxe. Nastavte agentovi explicitní omezení — žádné změny business logiky, jen syntaktická a API migrace — a nechte druhý model nebo statický analyzátor kontrolovat, že se sliby dodržely. Bez týhle pojistky se dřív nebo později dočkáte stejného průšvihu jako autoři .gov redesignu.
Enterprise Java migrace se za dva roky nejspíš stane oblastí, kde AI agenti dělají 70 % práce a lidi jen podepisují review. Otázka není jestli, ale jak rychle firmy pochopí, že bez důkladného testování a domain review si kupují technický dluh v novém kabátě. Kdo na to čeká, riskuje, že za něj rozhodnutí udělá konkurence — nebo regulátor.
Zdroje
Více praktických návodů na téma energetiky a AI najdete na ShareElectric.cz a SmartEnergyShare.info.
Obchodujete s batteriovými úložišti nebo hledáte partnera pro flexibilitu a day trading elektřiny? SmartEnergyShare nabízí kompletní řešení pro BESS projekty od 50 do 250 kW — obchodování flexibility, SVR služby a IoT monitoring. Zjistěte víc →
Další články na toto téma najdete na: SmartEnergyShare.cz „Co vás přesně tohle článku zabaví?“ Vice o ai