Firma platila 40 milionů za migraci Struts na Spring Boot. AI agent to zvládl za víkend – ale jen ten správný
Enterprise Java kód nikdo nemá rád. Miliony řádků, framework starý patnáct let, dokumentace neexistuje a jediný člověk, co tomu rozuměl, odešel do důchodu v roce 2019. Přesně tohle je realita stovek bank, pojišťoven a výrobních firem v Evropě i u nás. A přesně na tohle vznikl ScarfBench – nový benchmark, který měří, jestli AI agenti dokážou legacy Java monolit skutečně migrovat, nebo jen vyplivnou kód, co se ani nezkompiluje.
Jméno je schválně ironické. "Scarf" jako šála, kterou si legacy systém omotáte kolem krku a doufáte, že vás neuškrtí. Testeři z komunity kolem Hugging Face a vLLM postavili sadu úloh na reálných open-source Java projektech – migrace ze Struts 1 na Spring Boot 3, upgrade z Java 8 na Java 21, přechod z EJB na moderní Spring Data JPA. Žádné hračkové příklady z učebnice. Skutečný kód s cyklickými závislostmi, mrtvým kódem a komentáři v němčině z roku 2007.
Co přesně ScarfBench měří a proč na tom záleží
Benchmark neposuzuje jen "kompiluje se to". Hodnotí čtyři vrstvy: syntaktickou správnost, průchod testovací sadou (pokud nějaká existuje – u legacy kódu je to loterie), zachování business logiky přes diff-based srovnání chování a nakonec bezpečnost – jestli agent náhodou nezavedl SQL injection tím, že nahradil starý prepared statement špatně escapovaným stringem.
Výsledky jsou vystřízlivující. GPT-4.1 a Claude Opus 4.x zvládají menší moduly (do 5000 řádků) s úspěšností kolem 70-80 %. Jakmile ale úloha přesáhne 20 000 řádků propojeného kódu s vlastními XML konfiguracemi, úspěšnost padá pod 30 % i u nejlepších modelů. Agent ztrácí kontext, zapomene na závislost v jiném modulu, a výsledek se sice tváří elegantně, ale v produkci spadne na první null pointer exception.
Zajímavé je, že menší specializované modely doladěné přes LoRA na Java kódu (třeba fine-tuned Qwen2.5-Coder 32B) v některých úlohách překonaly obecné giganty – ne proto, že jsou chytřejší, ale protože nemají tendenci "vylepšovat" kód nad rámec zadání. Enterprise klienti chtějí nudnou, předvídatelnou migraci, ne kreativitu.
Jak si takový benchmark spustit sami – vLLM a Hugging Face Foundry
Pokud chcete ScarfBench (nebo podobné úlohy) zkusit na vlastní infrastruktuře, nemusíte platit za API u OpenAI. vLLM nabízí takzvaný native-speed transformers backend, který umí nasadit prakticky jakýkoliv model z Hugging Face Hubu bez ruční konverze na proprietární formát. Instalace je triviální:
```bash pip install vllm vllm serve Qwen/Qwen2.5-Coder-32B-Instruct --tensor-parallel-size 2 --max-model-len 32768 ```
Na dvou RTX 4090 (24 GB VRAM každá) rozjedete 32B model v kvantizaci AWQ a dostanete se na slušných 40-60 tokenů za sekundu při agentních úlohách, kde model opakovaně čte a přepisuje soubory. Cena hardwaru? Sestava se dvěma 4090 vyjde na 130-150 tisíc korun, provoz stojí pár korun na elektřině za hodinu běhu.
Pokud vlastní GPU nechcete kupovat, Hugging Face nabízí Foundry Managed Compute – spravovanou službu, kde si model z Hubu jedním klikem nasadíte na cloudové GPU bez starosti o Kubernetes, drivery nebo CUDA verze. Cena se pohybuje podle GPU třídy, u A100 40GB kolem 2-3 dolarů za hodinu, což je pro krátký benchmark run naprosto rozumné.
Zajímavá je i kombinace SkyPilot a Hugging Face: SkyPilot umí spouštět AI workloady na libovolném cloudu (AWS, GCP, Lambda Labs, RunPod) podle toho, kde je zrovna nejlevnější GPU, a výsledky – checkpointy, logy, artefakty – ukládat rovnou na Hugging Face Hub s takzvaným zero-egress storage. Neplatíte tedy za výstupní datový provoz při stahování výsledků, což se u velkých modelů (desítky GB vah) reálně projeví na faktuře.
Proč legacy Java migrace vůbec někdo řeší přes AI a ne přes lidi
Odpověď je nudná: nedostatek lidí. Struts, EJB 2, JSF – tohle jsou technologie, které se na univerzitách už neučí. Senior vývojář, co to umí, si účtuje 2000-3000 Kč na hodinu a má je zabookované na měsíce dopředu. Firma s 15letým core systémem tak řeší dilema: buď zaplatí konzultantům desítky milionů za ruční migraci, nebo zkusí AI agenta, co to udělá rychleji a levněji, i když s rizikem chyby.
ScarfBench ukazuje, že ta druhá cesta funguje jen s lidským dohledem. Nejlepší reálné nasazení, o kterém autoři benchmarku píší, nepoužívá agenta jako náhradu vývojáře, ale jako prvotní návrh – AI vytvoří migrovaný modul, junior vývojář zkontroluje diff, senior schválí. Tím se doba migrace zkrátí z týdnů na dny, ale odpovědnost zůstává na člověku. Firmy, které tohle přeskočily a nechaly agenta commitovat rovnou do produkce, měly podle diskuze na Hacker News průměrně o 3x vyšší počet post-deploy incidentů.
Otevřené modely versus uzavřené API – co se vyplatí enterprise firmě
Tady je to o důvěře v data. Banka nebo pojišťovna nechce posílat svůj core banking kód na cizí API, i kdyby to bylo sebelepší. Proto roste zájem o self-hosted řešení – Ollama pro rychlé prototypování na noteboocích vývojářů, vLLM nebo TGI (Text Generation Inference) pro produkční nasazení s vyšší propustností.
Ollama je pro tenhle use-case ideální na začátek: `ollama run qwen2.5-coder:32b` a za pár minut máte lokální agentní backend bez jakékoli sítě ven. Pro reálný enterprise provoz je to ale málo výkonné – Ollama je optimalizovaná na jednoho uživatele, ne na desítky vývojářů najednou. Tam nastupuje vLLM s continuous batchingem, který zvládne paralelní požadavky bez lineárního propadu výkonu.
Otevřené modely mají ještě jednu výhodu – jde je doladit na firemní kódovou základnu přes LoRA adaptéry. Stačí pár set příkladů "před/po" z vlastních minulých migrací a model se naučí firemní konvence, pojmenování proměnných, preferovaný styl error handlingu. Fine-tuning 32B modelu přes LoRA na jedné A100 vyjde na hodiny, ne dny, a cena se pohybuje v jednotkách tisíc korun.
Skrytá cena, na kterou firmy zapomínají – elektřina za GPU cluster
Málokdo počítá s tím, že rozjetí vlastního inferenčního clusteru pro AI agenty znamená reálnou spotřebu elektřiny 24/7. Osm GPU karet v serverovně běžících na plný výkon dokáže táhnout 3-4 kW nepřetržitě, a to je při current cenách energií nezanedbatelná položka v rozpočtu IT oddělení. Firmy, co si takový cluster staví na vlastní pěst, čím dál častěji řeší, jak spotřebu zaplatit chytře – tedy nakupovat elektřinu v době, kdy je na spotovém trhu levná, a omezovat běh při špičkách.
Tady se hodí nahlédnout na spotové ceny elektřiny a naplánovat těžké tréninkové běhy nebo dávkové zpracování benchmarků na noční hodiny, kdy je cena za MWh výrazně nižší. Firmy s vlastní fotovoltaikou navíc mohou přebytky z poledne směřovat přímo do GPU clusteru namísto prodeje do sítě za nevýhodnou cenu – to je téma, které řeší Smart Energy Share v sekci pro firmy a sdílení elektřiny mezi provozovnami. Pokud navíc firma provozuje víc datových sálů nebo poboček, dává smysl řešit obchodování s flexibilitou a nabízet nevyužitou kapacitu do sítě v době, kdy GPU cluster zrovna neběží naplno.
Podobnou logiku, jen z pohledu bateriových úložišť pro vyrovnání špiček při zátěži datových sálů, rozebírá bess-global-blog.vercel.app – užitečné čtení, pokud plánujete GPU farmu větší než pár karet v serverovně.
Kam se ScarfBench a podobné benchmarky posunou dál
Autoři benchmarku plánují rozšíření o COBOL a starší .NET Framework migrace – tam je poptávka po AI agentech ještě vyšší, protože COBOL programátoři jsou vzácnější než senior Java vývojáři. Očekávám, že do roka uvidíme podobné benchmarky specificky pro bankovní regulatorní kód, kde chyba nestojí jen peníze, ale i pokutu od ČNB nebo ECB.
Realistický odhad: agenti během příštích dvou let zvládnou spolehlivě migrovat 60-70 % typického enterprise monolitu bez zásahu člověka, zbytek – ty ošklivé edge case s cyklickými závislostmi a business logikou schovanou v komentářích – zůstane doménou lidí ještě hodně dlouho. Kdo tvrdí, že AI během roku nahradí celé migrace týmy, buď benchmark nečetl, nebo prodává vlastní produkt.
Pokud plánujete vlastní pilotní projekt s AI agentem na legacy kód, začněte malým modulem, měřte úspěšnost stejně přísně jako ScarfBench, a nezapomeňte na energetickou stránku provozu – ať už jde o cloudové GPU hodiny, nebo vlastní cluster doma. Detaily k modelům najdete přímo na Hugging Face.
Zdroje
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: ElectricShare.cz AWS prodává AI bloky za miliony. Tady je, jak trénovat vl... Vice o run ai