Jak se AI naučila programovat: Od HumanEval k zlaté medaili z ICPC

Programování má proti matematickému uvažování jednu velkou výhodu: odpověď můžeme spustit. Program se buď zkompiluje, nebo nezkompiluje. Na konkrétním vstupu vrátí konkrétní výstup. Můžeme změřit čas, paměť a porovnat výsledek se skrytým checkerem. V nedávném článku o cestě AI od GSM8K k důkazovým agentům jsme sledovali, jak se matematické systémy naučily vytvářet více postupů, hlasovat a ověřovat důkazy. Tento text na stejný příběh navazuje v prostředí, kde lze výsledek nejen posoudit, ale skutečně spustit.

To svádí k představě, že soutěžní programování je pro AI jednodušší než matematika. Ve skutečnosti je to tvrdší a zároveň čistší laboratoř. Model musí z dlouhého zadání odvodit skrytý algoritmus, dokázat si jeho korektnost, převést jej do bezchybného programu a přežít vstupy, které nikdy neviděl. Jediná opomenutá hraniční podmínka znamená nulu.

Za pět let se proto změnil nejen výkon modelů, ale celý způsob, jakým necháváme AI programovat. V roce 2021 jsme se ptali, zda jeden model na první pokus doplní krátkou funkci. V roce 2025 už několik agentů paralelně navrhovalo algoritmy, spouštělo kompilátor a testy, sdílelo nalezené chyby a iterovalo až k řešení na úrovni zlaté medaile z ICPC.

Tento text je technická historie této proměny. Nejde jen o to, který model získal kolik bodů, ale hlavně o to, jaký algoritmus inference, selekce a verifikace tento výsledek vyrobil. Právě tyto principy jsou přenositelné do HyperFusion a do experimentů na LUMI.

Hlavní závěr: největší skok nepřinesl model, který napsal jeden dokonalejší program. Přinesly jej systémy, které vytvořily populaci různých algoritmů, levně vyřadily zjevné chyby, hledaly protipříklady, opravovaly jen prokázané vady a inteligentně rozhodovaly, které programy vůbec stojí za odeslání.

Od našeptávání k vibe codingu

Pojem vibe coding zavedl Andrej Karpathy 2. února 2025 pro způsob práce, při němž člověk popisuje záměr přirozeným jazykem, přijímá velké změny vytvořené AI a postupně systém směruje, aniž by nutně četl každý řádek. Během několika měsíců se z technického slangu stal kulturní pojem a Collins jej vybral jako slovo roku 2025.

VYSVĚTLIVKA: CO JE VIBE CODING

V čisté podobě nejde jen o autocomplete ani o občasnou radu chatbota. Programátor přesouvá pozornost ze syntaxe na záměr, chování aplikace a další instrukci pro model. Kód může vznikat po velkých blocích a autor jej nemusí detailně chápat. To je skvělé pro prototyp, ale nebezpečné všude, kde chybí testy, bezpečnostní kontrola a někdo, kdo rozumí výslednému systému.

Je důležité nezaměnit rychlý růst AI nástrojů s čistým vibe codingem. Stack Overflow Developer Survey 2025 uvádí, že AI nástroje používá nebo plánuje používat 84 % respondentů, proti 76 % o rok dříve, a 51 % profesionálních vývojářů je používá denně. Současně však 72 % respondentů uvedlo, že vibe coding není součástí jejich profesionální práce. Masově se rozšířila AI asistence, nikoliv automaticky ochota přestat kód kontrolovat.

Střízlivější korekci přidal experiment METR z první poloviny roku 2025. Šestnáct zkušených open-source vývojářů řešilo 246 úloh ve vlastních repozitářích a s tehdejšími AI nástroji jim práce trvala v průměru o 19 % déle. Je to úzký časový snímek, nikoliv univerzální verdikt nad AI programováním. Připomíná ale, že rychlé rozšíření nástroje ještě samo o sobě nedokazuje vyšší produktivitu.

Soutěžní programování je proto zajímavým protipólem vibe codingu. Můžeme generovat kód velmi volně, ale nakonec musí projít přesným checkerem. Výzkumně cenná není samotná rychlost psaní, nýbrž schopnost změnit vágní proud návrhů v ověřený program.

Nejdřív pravidla: Codeforces, IOI a ICPC nejsou stejná disciplína

Číslo jako „85. percentil v programování“ zní jednoznačněji, než ve skutečnosti je. Codeforces, International Olympiad in Informatics a ICPC testují příbuzné, ale odlišné dovednosti.

Také metriky měří různé věci:

Proto v článku nebudu kreslit jednu falešně hladkou křivku „obecné programátorské inteligence“. U každého bodu časové osy uvádím platformu, počet pokusů, nástroje a způsob přepočtu na lidské pořadí.

Časová osa lidského ekvivalentu

První systémy ještě žádný důvěryhodný lidský percentil neměly. DeepCoder v roce 2017 urychlil enumerativní hledání krátkých programů přibližně o jeden řád, ale pracoval v omezeném DSL a řešil jen úlohy obtížností podobné nejjednodušším soutěžním zadáním. Codex v roce 2021 dosáhl 28,8 % pass@1 na HumanEval, ale HumanEval nemá výsledkovou listinu lidských soutěžících. Tyto milníky proto patří na osu, nikoliv na percentilovou stupnici.

