Ako sa AI naučila programovať: Od HumanEval k zlatej medaile z ICPC

Programovanie má proti matematickému uvažovaniu jednu veľkú výhodu: odpoveď môžeme spustiť. Program sa buď skompiluje, alebo neskompiluje. Na konkrétnom vstupe vráti konkrétny výstup. Môžeme zmerať čas, pamäť a porovnať výsledok so skrytým checkerom. V našom nedávnom článku o ceste AI od GSM8K k dôkazovým agentom sme sledovali, ako sa matematické systémy naučili vytvárať viac postupov, hlasovať a overovať dôkazy. Tento článok na rovnaký príbeh nadväzuje v prostredí, kde možno výsledok nielen posúdiť, ale skutočne spustiť.

To zvádza k predstave, že súťažné programovanie je pre AI jednoduchšie ako matematika. V skutočnosti je to tvrdšie a zároveň čistejšie laboratórium. Model musí z dlhého zadania odvodiť skrytý algoritmus, dokázať si jeho korektnosť, previesť ho do bezchybného programu a prežiť vstupy, ktoré nikdy nevidel. Jediná zabudnutá hraničná podmienka znamená nulu.

Za päť rokov sa preto zmenil nielen výkon modelov, ale celý spôsob, akým nechávame AI programovať. V roku 2021 sme sa pýtali, či jeden model na prvý pokus doplní krátku funkciu. V roku 2025 už niekoľko agentov paralelne navrhovalo algoritmy, spúšťalo kompilátor a testy, zdieľalo nájdené chyby a iterovalo až na riešenie na úrovni zlatej medaily z ICPC.

Tento text je technická história tejto premeny. Nejde len o to, ktorý model získal koľko bodov, ale hlavne o to, aký algoritmus inferencie, selekcie a verifikácie tento výsledok vyrobil. Práve tieto princípy sú prenositeľné do HyperFusion a do experimentov na LUMI.

Hlavný záver: najväčší skok nepriniesol model, ktorý napísal jeden dokonalejší program. Priniesli ho systémy, ktoré vytvorili populáciu rôznych algoritmov, lacno vyradili zjavné chyby, hľadali protipríklady, opravovali len dokázané vady a inteligentne rozhodovali, ktoré programy vôbec stoja za odoslanie.

Od našepkávania k vibe codingu

Pojem vibe coding zaviedol Andrej Karpathy 2. februára 2025 pre spôsob práce, pri ktorom človek opisuje zámer prirodzeným jazykom, prijíma veľké zmeny vytvorené AI a postupne systém smeruje bez toho, aby nutne čítal každý riadok. Počas niekoľkých mesiacov sa z technického slangu stal kultúrny pojem a Collins ho vybral ako slovo roku 2025.

VYSVETLIVKA: ČO JE VIBE CODING

V čistej podobe nejde len o autocomplete ani o občasnú radu chatbotu. Programátor presúva pozornosť zo syntaxe na zámer, správanie aplikácie a ďalšiu inštrukciu pre model. Kód môže vznikať po veľkých blokoch a autor ho nemusí detailne chápať. To je skvelé pre prototyp, ale nebezpečné všade, kde chýbajú testy, bezpečnostná kontrola a niekto, kto rozumie výslednému systému.

Je dôležité nezameniť rýchly rast AI nástrojov s čistým vibe codingom. Stack Overflow Developer Survey 2025 uvádza, že AI nástroje používa alebo plánuje používať 84% respondentov, oproti 76% o rok skôr, a 51% profesionálnych vývojárov ich používa denne. Súčasne však 72 % respondentov uviedlo, že vibe coding nie je súčasťou ich profesionálnej práce. Masovo sa rozšírila AI asistencia, nie automaticky ochota prestať kód kontrolovať.

Triezvejšiu korekciu pridal experiment METR z prvej polovice roka 2025. Šestnásť skúsených open-source vývojárov riešilo 246 úloh vo vlastných repozitároch as vtedajšími AI nástrojmi im práca trvala v priemere o 19 % dlhšie. Je to úzky časový snímok, nie univerzálny verdikt nad AI programovaním. Pripomína však, že rýchle rozšírenie nástroja ešte samo o sebe nedokazuje vyššiu produktivitu.

Súťažné programovanie je preto zaujímavým protipólom vibe codingu. Môžeme generovať kód veľmi voľne, ale nakoniec musí prejsť presným checkerom. Výskumne cenná nie je samotná rýchlosť písania, ale schopnosť zmeniť vágny prúd návrhov na overený program.

Najskôr pravidlá: Codeforces, IOI a ICPC nie sú rovnaká disciplína

Číslo ako „85. percentil v programovaní“ znie jednoznačnejšie, než v skutočnosti je. Codeforces, International Olympiad in Informatics a ICPC testujú príbuzné, ale odlišné zručnosti.

Tiež metriky meria rôzne veci:

Preto v článku nebudem kresliť jednu falošne hladkú krivku „všeobecnej programátorskej inteligencie“. Pri každom bode časovej osi uvádzam platformu, počet pokusov, nástroje a spôsob prepočtu na ľudské poradie.

Časová os ľudského ekvivalentu

Prvé systémy ešte žiadny dôveryhodný ľudský percentil nemali. DeepCoder v roku 2017 urýchlil enumeratívne hľadanie krátkych programov približne o jeden rád, ale pracoval v obmedzenom DSL a riešil len úlohy obtiažností podobné najjednoduchším súťažným zadaním. Codex v roku 2021 dosiahol 28,8 % pass@1 na HumanEval, ale HumanEval nemá výsledkovú listinu ľudských súťažiacich. Tieto míľniky preto patria na os, nie na percentilovú stupnicu.

Od roku 2022 už máme niekoľko priamych, hoci stále nie celkom zameniteľných porovnaní s ľuďmi. Do grafu dávam iba frontier systém danej doby a jeho verejne doložený výsledok:

• AlphaCode, Codeforces 2022: prekonal približne 45,7 % súťažiacich, teda výkon okolo mediánu.
• AlphaCode 2, Codeforces 2023: prekonal v priemere 85 % účastníkov. V dvoch najlepších súťažiach však prekonal viac ako 99,5 % účastníkov. Práve tento rozptyl ukazuje, prečo samotný priemer skrýva dôležitú časť príbehu.
• o1, Codeforces 2024: všeobecný o1 dosiahol 89. percentilu. Variant ďalej trénovaný pre IOI dosiahol Elo 1807 a 93. percentil.
• o1-IOI, IOI 2024: pod skutočným limitom 50 submitov na úlohu získal 213 bodov a 49. percentil elitných stredoškolských olympionikov.
• GPT-5, LiveOIBench 2025: na 403 úlohách z olympiád rokov 2023 až 2025 dosiahol 81,76. percentilu. Autori upozorňujú, že najlepší ľudia v tomto súbore bývajú nad 90. percentilom.
• Gemini 2.5 Deep Think, ICPC 2025: desať vyriešených úloh by znamenalo druhé miesto zo 139 tímov, teda lepší výsledok ako približne 98,6 % výsledkovej listiny. Ide o hypotetický prepočet, pretože Gemini nebol oficiálne zaradeným univerzitným tímom.

Čiaru spájam iba medzi výsledkami z rovnakej rodiny Codeforces. IOI, ICPC a LiveOIBench zostávajú ako samostatné body, pretože ich populácia aj pravidlá sú iné. Zvislá úsečka pri AlphaCode 2 nie je interval spoľahlivosti, ale rozdiel medzi priemerom a dvoma najlepšími súťažami. Graf tak ukazuje dve pravdy súčasne: frontier systémy sa v niektorých súťažiach dostali takmer na 99. percentil, zatiaľ čo v inej elitnej disciplíne v tom istom roku zostali okolo mediánu.

2021: HumanEval ukázal, že schopnosť je distribúcia, nie jediný pokus

Práca Evaluating Large Language Models Trained on Code predstavila Codex a spolu s ním HumanEval, 164 ručne napísaných programátorských úloh. Model dostal signatúru funkcie, docstring a niekoľko unit testov skrytých pred generáciou.

Codex vyriešil 28,8 % úloh na prvý pokus. Keď ale autori z rovnakého modelu vygenerovali 100 programov, aspoň jedno správne riešenie sa objavilo pri 70,2 % úloh.

To je jeden z najdôležitejších číselných rozdielov v celej histórii:

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

Model teda často správne riešenie vedel vygenerovať, ale jeden pokus ho nedokázal spoľahlivo vyťažiť. Tým vznikli dve odlišné výskumné otázky:

1. ako zlepšiť distribúciu kandidátov;
2. ako bez znalosti skrytých testov spoznať správny program medzi stovkou podobne presvedčivých návrhov.

PRIELOM 1: 28,8 % SA ZMENILO NA 70,2 %

Repeated sampling: rovnakému modelu položiť tú istú úlohu mnohokrát. Správny program sa objavil oveľa častejšie, než naznačoval pass@1. Zrodil sa ale problém selekcie: oracle vie, ktorý kandidát prejde skrytými testami, reálny systém nie.

APPS: programátorská úloha už nebola len doplnenie funkcie

Benchmark APPS v rovnakom roku priniesol 10 000 problémov od jednoduchých úloh po súťažné algoritmické výzvy. Zadanie bolo v prirodzenom jazyku a správnosť určovali testovacie prípady. Vtedajší GPT-Neo zvládal približne 20 % jednotlivých testov pri úvodných problémoch, nie 20 % kompletne vyriešených ťažkých úloh.

APPS zaviedol dôležité rozlíšenie, ktoré sa niekedy stráca dodnes: percento minulých test cases nie je to isté ako percento plne vyriešených problémov. Program, ktorý prejde deviatimi testami z desiatich, môže mať prakticky užitočný základ. V súťaži s binárnym checkerom ale stále získa nulu.

2022: AlphaCode zmenil generovanie kódu v populačné vyhľadávanie

AlphaCode bol prvý systém, ktorý dosiahol približne úroveň mediánového účastníka v nových Codeforces súťažiach. Vyhodnotenie použilo desať súťaží novších ako tréningové dáta. Nešlo o doplnenie krátkej funkcie, ale o dlhé zadania vyžadujúce kombinatoriku, grafy, dynamické programovanie a presnú analýzu zložitosti.

Architektúra bola dôležitejšia ako 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 predtrénoval transformery na verejnom kóde z GitHubu a dotrénoval ich na súťažných úlohách a riešeniach. Pri inferencii generoval rádovo viac programov ako predchádzajúce práce. Potom ich filtroval, zhlukoval a redukoval na desať pokusov.

V simulácii skončil priemerne v horných 54,3% výsledkovej listiny. To je často chybne prepisované ako 54. percentil. Správne to znamená, že približne 45,7 % účastníkov malo horší výsledok.

PRIELOM 2: MILIÓNY PROGRAMOV, DESAŤ SUBMITOV

Population search: model nebol súťažiaci, ktorý napísal jedno riešenie. Bol generátorom populácie. Samostatná vrstva kompilácie, testovania, deduplikácie a výberu rozhodla, ktorí členovia populácie dostanú vzácnu možnosť byť odoslaní.

CodeContests: dataset obsahoval aj chybné ľudské riešenia

DeepMind zverejnil dataset CodeContests a exekučné nástroje. Dáta obsahujú úlohy z Codeforces, AtCoderu, CodeChef a ďalších zdrojov, testovacie vstupy a výstupy a tiež správne aj chybné ľudské riešenia.