Od roku 2022 už máme několik přímých, byť stále ne zcela zaměnitelných srovnání s lidmi. Do grafu dávám pouze frontier systém dané doby a jeho veřejně doložený výsledek:

• AlphaCode, Codeforces 2022: překonal přibližně 45,7 % soutěžících, tedy výkon kolem mediánu.
• AlphaCode 2, Codeforces 2023: překonal v průměru 85 % účastníků. Ve dvou nejlepších soutěžích však překonal více než 99,5 % účastníků. Právě tento rozptyl ukazuje, proč samotný průměr skrývá důležitou část příběhu.
• o1, Codeforces 2024: obecný o1 dosáhl 89. percentilu. Varianta dále trénovaná pro IOI dosáhla Elo 1807 a 93. percentilu.
• o1-IOI, IOI 2024: pod skutečným limitem 50 submitů na úlohu získal 213 bodů a 49. percentil elitních středoškolských olympioniků.
• GPT-5, LiveOIBench 2025: na 403 úlohách z olympiád let 2023 až 2025 dosáhl 81,76. percentilu. Autoři upozorňují, že nejlepší lidé v tomto souboru bývají nad 90. percentilem.
• Gemini 2.5 Deep Think, ICPC 2025: deset vyřešených úloh by znamenalo druhé místo ze 139 týmů, tedy lepší výsledek než přibližně 98,6 % výsledkové listiny. Jde o hypotetický přepočet, protože Gemini nebyl oficiálně zařazeným univerzitním týmem.

Čáru spojuji pouze mezi výsledky ze stejné rodiny Codeforces. IOI, ICPC a LiveOIBench zůstávají jako samostatné body, protože jejich populace i pravidla jsou jiné. Svislá úsečka u AlphaCode 2 není interval spolehlivosti, ale rozdíl mezi průměrem a dvěma nejlepšími soutěžemi. Graf tak ukazuje dvě pravdy současně: frontier systémy se v některých soutěžích dostaly téměř na 99. percentil, zatímco v jiné elitní disciplíně tentýž rok zůstaly kolem mediánu.

2021: HumanEval ukázal, že schopnost je distribuce, ne jediný pokus

Práce Evaluating Large Language Models Trained on Code představila Codex a spolu s ním HumanEval, 164 ručně napsaných programátorských úloh. Model dostal signaturu funkce, docstring a několik unit testů skrytých před generací.

Codex vyřešil 28,8 % úloh na první pokus. Když ale autoři ze stejného modelu vygenerovali 100 programů, alespoň jedno správné řešení se objevilo u 70,2 % úloh.

To je jeden z nejdůležitějších číselných rozdílů v celé historii:

pass@1   = 28,8 %
pass@100 = 70,2 %
oracle gap = 41,4 procentního bodu

Model tedy často správné řešení uměl vygenerovat, ale jeden pokus jej nedokázal spolehlivě vytěžit. Tím vznikly dvě odlišné výzkumné otázky:

1. jak zlepšit distribuci kandidátů;
2. jak bez znalosti skrytých testů poznat správný program mezi stovkou podobně přesvědčivých návrhů.

PRŮLOM 1: 28,8 % SE ZMĚNILO V 70,2 %

Repeated sampling: stejnému modelu položit tutéž úlohu mnohokrát. Správný program se objevil mnohem častěji, než naznačoval pass@1. Zrodil se ale problém selekce: oracle ví, který kandidát projde skrytými testy, reálný systém ne.

APPS: programátorská úloha už nebyla jen doplnění funkce

Benchmark APPS ve stejném roce přinesl 10 000 problémů od jednoduchých úloh po soutěžní algoritmické výzvy. Zadání bylo v přirozeném jazyce a správnost určovaly testovací případy. Tehdejší GPT-Neo zvládal přibližně 20 % jednotlivých testů u úvodních problémů, nikoliv 20 % kompletně vyřešených těžkých úloh.

APPS zavedl důležité rozlišení, které se někdy ztrácí dodnes: procento prošlých test cases není totéž jako procento plně vyřešených problémů. Program, který projde devíti testy z deseti, může mít prakticky užitečný základ. V soutěži s binárním checkerem ale stále získá nulu.

2022: AlphaCode změnil generování kódu v populační vyhledávání

AlphaCode byl první systém, který dosáhl přibližně úrovně mediánového účastníka v nových Codeforces soutěžích. Vyhodnocení použilo deset soutěží novějších než tréninková data. Nešlo o doplnění krátké funkce, ale o dlouhá zadání vyžadující kombinatoriku, grafy, dynamické programování a přesnou analýzu složitosti.

Architektura byla důležitější než jeden checkpoint:

zadání
  -> miliony různorodých programů
  -> kompilace a veřejné testy
  -> behaviorální clustery
  -> seřazení kandidátů
  -> nejvýše 10 submitů

AlphaCode předtrénoval transformery na veřejném kódu z GitHubu a dotrénoval je na soutěžních úlohách a řešeních. Při inferenci generoval řádově více programů než předchozí práce. Potom je filtroval, shlukoval a redukoval na deset pokusů.

V simulaci skončil průměrně v horních 54,3 % výsledkové listiny. To je často chybně přepisováno jako 54. percentil. Správně to znamená, že přibližně 45,7 % účastníků mělo horší výsledek.

PRŮLOM 2: MILIONY PROGRAMŮ, DESET SUBMITŮ

Population search: model nebyl soutěžící, který napsal jedno řešení. Byl generátorem populace. Samostatná vrstva kompilace, testování, deduplikace a výběru rozhodla, kteří členové populace dostanou vzácnou možnost být odesláni.

CodeContests: dataset obsahoval i chybná lidská řešení

DeepMind zveřejnil dataset CodeContests a exekuční nástroje. Data obsahují úlohy z Codeforces, AtCoderu, CodeChef a dalších zdrojů, testovací vstupy a výstupy a také správná i chybná lidská řešení.

Chybný kód je pro trénink překvapivě cenný. Umožňuje učit nejen „jak vypadá správné řešení“, ale i „které malé změny mění přijatý program v téměř správný program“. Pro budoucí critic a repair model je tato hranice užitečnější než další tisíc bezchybných šablon.

Tajná zbraň AlphaCode: shlukování podle chování, ne podle textu

Dva programy mohou vypadat úplně jinak a přitom implementovat stejný algoritmus. Naopak dvě téměř stejné implementace se mohou lišit jediným znaménkem a mít rozdílné chování na hranici rozsahu.

Proto AlphaCode neodvozoval diverzitu jen z textové podobnosti. Vygeneroval další vstupy, spustil na nich kandidátní programy a pro každý program vytvořil podpis jeho výstupů:

testy = generate_inputs(problem)

signature(program) = [
  run(program, test_1),
  run(program, test_2),
  ...,
  run(program, test_m)
]

clusters = group_by_similar_signature(programs)

Pokud deset tisíc programů vrací na všech diagnostických vstupech totéž, nemá smysl poslat deset jejich kosmetických variant. Lepší je vybrat jednoho zástupce a zbývající submission budget věnovat jiným behaviorálním hypotézám.

To je programátorský ekvivalent hlasování o normalizované matematické odpovědi, ale s mnohem bohatším signálem. Nehlasujeme pouze o konečném čísle. Porovnáváme funkce podle jejich chování na celé sadě cílených otázek.

Proč největší cluster není automaticky pravda

Behaviorální většina funguje, pokud správný algoritmus vytváří širokou oblast podobných implementací a chyby jsou roztříštěné. Může ale selhat, když modely sdílejí stejný populární omyl. Typickým příkladem je řešení, které projde ukázkou, ale ignoruje přetečení, duplicitní hodnoty nebo nejhorší asymptotický případ.

Proto cluster size není důkaz. Je to prior. Tvrdé testy, adversariální vstupy a kvalitní scorer musejí rozhodnout, zda je největší skupina moudrým davem, nebo davem se stejným bugem.

2023: AlphaCode 2, jeden milion kandidátů zúžený na deset

Technická zpráva AlphaCode 2 nabízí mimořádně konkrétní recept. Základem byla rodina modelů odvozených z Gemini Pro, nikoliv jediný generátor. Modely prošly dvěma koly fine-tuningu na aktualizovaném CodeContests datasetu a kvalitnější doplňkové sadě.

Aktualizovaný korpus měl přibližně 15 000 problémů a 30 milionů lidských programů. Rodina policy modelů vznikla s různými hyperparametry. Diverzita tedy nebyla ponechána jen náhodné teplotě, byla zabudována do rodiny generátorů.

Pro každý z 77 problémů z dvanácti nových Codeforces soutěží systém udělal následující:

1. vygeneroval až 1 000 000 C++ programů;
2. náhodně měnil teplotu a metadata v promptu;
3. rovnoměrně rozdělil budget mezi několik policy modelů;
4. spustil kandidáty na veřejných příkladech;
5. odstranil nekompilující a zjevně špatné programy;
6. z přibližně 50 000 přeživších vytvořil behaviorální clustery;
7. ponechal deset největších clusterů;
8. naučeným Gemini scorerem vybral nejlepšího zástupce každého clusteru;
9. odeslal nejvýše deset programů.

Veřejné testy a kompilace odstranily v průměru přibližně 95 % kandidátů. To je důležitý ekonomický princip: drahý naučený soudce se nemá plýtvat na kód, který nedokáže projít ani prvním příkladem.

Výsledek byl 43 % vyřešených problémů do deseti pokusů proti 25 % původního AlphaCode. Odhadované pořadí se posunulo z výkonu lepšího než asi 46 % účastníků na výkon lepší než 85 % účastníků.

Ještě působivější je efektivita. Přibližně 100 vzorků AlphaCode 2 stačilo k dosažení výkonu původního AlphaCode s milionem vzorků. Autoři proto uvádějí více než desetitisícinásobné zlepšení sample efficiency na této srovnávací úrovni.

PRŮLOM 3: 25 % SE ZMĚNILO V 43 % A MEDIÁN V 85. PERCENTIL

Diverse policies + execution + clustering + scorer: silnější model nezrušil potřebu vyhledávání. Změnil jeho ekonomiku. Sto nových vzorků mohlo mít hodnotu milionu starých, ale finální výsledek stále závisel na tvrdém filtru a selekci.