Chybný kód je pre tréning prekvapivo cenný. Umožňuje učiť nielen „ako vyzerá správne riešenie“, ale aj „ktoré malé zmeny menia prijatý program na takmer správny program“. Pre budúci critic a repair model je táto hranica užitočnejšia ako ďalší tisíc bezchybných šablón.

Tajná zbraň AlphaCode: zhlukovanie podľa správania, nie podľa textu

Dva programy môžu vyzerať úplne inak a pritom implementovať rovnaký algoritmus. Naopak dve takmer rovnaké implementácie sa môžu líšiť jediným znamienkom a mať rozdielne správanie na hranici rozsahu.

Preto AlphaCode neodvodzoval diverzitu iba z textovej podobnosti. Vygeneroval ďalšie vstupy, spustil na nich kandidátne programy a pre každý program vytvoril podpis jeho výstupov:

testy = generate_inputs(problem)

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

clusters = group_by_similar_signature(programs)

Ak desaťtisíc programov vracia na všetkých diagnostických vstupoch to isté, nemá zmysel poslať desať ich kozmetických variantov. Lepšie je vybrať jedného zástupcu a zostávajúce submission budget venovať iným behaviorálnym hypotézam.

To je programátorský ekvivalent hlasovania o normalizovanej matematickej odpovedi, ale s oveľa bohatším signálom. Nehlasujeme iba o konečnom čísle. Porovnávame funkcie podľa ich správania na celej sade cielených otázok.

Prečo najväčší klaster nie je automaticky pravda

Behaviorálna väčšina funguje, ak správny algoritmus vytvára širokú oblasť podobných implementácií a chyby sú roztrieštené. Môže ale zlyhať, keď modely zdieľajú rovnaký populárny omyl. Typickým príkladom je riešenie, ktoré prejde ukážkou, ale ignoruje pretečenie, duplicitné hodnoty alebo najhorší asymptotický prípad.

Preto cluster size nie je dôkaz. Je to prior. Tvrdé testy, adversariálne vstupy a kvalitný scorer musia rozhodnúť, či je najväčšia skupina múdrym davom alebo davom s rovnakým bugom.

2023: AlphaCode 2, jeden milión kandidátov zúžený na desať

Technická správa AlphaCode 2 ponúka mimoriadne konkrétny recept. Základom bola rodina modelov odvodených z Gemini Pro, nie jediný generátor. Modely prešli dvoma kolesami fine-tuningu na aktualizovanom CodeContests datasete a kvalitnejšej doplnkovej sade.

Aktualizovaný korpus mal približne 15 000 problémov a 30 miliónov ľudských programov. Rodina policy modelov vznikla s rôznymi hyperparametrmi. Diverzita teda nebola ponechaná len náhodnej teplote, bola zabudovaná do rodiny generátorov.

Pre každý z 77 problémov z dvanástich nových Codeforces súťaží systém urobil nasledujúce:

1. vygeneroval až 1 000 000 C++ programov;
2. náhodne menil teplotu a metadáta v prompte;
3. rovnomerne rozdelil budget medzi niekoľko policy modelov;
4. spustil kandidátov na verejných príkladoch;
5. odstránil nekompilujúce a zjavne zlé programy;
6. z približne 50 000 preživších vytvoril behaviorálne klastre;
7. ponechal desať najväčších klastrov;
8. naučeným Gemini scorerom vybral najlepšieho zástupcu každého klastra;
9. odoslal najviac desať programov.

Verejné testy a kompilácie odstránili v priemere približne 95 % kandidátov. To je dôležitý ekonomický princíp: drahý naučený sudca sa nemá plytvať na kód, ktorý nedokáže prejsť ani prvým príkladom.

Výsledok bol 43% vyriešených problémov do desiatich pokusov proti 25% pôvodného AlphaCode. Odhadované poradie sa posunulo z výkonu lepšieho ako asi 46 % účastníkov na výkon lepší ako 85 % účastníkov.

Ešte pôsobivejšia je efektivita. Približne 100 vzoriek AlphaCode 2 stačilo na dosiahnutie výkonu pôvodného AlphaCode s miliónom vzoriek. Autori preto uvádzajú viac ako desaťtisícinásobné zlepšenie sample efficiency na tejto porovnávacej úrovni.

PRIELOM 3: 25 % SA ZMENILO NA 43 % A MEDIÁN V 85. PERCENTIL

Diverse policies + execution + clustering + scorer: silnejší model nezrušil potrebu vyhľadávania. Zmenil jeho ekonomiku. Sto nových vzoriek mohlo mať hodnotu milióna starých, ale finálny výsledok stále závisel od tvrdého filtra a selekcie.

Ako vznikne milión kandidátov: sampling nie je to isté ako tree search

Intuitívne vysvetlenie často znie, že systém prehľadával strom riešenia. História je ale jemnejšia.

DeepCoder v roku 2017 skutočne používal klasické vyhľadávanie. Neurónová sieť z príkladov odhadla, ktoré funkcie obmedzeného jazyka budú v programe potrebné, a týmito pravdepodobnosťami sa riadil depth-first search, enumeratívny solver alebo SMT solver. Model teda zmenšoval a radil explicitný kombinatorický priestor krátkych programov.

AlphaCode a AlphaCode 2 naproti tomu nevytvárali milión kandidátov pomocou jedného obrieho Monte Carlo tree search. Generatívny transformer opakovane autoregresívne vzorkoval celý program token po tokene. Jednotlivé rollouts bolo možné spúšťať nezávisle a masívne paralelne. Diverzitu vytvárali rôzne policy modely, jazyky, prompty, metadáta a náhodne volená teplota. Až hotové programy prešli kompiláciou, verejnými testami, behaviorálnym clusteringom a scorerom.

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í

Prečo šiel milión vôbec vyrobiť? Súťažné programy sú relatívne krátke, sampling je možné dobre batchovať na akcelerátoroch a rollouts na seba nemusia čakať. Milión kandidátov pritom neznamená milión povolených submitov. AlphaCode 2 zredukoval milión surových programov asi na 50 000 preživších po prvých filtroch, potom na desať behaviorálnych klastrov a nakoniec na desať skutočných odoslaní.