Jak vznikne milion kandidátů: sampling není totéž co tree search

Intuitivní vysvětlení často zní, že systém prohledával strom řešení. Historie je ale jemnější.

DeepCoder v roce 2017 skutečně používal klasické vyhledávání. Neuronová síť z příkladů odhadla, které funkce omezeného jazyka budou v programu potřeba, a těmito pravděpodobnostmi se řídil depth-first search, enumerativní solver nebo SMT solver. Model tedy zmenšoval a řadil explicitní kombinatorický prostor krátkých programů.

AlphaCode a AlphaCode 2 naproti tomu nevytvářely milion kandidátů pomocí jednoho obřího Monte Carlo tree search. Generativní transformer opakovaně autoregresivně vzorkoval celý program token po tokenu. Jednotlivé rollouts bylo možné spouštět nezávisle a masivně paralelně. Diverzitu vytvářely různé policy modely, jazyky, prompty, metadata a náhodně volená teplota. Teprve hotové programy prošly kompilací, veřejnými testy, behaviorálním clusteringem a scorerem.

nezávislý rollout 1  -> celý program -> testy
nezávislý rollout 2  -> celý program -> testy
...
nezávislý rollout N  -> celý program -> testy

nikoliv nutně:
kořen -> token -> token -> společný explicitní strom všech možností

Proč šel milion vůbec vyrobit? Soutěžní programy jsou relativně krátké, sampling lze dobře batchovat na akcelerátorech a rollouts na sebe nemusí čekat. Milion kandidátů přitom neznamená milion povolených submitů. AlphaCode 2 zredukoval milion surových programů asi na 50 000 přeživších po prvních filtrech, potom na deset behaviorálních clusterů a nakonec na deset skutečných odeslání.

U o1-IOI známe vnější rozhraní, nikoliv kompletní proprietární mechanismus. OpenAI uvádí, že systém vzorkoval mnoho kandidátů, vybíral 50 pomocí veřejných a generovaných testů a learned scoreru a v uvolněném experimentu dovolil 10 000 submitů na úlohu. Veřejná zpráva ale netvrdí, že uvnitř běžel MCTS. Víme, že o1 se zlepšuje s delším test-time compute a že umí opravovat vlastní postup. Přesný tvar interního větvení zveřejněn nebyl.

Dnešní agentní systémy navíc nevytvářejí diverzitu jen nezávislým samplingem. Typická smyčka je plán -> implementace -> kompilace -> failing test -> cílená oprava. Nový kandidát vznikne jako větev vyvolaná konkrétním důkazem chyby. Beam search, DFS nebo MCTS lze nad takovou smyčkou postavit, ale nejsou automatickým vysvětlením každého reasoning modelu.

Nejdůležitější trend je ekonomický: silnější policy dramaticky snižuje potřebný počet slepých vzorků. AlphaCode 2 dosáhl přibližně se 100 vzorky výkonu, na který původní AlphaCode potřeboval milion. Pro HyperFusion proto dává větší smysl vytvořit desítky záměrně odlišných plánů, měřit jejich chování a větvit jen tam, kde test odhalí spor, než bezhlavě vyrábět milion kosmetických variant.

Kompilátor není jen rozhodčí, je také učitel

Programování nabízí signály, které matematický text často nemá:

• parser ukáže syntaktickou chybu;
• kompilátor vrátí typ a řádek problému;
• runtime odhalí výjimku nebo přetečení;
• profiler ukáže časovou či paměťovou složitost;
• checker vrátí konkrétní vstup, na kterém řešení selhalo;
• rozdílové testování ukáže, kde se kandidáti rozcházejí.

Ne všechny signály jsou stejně hodnotné. Chyba kompilace často přímo ukazuje lokální opravu. „Wrong answer on hidden test 37“ téměř nic neříká. Nejlepší architektury proto nevnímají execution feedback jako jedinou zprávu, ale jako postupné zpřesňování diagnózy.

Generování testů jako aktivní experiment

Nejužitečnější test není náhodný vstup. Je to vstup, na kterém se dvě věrohodná řešení neshodnou. Má vysokou informační hodnotu, protože rozdělí hypotézy.

Představme si tři kandidáty:

• A používá greedy algoritmus;
• B dynamické programování;
• C stejný greedy postup, ale opravuje duplicity.

Náhodný test může vrátit stejné výsledky pro všechny. Aktivní generátor má hledat malý případ s duplicitou, případ s nulou, maximální rozsah a konstrukci, na níž greedy poruší globální optimum. Teprve potom se z testování stává vědecký experiment, nikoliv loterie.

2024: o1-IOI přesně změřil hodnotu selektoru

OpenAI vyhodnotilo specializovaný model odvozený z o1 na International Olympiad in Informatics 2024. Podle oficiálního popisu měl systém deset hodin na šest problémů a nejvýše 50 submitů na každý problém.

Pro každý problém vygeneroval mnoho kandidátů. Padesát odeslaných řešení vybíral podle tří signálů:

1. výkonu na veřejných IOI testech;
2. výkonu na testech vygenerovaných modelem;
3. naučené skórovací funkce.