U o1-IOI poznáme vonkajšie rozhranie, nie kompletný proprietárny mechanizmus. OpenAI uvádza, že systém vzorkoval mnoho kandidátov, vyberal 50 pomocou verejných a generovaných testov a learned scorerov av uvoľnenom experimente dovolil 10 000 submitov na úlohu. Verejná správa ale netvrdí, že vo vnútri bežal MCTS. Vieme, že o1 sa zlepšuje s dlhším test-time compute a že dokáže opravovať vlastný postup. Presný tvar interného vetvenia zverejnený nebol.

Dnešné agentové systémy navyše nevytvárajú diverzitu iba nezávislým samplingom. Typická slučka je plán -> implementácia -> kompilácia -> failing test -> cielená oprava. Nový kandidát vznikne ako vetva vyvolaná konkrétnym dôkazom chyby. Beam search, DFS alebo MCTS je možné nad takou slučkou postaviť, ale nie sú automatickým vysvetlením každého reasoning modelu.

Najdôležitejší trend je ekonomický: silnejšie policy dramaticky znižuje potrebný počet slepých vzoriek. AlphaCode 2 dosiahol približne so 100 vzorkami výkonu, na ktorý pôvodný AlphaCode potreboval milión. Pre HyperFusion preto dáva väčší zmysel vytvoriť desiatky zámerne odlišných plánov, merať ich správanie a vetviť len tam, kde test odhalí spor, než bezhlavo vyrábať milión kozmetických variantov.

Kompilátor nie je len rozhodca, je aj učiteľ

Programovanie ponúka signály, ktoré matematický text často nemá:

• parser ukáže syntaktickú chybu;
• kompilátor vráti typ a riadok problému;
• runtime odhalí výnimku alebo pretečenie;
• profiler ukáže časovú či pamäťovú zložitosť;
• checker vráti konkrétny vstup, na ktorom riešenie zlyhalo;
• rozdielové testovanie ukáže, kde sa kandidáti rozchádzajú.

Nie všetky signály sú rovnako hodnotné. Chyba kompilácie často priamo ukazuje lokálnu opravu. „Wrong answer on hidden test 37“ takmer nič nehovorí. Najlepšie architektúry preto nevnímajú execution feedback ako jedinú správu, ale ako postupné spresňovanie diagnózy.

Generovanie testov ako aktívny experiment

Najužitočnejší test nie je náhodný vstup. Je to vstup, na ktorom sa dve vierohodné riešenia nezhodnú. Má vysokú informačnú hodnotu, pretože rozdelí hypotézy.

Predstavme si troch kandidátov:

• A používa greedy algoritmus;
• B dynamické programovanie;
• C rovnaký greedy postup, ale opravuje duplicity.

Náhodný test môže vrátiť rovnaké výsledky pre všetkých. Aktívny generátor má hľadať malý prípad s duplicitou, prípad s nulou, maximálny rozsah a konštrukciu, na ktorej greedy porušia globálne optimum. Až potom sa z testovania stáva vedecký experiment, nie lotérie.

2024: o1-IOI presne zmeral hodnotu selektora

OpenAI vyhodnotilo špecializovaný model odvodený z o1 na International Olympiad in Informatics 2024. Podľa oficiálneho popisu mal systém desať hodín na šesť problémov a najviac 50 submitov na každý problém.

Pre každý problém vygeneroval mnoho kandidátov. Päťdesiat odoslaných riešení vyberal podľa troch signálov:

1. výkonu na verejných IOI testoch;
2. výkonu na testoch vygenerovaných modelom;
3. naučené skórovacie funkcie.

Výsledok bol 213 bodov a 49. percentil súťažiacich. OpenAI zároveň odhadlo, že náhodný výber kandidátov by získal v priemere iba 156 bodov.

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

To je najčistejšia dostupná ablácia hodnoty kognitívnej architektúry. Správne programy už v populácii boli. Takmer 60 bodov nevytvoril ďalší pretraining, ale schopnosť investovať obmedzených 50 submitov do lepších kandidátov.

Keď sa limit umelo uvoľnil na 10 000 submitov na problém, systém získal 362,14 bodu, nad hranicou zlatej medaily, a to aj bez test-time selekcie. Tento výsledok je cenný ako oracle experiment, ale nie je férovým súťažným výsledkom. Ukazuje hornú hranicu generátora pri takmer neobmedzenom pokuse, nie schopnosť pracovať pod pravidlami IOI.

PRIELOM 4: +57 BODOV BEZ ZMENY GENERÁTORA

Public tests + generated tests + learned scorer: selektor rozhodoval, ktoré z mnohých riešení spotrebuje obmedzený submission budget. Náhodný výber nechával veľkú časť schopnosti modelu nevyužitú.

Codeforces rating: rovnaká rodina, iný pohľad

OpenAI tiež simulovalo Codeforces súťaže s desiatimi povolenými submitmi. GPT-4o dosiahol Elo 808, približne 11. percentilu. o1-preview dosiahol Elo 1258 a 62. percentil, o1 Elo 1673 a 89. percentil a špecializovaný o1-IOI Elo 1807, teda 93. percentil.

Tieto čísla nie je možné zameniť so 49. percentilom na IOI. IOI vyberá najtalentovanejšie stredoškolské olympioniky sveta a používa iný typ úloh i bodovania. Práve rozdiel medzi 93. percentilom Codeforces a 49. percentilom IOI pripomína, že „ľudský percentil“ vždy potrebuje menovateľ.

2024: benchmark sa začal brániť kontaminácii

HumanEval bol zásadný, ale má iba 164 úloh a rýchlo sa stal súčasťou verejného ekosystému. Akonáhle sa riešenia, testy a odvodené varianty objavia v tréningových dátach, vysoké skóre môže merať pamäť rovnako ako zovšeobecnenie.