Výsledek byl 213 bodů a 49. percentil soutěžících. OpenAI zároveň odhadlo, že náhodný výběr kandidátů by získal v průměru pouze 156 bodů.

stejný generátor + náhodný výběr       ≈ 156 bodů
stejný generátor + test-time selection = 213 bodů
hodnota selektoru                       ≈ +57 bodů

To je nejčistší dostupná ablace hodnoty kognitivní architektury. Správné programy už v populaci byly. Téměř 60 bodů nevytvořil další pretraining, ale schopnost investovat omezených 50 submitů do lepších kandidátů.

Když se limit uměle uvolnil na 10 000 submitů na problém, systém získal 362,14 bodu, nad hranicí zlaté medaile, a to i bez test-time selekce. Tento výsledek je cenný jako oracle experiment, ale není férovým soutěžním výsledkem. Ukazuje horní mez generátoru při téměř neomezeném pokusu, nikoliv schopnost pracovat pod pravidly IOI.

PRŮLOM 4: +57 BODŮ BEZE ZMĚNY GENERÁTORU

Public tests + generated tests + learned scorer: selektor rozhodoval, které z mnoha řešení spotřebuje omezený submission budget. Náhodný výběr nechával velkou část schopnosti modelu nevyužitou.

Codeforces rating: stejná rodina, jiný pohled

OpenAI také simulovalo Codeforces soutěže s deseti povolenými submity. GPT-4o dosáhl Elo 808, přibližně 11. percentilu. o1-preview dosáhl Elo 1258 a 62. percentilu, o1 Elo 1673 a 89. percentilu a specializovaný o1-IOI Elo 1807, tedy 93. percentilu.

Tato čísla nelze zaměnit s 49. percentilem na IOI. IOI vybírá nejtalentovanější středoškolské olympioniky světa a používá jiný typ úloh i bodování. Právě rozdíl mezi 93. percentilem Codeforces a 49. percentilem IOI připomíná, že „lidský percentil“ vždy potřebuje jmenovatel.

2024: benchmark se začal bránit kontaminaci

HumanEval byl zásadní, ale má pouze 164 úloh a rychle se stal součástí veřejného ekosystému. Jakmile se řešení, testy a odvozené varianty objeví v tréninkových datech, vysoké skóre může měřit paměť stejně jako zobecnění.

LiveCodeBench proto průběžně sbírá nové úlohy z LeetCode, AtCoderu a Codeforces. První verze obsahovala 400 úloh publikovaných od května 2023 do května 2024. Datum vydání úlohy umožňuje testovat modely na problémech, které vznikly až po jejich pravděpodobném datovém cut-offu.

LiveCodeBench navíc nehodnotí jen generování programu. Obsahuje scénáře pro:

• self-repair chybného kódu;
• předpovídání výstupu programu;
• práci s execution feedbackem;
• klasické generování řešení.

To je metodicky důležité. Model, který umí napsat řešení, nemusí umět najít konkrétní chybu. Model, který správně opraví známý bug, nemusí umět vymyslet algoritmus od nuly. Jediné coding score tyto schopnosti zbytečně slévá.

2025: Gemini Deep Think přinesl multiagentní tým k ICPC

Finále ICPC je jiný typ tlaku. Tým má pět hodin, jediný přijatý submit znamená bod a každý neúspěšný pokus přidává časovou penalizaci. Nestačí mít correct@1000. Potřebujete rychle najít správný algoritmus, implementovat jej a vědět, kdy jej odeslat.

Pokročilá verze Gemini 2.5 Deep Think řešila ICPC World Finals 2025 vzdáleně pod dohledem organizátorů. Začala o deset minut později než lidé, měla stejný pětihodinový limit a vyřešila 10 z 12 úloh. Osm úloh zvládla během prvních 45 minut, další dvě do tří hodin. S kombinovaným penalizačním časem 677 minut by při srovnání s oficiální tabulkou skončila druhá ze 139 týmů.

DeepMind popsal několik klíčových součástí:

• multi-step reasoning;
• paralelní myšlení;
• několik Gemini agentů s vlastními návrhy;
• přístup k terminálu;
• spouštění kódu a testů;
• iteraci podle výsledků všech pokusů;
• reinforcement learning na velmi těžkých programátorských úlohách.

Zveřejněny byly také finální programy Gemini pro ICPC 2025. Úplnou architekturu, počty vzorků a všechny interní prompty ale reprodukovat nelze. Jde o důležitý soutěžní milník, nikoliv o otevřený recept v kvalitě NuminaMath.

PRŮLOM 5: 10 Z 12 ÚLOH V PĚTI HODINÁCH

Parallel agents + terminals + iteration: agenti nenapsali pouze několik nezávislých programů. Viděli výsledky exekuce, opravovali se a využívali předchozí pokusy jako společnou experimentální paměť.

Problem C: řešení, které nenašel žádný univerzitní tým

Gemini za přibližně půl hodiny vyřešil Problem C, který nepřijal žádný lidský tým. Úloha požadovala optimální distribuci kapaliny sítí kanálů a zásobníků s nekonečně mnoha možnými nastaveními.

Podle zveřejněného popisu Gemini zavedl pro zásobníky prioritní hodnoty. Pro pevně zvolené priority šlo nejlepší nastavení kanálů najít dynamickým programováním. Potom pomocí minimaxového argumentu převedl původní úlohu na hledání priorit, které vytvářejí nejtěsnější omezení. V konvexním prostoru použil vnořené ternární vyhledávání.

Tento příklad je důležitý, protože to není pouze bezchybná implementace známé šablony. Úspěch vyžadoval několik reprezentací stejného problému:

fyzická síť
  -> priority zásobníků
  -> dynamické programování pro pevné priority
  -> minimaxová reformulace
  -> numerické hledání optimálních priorit

Právě schopnost změnit reprezentaci odděluje silného implementátora od algoritmického objevování.

2025 a 2026: střízlivá data proti příliš rychlému vítězství

Zprávy o medailových systémech mohou vytvořit dojem, že soutěžní programování je vyřešeno. Otevřenější benchmarky ukazují složitější obraz.

LiveCodeBench Pro: nula procent na hard bez nástrojů

LiveCodeBench Pro sestavili spolu s výzkumníky také medailisté mezinárodních algoritmických olympiád. Úlohy z Codeforces, ICPC a IOI průběžně aktualizovali, anotovali je podle algoritmických kategorií a řádek po řádku analyzovali chybná řešení modelů.

Bez externích nástrojů dosáhl nejlepší hodnocený model 53 % pass@1 na středně těžkých úlohách a 0 % na hard. Autoři zjistili, že modely jsou silnější v implementačně náročných problémech než v jemném algoritmickém uvažování a složité analýze případů. Často vytvářely sebevědomé, ale nesprávné zdůvodnění.

To neodporuje výsledku Gemini. Ukazuje to rozdíl mezi samostatným modelem bez nástrojů a drahou uzavřenou multiagentní architekturou s terminály, exekucí a iterací.

LiveOIBench: offline olympiády s lidským srovnáním

LiveOIBench, jehož třetí verze vyšla 8. července 2026, obsahuje 403 odborně vybrané úlohy ze 72 soutěží ve 14 informatických olympiádách z let 2023 až 2025. Každá úloha má v průměru okolo 60 oficiálních test cases a detailní subtask rubriku. Celé hodnocení lze spustit offline.

Ze 34 hodnocených modelů dosáhl GPT-5 81,76. percentilu, stále pod nejlepšími lidskými soutěžícími. Open-weight gpt-oss-120b dosáhl přibližně 60. percentilu. Analýza reasoning traces navíc naznačila, že robustnější modely preferují přesnou analýzu zadání před nadměrným chaotickým prohledáváním.

PRŮLOM 6: BENCHMARK UŽ NEMĚŘÍ JEN ACCEPTED / WRONG ANSWER

Fresh problems + subtasks + human percentiles: nová generace benchmarků sleduje datum úlohy, dílčí body, test coverage a přímé srovnání s elitními lidmi. Vysoký pass@k na malé statické sadě už nestačí.

Co v historii skutečně vyhrávalo

1. Diverzita algoritmů, ne jen slov

Změna teploty často vytvoří jiný styl stejného algoritmu. Skutečná diverzita znamená jinou datovou strukturu, invariant, asymptotiku nebo rozklad problému. AlphaCode 2 ji podporoval několika fine-tuned policies a měněnými metadaty.

2. Tvrdé filtry před drahým soudcem

Kompilace, veřejné testy, limity, sanitizery a statická kontrola jsou levnější a spolehlivější než LLM judge. AlphaCode 2 tak odstranil přibližně 95 % kandidátů ještě před finální selekcí.

3. Behaviorální deduplikace

Textově odlišný kód může být funkčně totožný. Shlukování podle výstupů na diagnostických vstupech chrání submission budget před deseti kopiemi stejné chyby.

4. Aktivně generované protipříklady

Nejlepší test rozlišuje dva silné kandidáty. Generátor testů má maximalizovat informační zisk, nikoliv počet náhodných vstupů.

5. Learned scorer jako poslední vrstva, ne jediná pravda

Scorer je užitečný tam, kde exekuce nerozhodla. Nemá přepisovat fakt, že program spadl, porušil limit nebo neprošel známým testem.

6. Cílená oprava

Když známe failing input, opravujeme konkrétní invariant nebo řádek. Volná syntéza dvou programů může zničit části, které už byly správné.

7. Test-time compute s rozpočtem

Sto kandidátů bez selektoru je oracle experiment. Reálná architektura musí optimalizovat očekávaný počet bodů na GPU-sekundu, kompilaci a povolený submit.

8. Oddělení profesí

Plánovač, implementátor, generátor testů, kritik a selektor mají jiné cíle. Jeden model může role střídat, ale protokol musí zabránit tomu, aby autor pouze potvrdil vlastní řešení.

Co naopak opakovaně nefungovalo

1. Sto téměř totožných implementací

Zvyšují pass@k méně, než naznačuje počet vzorků. Korelovaná chyba přežije hlasování i reranking.

2. Optimalizace pouze na veřejné ukázky

Ukázkový test vysvětluje formát, nikoliv plnou specifikaci. Model se snadno naučí patch pro tři příklady a mine obecný algoritmus.

3. „Kód vypadá správně“ jako hlavní metrika