LiveCodeBench preto priebežne zbiera nové úlohy z LeetCode, AtCoderu a Codeforces. Prvá verzia obsahovala 400 úloh publikovaných od mája 2023 do mája 2024. Dátum vydania úlohy umožňuje testovať modely na problémoch, ktoré vznikli až po ich pravdepodobnom dátovom cut-offe.

LiveCodeBench navyše nehodnotí len generovanie programu. Obsahuje scenáre pre:

• self-repair chybného kódu;
• predpovedanie výstupu programu;
• prácu s execution feedbackom;
• klasické generovanie riešení.

To je metodicky dôležité. Model, ktorý vie napísať riešenie, nemusí vedieť nájsť konkrétnu chybu. Model, ktorý správne opraví známy bug, nemusí vedieť vymyslieť algoritmus od nuly. Jediné coding score tieto schopnosti zbytočne zlieva.

2025: Gemini Deep Think priniesol multiagentný tím k ICPC

Finále ICPC je iný typ tlaku. Tím má päť hodín, jediný prijatý submit znamená bod a každý neúspešný pokus pridáva časovú penalizáciu. Nestačí mať correct@1000. Potrebujete rýchlo nájsť správny algoritmus, implementovať ho a vedieť, kedy ho odoslať.

Pokročilá verzia Gemini 2.5 Deep Think riešila ICPC World Finals 2025 vzdialene pod dohľadom organizátorov. Začala o desať minút neskôr ako ľudia, mala rovnaký päťhodinový limit a vyriešila 10 z 12 úloh. Osem úloh zvládla počas prvých 45 minút, ďalšie dve do troch hodín. S kombinovaným penalizačným časom 677 minút by pri porovnaní s oficiálnou tabuľkou skončila druhá zo 139 tímov.

DeepMind popísal niekoľko kľúčových súčastí:

• multi-step reasoning;
• paralelné myslenie;
• niekoľko Gemini agentov s vlastnými návrhmi;
• prístup k terminálu;
• spúšťanie kódu a testov;
• iteráciu podľa výsledkov všetkých pokusov;
• reinforcement learning na veľmi ťažkých programátorských úlohách.

Zverejnené boli tiež finálne programy Gemini pre ICPC 2025. Úplnú architektúru, počty vzoriek a všetky interné prompty ale reprodukovať nemožno. Ide o dôležitý súťažný míľnik, nie o otvorený recept v kvalite NuminaMath.

PRIELOM 5: 10 Z 12 ÚLOH V PÄTI HODINÁCH

Parallel agents + terminals + iteration: agenti nenapísali iba niekoľko nezávislých programov. Videli výsledky exekúcie, opravovali sa a využívali predchádzajúce pokusy ako spoločnú experimentálnu pamäť.

Problem C: riešenie, ktoré nenašiel žiadny univerzitný tím

Gemini za približne pol hodiny vyriešil Problem C, ktorý neprijal žiadny ľudský tím. Úloha požadovala optimálnu distribúciu kvapaliny sieťou kanálov a zásobníkov s nekonečne mnohými možnými nastaveniami.

Podľa zverejneného popisu Gemini zaviedol pre zásobníky prioritné hodnoty. Pre pevne zvolené priority šlo najlepšie nastavenie kanálov nájsť dynamickým programovaním. Potom pomocou minimaxového argumentu previedol pôvodnú úlohu na hľadanie priorít, ktoré vytvárajú najtesnejšie obmedzenia. V konvexnom priestore použil vnorené ternárne vyhľadávanie.

Tento príklad je dôležitý, pretože to nie je iba bezchybná implementácia známej šablóny. Úspech vyžadoval niekoľko reprezentácií rovnaké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áve schopnosť zmeniť reprezentáciu oddeľuje silného implementátora od algoritmického objavovania.

2025 a 2026: triezve dáta proti príliš rýchlemu víťazstvu

Správy o medailových systémoch môžu vytvoriť dojem, že súťažné programovanie je vyriešené. Otvorenejšie benchmarky ukazujú zložitejší obraz.

LiveCodeBench Pro: nula percent na hard bez nástrojov

LiveCodeBench Pro zostavili spolu s výskumníkmi aj medailisti medzinárodných algoritmických olympiád. Úlohy z Codeforces, ICPC a IOI priebežne aktualizovali, anotovali ich podľa algoritmických kategórií a riadok po riadku analyzovali chybné riešenia modelov.

Bez externých nástrojov dosiahol najlepšie hodnotený model 53% pass@1 na stredne ťažkých úlohách a 0% na hard. Autori zistili, že modely sú silnejšie v implementačne náročných problémoch ako v jemnom algoritmickom uvažovaní a zložitej analýze prípadov. Často vytvárali sebavedomé, ale nesprávne zdôvodnenie.

To neodporuje výsledku Gemini. Ukazuje to rozdiel medzi samostatným modelom bez nástrojov a drahou uzavretou multiagentnou architektúrou s terminálmi, exekúciou a iteráciou.

LiveOIBench: offline olympiády s ľudským porovnaním

LiveOIBench, ktorého tretia verzia vyšla 8. júla 2026, obsahuje 403 odborne vybrané úlohy zo 72 súťaží v 14 informatických olympiádach z rokov 2023 až 2025. Každá úloha má v priemere okolo 60 oficiálnych test cases a detailnú subta. Celé hodnotenie je možné spustiť offline.

Z 34 hodnotených modelov dosiahol GPT-5 81,76. percentilu, stále pod najlepšími ľudskými súťažiacimi. Open-weight gpt-oss-120b dosiahol približne 60. percentil. Analýza reasoning traces navyše naznačila, že robustnejšie modely preferujú presnú analýzu zadania pred nadmerným chaotickým prehľadávaním.

PRIELOM 6: BENCHMARK UŽ NEMERÍ LEN ACCEPTED / WRONG ANSWER

Fresh problems + subtasks + human percentiles: nová generácia benchmarkov sleduje dátum úlohy, čiastkové body, test coverage a priame porovnanie s elitnými ľuďmi. Vysoký pass@k na malej statickej sade už nestačí.

Čo v histórii skutočne vyhrávalo

1. Diverzita algoritmov, nie len slov

Zmena teploty často vytvorí iný štýl rovnakého algoritmu. Skutočná diverzita znamená inú dátovú štruktúru, invariant, asymptotiku alebo rozklad problému. AlphaCode 2 ju podporoval niekoľkými fine-tuned policies a menenými metadátami.

2. Tvrdé filtre pred drahým sudcom

Kompilácia, verejné testy, limity, sanitizéry a statická kontrola sú lacnejšie a spoľahlivejšie ako LLM judge. AlphaCode 2 tak odstránil približne 95 % kandidátov ešte pred finálnou selekciou.

3. Behaviorálna deduplikácia

Textovo odlišný kód môže byť funkčne totožný. Zhlukovanie podľa výstupov na diagnostických vstupoch chráni submission budget pred desiatimi kópiami rovnakej chyby.

4. Aktívne generované protipríklady

Najlepší test rozlišuje dvoch silných kandidátov. Generátor testov má maximalizovať informačný zisk, nie počet náhodných vstupov.

5. Learned scorer ako posledná vrstva, nie jediná pravda

Scorer je užitočný tam, kde exekúcia nerozhodla. Nemá prepisovať fakt, že program spadol, porušil limit alebo neprešiel známym testom.

6. Cielená oprava

Keď poznáme failing input, opravujeme konkrétny invariant alebo riadok. Voľná ​​syntéza dvoch programov môže zničiť časti, ktoré už boli správne.

7. Test-time compute s rozpočtom

Sto kandidátov bez selektora je oracle experiment. Reálna architektúra musí optimalizovať očakávaný počet bodov na GPU-sekundu, kompiláciu a povolený submit.

8. Oddelenie profesií

Plánovač, implementátor, generátor testov, kritik a selektor majú iné ciele. Jeden model môže role striedať, ale protokol musí zabrániť tomu, aby autor iba potvrdil vlastné riešenie.

Čo naopak opakovane nefungovalo

1. Sto takmer totožných implementácií

Zvyšujú pass@k menej, než naznačuje počet vzoriek. Korelovaná chyba prežije hlasovanie aj reranking.

2. Optimalizácia iba na verejné ukážky

Ukážkový test vysvetľuje formát, nie plnú špecifikáciu. Model sa ľahko naučí patch pre tri príklady a minie všeobecný algoritmus.

3. „Kód vyzerá správne“ ako hlavná metrika

Jazykový sudca často preferuje čisté názvy, komentáre a presvedčivé vysvetlenie. Skrytý checker sa o štýl nezaujíma.

4. Random submit

Experiment o1-IOI nameral takmer 60-bodový rozdiel medzi náhodným a inteligentným výberom rovnakej populácie.

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

Výzva „skontroluj sa“ často vytvorí dlhšiu racionalizáciu. Oprava má dostať nový test, traceback, counterexample alebo konflikt s iným kandidátom.

6. Zmiešanie oracle@k s nasaditeľným výkonom

Desaťtisíc submitov nad hranicou zlata neznamená zlatú medailu pod limitom päťdesiatich pokusov. Oracle je diagnostika potenciálu generátora.

7. Benchmark bez časovej provencie

Pri verejnom probléme potrebujeme dátum zverejnenia, dátum modelového cut-offu, dostupnosť riešenia a hash konkrétnej verzie datasetu.

Ako by som z toho postavil HyperFusion Code

História ukazuje architektúru, ktorá nie je prostým majority vote. Je to riadený experimentálny cyklus.

Pôvodné úvodné ilustrácie tu dostáva presnejšiu úlohu: znázorňuje fúziu viacerých nezávislých prúdov uvažovania, nie samotné programovanie.

Fáza 1: odtlačok problému

Router najprv odhadne:

• algoritmickú oblasť;
• očakávanú zložitosť;
• potrebu matematického dôkazu;
• rizikové hraničné prípady;
• či je vhodnejší C++, Python alebo iný jazyk;
• koľko inferencie budgetu úloha zaslúži.

Router nemá rovno riešiť. Má vytvoriť experimentálny plán.

Fáza 2: slepá súťaž algoritmických návrhov

Tri až päť rôznych lokálnych modelov vytvoria iba návrh algoritmu, invariant a odhad zložitosti. Nevidí návrhy ostatných. Tým sa zabráni predčasnej konvergencii na prvú sebavedomú myšlienku.

Návrhy sa zoskupia podľa skutočného princípu:

• greedy;
• dynamické programovanie;
• grafová transformácia;
• tok alebo matching;
• matematická konštrukcia;
• search s pruningom;
• randomizovaný alebo numerický postup.

Do ďalšej fázy postupujú najviac dvaja reprezentanti každej rodiny.

Fáza 3: viac implementácií silných plánov

Každý preživší plán implementujú najmenej dva modely. Tým oddelíme chybu algoritmu od chyby zápisu. Pokiaľ dve nezávislé implementácie rovnakého plánu dávajú iné výsledky, získavame veľmi cenný diagnostický konflikt.

Fáza 4: test forge

Samostatný agent vytvára:

• minimálne prípady;
• nulu a prázdny vstup, ak sú povolené;
• duplicity a zhodné hodnoty;
• maximálna veľkosť;
• hodnoty pri hraniciach dátových typov;
• prípady porušujúce greedy intuíciu;
• vstupy, na ktorých sa kandidáti líšia;
• metamorfná transformácia so známou reláciou výstupov.