Jazykový soudce často preferuje čisté názvy, komentáře a přesvědčivé vysvětlení. Skrytý checker se o styl nezajímá.

4. Random submit

Experiment o1-IOI naměřil téměř 60bodový rozdíl mezi náhodným a inteligentním výběrem stejné populace.

5. Self-reflection bez nového důkazu

Výzva „zkontroluj se“ často vytvoří delší racionalizaci. Oprava má dostat nový test, traceback, counterexample nebo konflikt s jiným kandidátem.

6. Smíchání oracle@k s nasaditelným výkonem

Deset tisíc submitů nad hranicí zlata neznamená zlatou medaili pod limitem padesáti pokusů. Oracle je diagnostika potenciálu generátoru.

7. Benchmark bez časové provenance

U veřejného problému potřebujeme datum zveřejnění, datum modelového cut-offu, dostupnost řešení a hash konkrétní verze datasetu.

Jak bych z toho postavil HyperFusion Code

Historie ukazuje architekturu, která není prostým majority vote. Je to řízený experimentální cyklus.

Původní úvodní ilustrace zde dostává přesnější roli: znázorňuje fúzi více nezávislých proudů uvažování, nikoliv samotné programování.

Fáze 1: otisk problému

Router nejprve odhadne:

• algoritmickou oblast;
• očekávanou složitost;
• potřebu matematického důkazu;
• rizikové hraniční případy;
• zda je vhodnější C++, Python nebo jiný jazyk;
• kolik inference budgetu úloha zaslouží.

Router nemá rovnou řešit. Má vytvořit experimentální plán.

Fáze 2: slepá soutěž algoritmických návrhů

Tři až pět různých lokálních modelů vytvoří pouze návrh algoritmu, invariant a odhad složitosti. Nevidí návrhy ostatních. Tím se zabrání předčasné konvergenci na první sebevědomou myšlenku.

Návrhy se seskupí podle skutečného principu:

• greedy;
• dynamické programování;
• grafová transformace;
• tok nebo matching;
• matematická konstrukce;
• search s pruningem;
• randomizovaný nebo numerický postup.

Do další fáze postupují nejvýše dva reprezentanti každé rodiny.

Fáze 3: více implementací silných plánů

Každý přeživší plán implementují nejméně dva modely. Tím oddělíme chybu algoritmu od chyby zápisu. Pokud dvě nezávislé implementace stejného plánu dávají jiné výsledky, získáváme velmi cenný diagnostický konflikt.

Fáze 4: test forge

Samostatný agent vytváří:

• minimální případy;
• nulu a prázdný vstup, pokud jsou povolené;
• duplicity a shodné hodnoty;
• maximální velikost;
• hodnoty u hranic datových typů;
• případy porušující greedy intuici;
• vstupy, na kterých se kandidáti liší;
• metamorfní transformace se známou relací výstupů.

Pokud známe pomalý referenční algoritmus pro malé n, používáme differential testing. Pro malé případy vyčerpávajícím způsobem porovnáme rychlé kandidáty s brute force.

Fáze 5: cílená oprava

Kandidát dostane pouze:

• původní plán;
• vlastní kód;
• konkrétní failing input;
• očekávaný a skutečný výstup;
• případně diagnostiku sanitizeru nebo limitu.

Úkolem není „napiš lepší řešení“, ale „najdi minimální příčinu tohoto selhání a oprav ji bez změny ostatních invariantů“.

Fáze 6: turnajový selektor

Pořadí kandidátů kombinuje tvrdé a měkké signály:

score =
    1000 * known_tests_passed
  - 1000 * crash_or_timeout
  +  120 * independent_implementations_agree
  +   80 * adversarial_tests_passed
  +   40 * predicted_correctness
  +   20 * algorithmic_diversity_bonus
  -   10 * unexplained_complexity_risk

Konkrétní váhy musejí být zamknuté na validační sadě. Testovací sada slouží pouze k jednorázovému reportu.

Fáze 7: auditovatelný submit

Systém uloží:

• všechny algoritmické návrhy;
• zdrojový model a seed;
• programy a jejich hashe;
• kompilátor a flags;
• všechny generované testy;
• výsledky exekuce;
• opravy a jejich důvody;
• finální skóre selektoru;
• skutečný výsledek skrytého checkeru.

Bez této stopy nelze zjistit, zda zlepšení přinesl model, generátor testů, repair loop nebo pouze větší počet pokusů.

Konkrétní experiment pro LUMI

Navrhoval bych experiment Exp05: Behavioral Code Fusion. Nejdřív by nepoužíval žádný drahý judge model. Využil by pouze lokální řešitele, kompilátor, sanitizery, brute-force reference a behaviorální shodu.

Dataset

1. trénovací sada pro nastavení pravidel a vah;
2. validační sada pro volbu budgetu a stopping rule;
3. uzamčená testovací sada podle data zveřejnění;
4. dodatečný čerstvý holdout z LiveCodeBench nebo LiveOIBench.

Rozdělení musí být podle problémů a jejich původu, ne podle jednotlivých programů. Jinak by dvě téměř stejné varianty úlohy mohly skončit na obou stranách splitu.

Kandidátní konfigurace