Pokiaľ poznáme pomalý referenčný algoritmus pre malýchn, používame differential testing. Pre malé prípady vyčerpávajúcim spôsobom porovnáme rýchlych kandidátov s brute force.

Fáza 5: cielená oprava

Kandidát dostane iba:

• pôvodný plán;
• vlastný kód;
• konkrétny failing input;
• očakávaný a skutočný výstup;
• prípadne diagnostiku sanitizéra alebo limitu.

Úlohou nie je „napíš lepšie riešenie“, ale „nájdi minimálnu príčinu tohto zlyhania a opráv ju bez zmeny ostatných invariantov“.

Fáza 6: turnajový selektor

Poradie kandidátov 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étne váhy musia byť zamknuté na validačnej sade. Testovacia sada slúži iba k jednorazovému reportu.

Fáza 7: auditovateľný submit

Systém uloží:

• všetky algoritmické návrhy;
• zdrojový model a seed;
• programy a ich hasha;
• kompilátor a flags;
• všetky generované testy;
• výsledky exekúcie;
• opravy a ich dôvody;
• finálne skóre selektora;
• skutočný výsledok skrytého checkera.

Bez tejto stopy nemožno zistiť, či zlepšenie priniesol model, generátor testov, repair loop alebo iba väčší počet pokusov.

Pôvodný návrh experimentu pre LUMI

Pôvodne som navrhol experiment Exp05: Behavioral Code Fusion bez drahého judge modelu, iba s lokálnymi riešiteľmi, kompilátorom, sanitizérmi, brute-force referenciami a behaviorálnou zhodou. Nasledujúca časť zachováva plán; hneď za ňou sú výsledky skutočného behu.

Dataset

1. trénovacia sada pre nastavenie pravidiel a váh;
2. validačná sada pre voľbu budgetu a stopping rule;
3. uzamknutá testovacia sada podľa dátumu zverejnenia;
4. dodatočný čerstvý holdout z LiveCodeBench alebo LiveOIBench.

Rozdelenie musí byť podľa problémov a ich pôvodu, nie podľa jednotlivých programov. Inak by dve takmer rovnaké varianty úlohy mohli skončiť na oboch stranách splitu.

Kandidátna konfigurácia

Pre 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ámerne menší budget ako milión vzoriek AlphaCode. Cieľom je zmerať, koľko výkonu vytvorí diverzita modelov a execution feedback pri lokálne realistickej cene.

Ablácia

Táto postupnosť presne ukáže medznú hodnotu každej vrstvy. Keď variant E nepridá výkon, generátor testov nevytvára informatívne vstupy. Keď G nepridá nič nad F, drahý scorer nie je potrebný.

Metriky

Nestačí jedno percento:

• pass@1 najsilnejšieho modelu;
• oracle@18;
• selected@1;
• selected@3;
• priemerné body zo subtasks;
• oracle gap a selector recovery rate;
• počet behaviorálnych klastrov;
• pairwise error correlation medzi modelmi;
• počet kompilácií a spustení;
• GPU-sekundy, CPU-sekundy a energie;
• čas do prvého accepted riešenie;
• koľko opráv odstránilo pôvodný bug a koľko vytvorilo nový.

Kľúčová metrika selektora môže byť:

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

Hovorí, akú časť dostupného oracle gapu dokázala architektúra skutočne získať bez prístupu k skrytému riešeniu.

Čo by bolo skutočným výsledkom výskumu

Najcennejším výstupom by nebolo tvrdenie „tri modely sú lepšie ako jeden“. To sa dá očakávať už z pass@k. Výskumne zaujímavé sú tieto otázky:

1. Má diverzita modelových rodín väčšiu hodnotu ako rovnaký počet vzoriek najlepšieho modelu?
2. Dokáže behaviorálny clustering predpovedať korelovanú chybu?
3. Ktorý typ automatického testu najviac zvyšuje selector recovery?
4. Kedy oprava pomáha a kedy poškodí správny základ?
5. Je možné neistotu odhadnúť z nezhody kandidátov lepšie ako z vlastného confidencie modelu?
6. Ako sa optimálna architektúra mení s pamäťovým a časovým rozpočtom?
7. Potrebujeme veľkého sudcu, alebo väčšinu sporov rozhodne exekúcia?

Od návrhu k dátam: experiment som skutočne spustil na LUMI

Na fínskom superpočítači LUMI som postavil lokálny panel open-weight modelov a bezpečný execution sandbox. Použil som stratifikovanú vzorku 40 úloh LiveCodeBench zverejnených od marca 2025: 13 easy, 14 medium a 13 hard, z toho 26 z AtCoderu a 14 z LeetCode. Lokálne bežali gpt-oss-120b, Qwen2.5-72B, GLM-4.7-flash a Mistral-Small-3.2-24B; Kimi K2.7-code a Kimi K3 cez API slúžili iba ako referenčný strop.

Tvrdý signál musí kandidátov rozlišovať

Samotné spustenie kódu nestačilo. Kandidáti, ktorí prešli verejnými testami, na nich vracali rovnaké výstupy, takže selektor zostal slepý; približne pri jednej pätine úloh takýto kandidát neskôr zlyhal na skrytom teste. V kontrolovanom pilote som hodnotu rozlišovacej vrstvy meral čistým rozdelením testov na selekčnú a nezávislú skórovaciu časť. V produkcii túto úlohu musia prevziať generované protipríklady a differential testing.

Najdôležitejší výsledok z LUMI: najcennejším artefaktom nemusí byť ďalší program, ale test, ktorý oddelí správne riešenie od programu úspešného iba na verejných príkladoch.

Spoločný oracle zostal na 35/40 a rovnakých 35 úloh zvládol jeden najsilnejší coder sám. Receptom preto nebol čo najpestrejší panel, ale jeden silný model × viac vzoriek × rozlišovacia testová selekcia.

Päť najťažších úloh, štyri orchestrace