Pro každý problém:

3 různé modely
× 3 algoritmické plány na model
× 2 implementace pro vybrané plány
= nejvýše 18 programů před repair

To je záměrně menší budget než milion vzorků AlphaCode. Cílem je změřit, kolik výkonu vytvoří diverzita modelů a execution feedback při lokálně realistické ceně.

Ablace

Tato posloupnost přesně ukáže mezní hodnotu každé vrstvy. Když varianta E nepřidá výkon, generátor testů nevytváří informativní vstupy. Když G nepřidá nic nad F, drahý scorer není potřeba.

Metriky

Nestačí jedno procento:

• pass@1 nejsilnějšího modelu;
• oracle@18;
• selected@1;
• selected@3;
• průměrné body ze subtasks;
• oracle gap a selector recovery rate;
• počet behaviorálních clusterů;
• pairwise error correlation mezi modely;
• počet kompilací a spuštění;
• GPU-sekundy, CPU-sekundy a energie;
• čas do prvního accepted řešení;
• kolik oprav odstranilo původní bug a kolik vytvořilo nový.

Klíčová metrika selektoru může být:

selector recovery =
  (selected@1 - pass@1_best_single)
  / (oracle@k - pass@1_best_single)

Říká, jakou část dostupného oracle gapu dokázala architektura skutečně získat bez přístupu ke skrytému řešení.

Co by bylo skutečným výsledkem výzkumu

Nejcennějším výstupem by nebylo tvrzení „tři modely jsou lepší než jeden“. To lze očekávat už z pass@k. Výzkumně zajímavé jsou tyto otázky:

1. Má diverzita modelových rodin větší hodnotu než stejný počet vzorků nejlepšího modelu?
2. Dokáže behaviorální clustering předpovědět korelovanou chybu?
3. Který typ automatického testu nejvíc zvyšuje selector recovery?
4. Kdy oprava pomáhá a kdy poškodí správný základ?
5. Lze nejistotu odhadnout z neshody kandidátů lépe než z vlastního confidence modelu?
6. Jak se optimální architektura mění s paměťovým a časovým rozpočtem?
7. Potřebujeme velkého soudce, nebo většinu sporů rozhodne exekuce?

Paralelní větev: soutěžní programování není běžný software engineering

HumanEval, Codeforces, IOI a ICPC mají jasné zadání, čistý vstup, očekávaný výstup a relativně izolovaný program. Reálný repozitář je jiný svět. Zadání může být neúplné, testy zastaralé a správná oprava může vyžadovat pochopení stovek souborů.

Proto bych do hlavní časové osy nemíchal SWE-bench a agenty opravující GitHub issues. Zaslouží si samostatný článek. Principy jsou příbuzné, ale role testů je jiná: v soutěži testy definují pravdu, v reálném vývoji mohou být samy součástí problému.

Co si odnést

Historie soutěžního programování AI není jednoduchý příběh stále větších modelů. Je to historie stále lepší organizace pokusů:

1. HumanEval odhalil obrovský rozdíl mezi pass@1 a pass@100.
2. AlphaCode proměnil generování v populační search.
3. AlphaCode 2 spojil různé policy modely, execution, behaviorální clustering a learned scorer.
4. o1-IOI změřil, že selekce stejné populace měla hodnotu přibližně 57 bodů.
5. LiveCodeBench přidal čerstvá data a více schopností než samotné generování.
6. Gemini na ICPC použil paralelní agenty, terminály a iterativní opravu.
7. LiveCodeBench Pro a LiveOIBench ukázaly, že elitní algoritmické uvažování stále není vyřešené.

Konečný princip: nejchytřejší programátorský systém není ten, který nejdéle přemýšlí v jednom monologu. Je to systém, který umí vytvářet nezávislé hypotézy, navrhovat experimenty, sbírat tvrdé důkazy, opravovat konkrétní chyby a hospodařit s omezeným rozpočtem submitů.

Právě programování může být pro HyperFusion ideální laboratoří. Máme zde něco, co u otevřených humanitních otázek často chybí: levnou zpětnou vazbu z reality. Když ji dobře využijeme, nepotřebujeme, aby jeden model byl dokonalý. Potřebujeme, aby se celý systém uměl učit z každého neúspěšného běhu.

Primární zdroje a reprodukční materiály

• DeepCoder: Learning to Write Programs
• Evaluating Large Language Models Trained on Code, Codex a HumanEval
• Measuring Coding Challenge Competence With APPS
• Competition-level code generation with AlphaCode
• DeepMind: Competitive programming with AlphaCode
• CodeContests dataset a exekuční nástroje
• AlphaCode 2 Technical Report
• OpenAI: Learning to reason with LLMs, část o IOI a Codeforces
• LiveCodeBench
• LiveCodeBench repository a evaluation harness
• LiveCodeBench Pro
• LiveOIBench
• Gemini 2.5 Deep Think na ICPC World Finals 2025
• Zveřejněné programy Gemini z ICPC 2025
• Původní příspěvek Andreje Karpathyho k pojmu vibe coding
• Collins Word of the Year 2025: vibe coding
• Stack Overflow Developer Survey 2025: AI a vibe coding
• METR: měření produktivity zkušených open-source vývojářů s AI