Iba s lokálnym gpt-oss-120b sa podarilo prelomiť 2 z 5 úloh, ktoré základný panel nevyriešil. Jedna padla len v režime proof-pilot, hoci tri ostatné režimy skončili na nule. Nástroje nevolal samotný model (tool_calls = 0); exekúciu a konkrétnu spätnú väzbu riadil harness.

Kimi K3 zároveň ukázal metodickú pascu: pri limite 12 000 tokenov dosiahol iba 17/40, pretože 35 % odpovedí skončilo uprostred uvažovania. Po zvýšení limitu na 32 000 tokenov vyskočil na 31/40. Bez kontrolného behu by chyba harnessu vyzerala ako slabosť modelu.

Rýchlosť inferencie ako nová dimenzia AI aplikácií

V kurze Fast LLM Inference with Cerebras som vyskúšal opačný extrém: čo sa zmení, keď čakanie na veľký model takmer zmizne. Katalóg Cerebras uvádza pre gpt-oss-120b približne 3 000 výstupných tokenov za sekundu. Je to údaj poskytovateľa; moje konkrétne merania boli:

Podobné zadanie biliardu trvalo v jednom behu GPT-4.1 mini približne 39 sekúnd. Nie je to čistý hardvérový benchmark, pretože sa líšili modely aj infraštruktúra. Je to však názorný rozdiel v používateľskom zážitku.

Dve sekundy k prvému hrateľnému prototypu

Prvý Tetris bol skutočne hrateľný: padajúce tetrominá, posun, rotácia, zrýchlený pád, mazanie riadkov a skóre. Neznamená to hotový produkt za dve sekundy, ale funkčný základ pripravený na okamžité testovanie a opravy.

Šach bol hrubší: vznikla šachovnica, ovládanie figúr, základná kontrola ťahov a jednoduchá odpoveď počítača. Nie je pravidlovo kompletný ani nenahrádza overený engine. Od prázdneho zadania k interaktívnej hre za približne dve sekundy je však pozoruhodný štart.

Nie iba rýchlejší chat

Pri stovkách až tisícoch tokenov za sekundu sa do jednej interakcie zmestí viac kandidátov, testy, opravy aj výber. Pre HyperAdvisor a HyperFusion z toho vychádzajú tri režimy:

Najlepšou metrikou preto nie je samotné tokens/s, ale: za aký čas a cenu systém vytvorí overený správny výsledok? Rýchlosť dodá viac pokusov; exekúcia a rozlišovacie testy dodajú dôvod veriť vybranému výsledku.

Paralelná vetva: súťažné programovanie nie je bežný softvér engineering

HumanEval, Codeforces, IOI a ICPC majú jasné zadanie, čistý vstup, očakávaný výstup a relatívne izolovaný program. Reálny repozitár je iný svet. Zadanie môže byť neúplné, testy zastarané a správna oprava môže vyžadovať pochopenie stoviek súborov.

Preto by som do hlavnej časovej osi nemiešal SWE-bench a agentov opravujúcich GitHub issues. Zaslúži si samostatný článok. Princípy sú príbuzné, ale rola testov je iná: v súťaži testy definujú pravdu, v reálnom vývoji môžu byť samy súčasťou problému.

Čo si odniesť

História súťažného programovania AI nie je jednoduchý príbeh stále väčších modelov. Je to história stále lepšia organizácia pokusov:

1. HumanEval odhalil obrovský rozdiel medzi pass@1 a pass@100.
2. AlphaCode premenil generovanie v populačnej search.
3. AlphaCode 2 spojil rôzne policy modely, execution, behaviorálny clustering a learned scorer.
4. o1-IOI zmeral, že selekcia rovnakej populácie mala hodnotu približne 57 bodov.
5. LiveCodeBench pridal čerstvé dáta a viac schopností ako samotné generovanie.
6. Gemini na ICPC použil paralelné agentov, terminály a iteratívnu opravu.
7. LiveCodeBench Pro a LiveOIBench ukázali, že elitné algoritmické uvažovanie stále nie je vyriešené.
8. Môj experiment na LUMI získal rozlišovacími testami 80–83 % dostupného oracle gapu.
9. Štyri orchestrace rovnakého lokálneho modelu prelomili dve z piatich najťažších úloh.
10. Cerebras ukázal druhú os: do jednej interakcie sa môže zmestiť generovanie, kontrola aj oprava.

Konečný princíp: najchytrejší programátorský systém nie je ten, ktorý najdlhšie premýšľa v jednom monológe. Je to systém, ktorý vie vytvárať nezávislé hypotézy, navrhovať experimenty, zbierať tvrdé dôkazy, opravovať konkrétne chyby a hospodáriť s obmedzeným rozpočtom submitov.

Práve programovanie môže byť pre HyperFusion ideálnym laboratóriom. Máme tu niečo, čo pri otvorených humanitných otázkach často chýba: lacnú spätnú väzbu z reality. Keď ju dobre využijeme, nepotrebujeme, aby jeden model bol dokonalý. Potrebujeme, aby sa celý systém vedel učiť z každého neúspešného behu.

Primárne zdroje a reprodukčné materiály

• DeepCoder: Learning to Write Programs
• Evaluating Large Language Modely 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, časť o IOI a Codeforces
• LiveCodeBench
• LiveCodeBench repository a hodnotenie harness
• LiveCodeBench Pro
• LiveOIBench
• Gemini 2.5 Deep Think na ICPC World Finals 2025
• Zverejnené programy Gemini z ICPC 2025
• Pôvodný príspevok Andreja Karpathyho k pojmu vibe coding
• Collins Word of the Year 2025: vibe coding
• Stack Overflow Developer Survey 2025: AI a vibe coding
• METR: meranie produktivity skúsených open-source vývojárov s AI
• Fast LLM Inference with Cerebras, kurz DeepLearning.AI
• Katalóg Cerebras Inference a uvádzaná rýchlosť gpt-oss-120b
• Cerebras Cloud