Jak AI nauczyła się programować: Od HumanEval do złotego medalu ICPC

Programowanie ma jedną wielką przewagę nad rozumowaniem matematycznym: odpowiedź możemy uruchomić. Program albo się kompiluje, albo nie. Dla konkretnego wejścia zwraca konkretny wynik. Możemy zmierzyć czas i pamięć oraz porównać rezultat z ukrytym checkerem. W naszym niedawnym artykule o drodze AI od GSM8K do agentów dowodzących pokazaliśmy, jak systemy matematyczne nauczyły się tworzyć wiele podejść, głosować i weryfikować dowody. Ten artykuł rozwija tę samą historię w środowisku, w którym rezultat można nie tylko ocenić, lecz także naprawdę uruchomić.

Prowadzi to do poglądu, że programowanie konkurencyjne jest dla sztucznej inteligencji łatwiejsze niż matematyka. W rzeczywistości jest to trudniejsze i czystsze laboratorium. Model musi wyprowadzić ukryty algorytm z długich danych wejściowych, udowodnić jego poprawność, przełożyć go na doskonały program i przetrwać dane wejściowe, których nigdy nie widział. Jedyny pominięty warunek brzegowy oznacza zero.

Dlatego w ciągu pięciu lat zmieniła się nie tylko wydajność modeli, ale cały sposób, w jaki pozwalamy programować sztuczną inteligencję. W 2021 roku pytaliśmy, czy któryś model wykona krótką funkcję za pierwszym razem. Do 2025 r. wielu agentów projektowało już algorytmy równolegle, uruchamiało kompilator i testy, dzieliło się znalezionymi błędami i pracowało nad rozwiązaniem na poziomie złotego medalu ICPC.

Ten tekst jest techniczną historią tej transformacji. Nie chodzi tylko o to, który model zdobył ile punktów, ale przede wszystkim o to, który algorytm wnioskowania, selekcji i weryfikacji dał taki wynik. To właśnie te zasady można przenieść do HyperFusion i eksperymentów w LUMI.

Główny wniosek: największego skoku nie dokonał model, który napisał jeszcze jeden doskonały program. Było to spowodowane systemami, które tworzyły populację różnych algorytmów, tanio usuwały oczywiste błędy, szukały kontrprzykładów, naprawiały tylko sprawdzone błędy i inteligentnie decydowały, które programy w ogóle warto wysyłać.

Od szeptania po kodowanie wibracyjne

Termin kodowanie wibracji został wprowadzony przez Andreja Karpathy’ego 2 lutego 2025 r. na określenie sposobu pracy, w którym osoba opisuje intencje w języku naturalnym, akceptuje duże zmiany stworzone przez sztuczną inteligencję i stopniowo kieruje systemem, niekoniecznie czytając każdą linijkę. W ciągu kilku miesięcy slang techniczny stał się terminem kulturowym, a Collins wybrał go jako Słowo Roku 2025.

NOTA WYJAŚNIAJĄCA: CO TO JEST KODOWANIE VIBE

W czystej postaci nie jest to tylko autouzupełnianie czy okazjonalne porady chatbota. Programista przenosi uwagę ze składni na intencje, zachowanie aplikacji i inne instrukcje dotyczące modelu. Kod można tworzyć w dużych blokach, a autor nie musi go szczegółowo rozumieć. Jest to świetne rozwiązanie w przypadku prototypu, ale niebezpieczne wszędzie tam, gdzie brakuje testów, przeglądu bezpieczeństwa i kogoś, kto rozumie powstały system.

Ważne jest, aby nie mylić szybkiego rozwoju narzędzi AI z czystym kodowaniem wibracyjnym. Ankieta Stack Overflow Developer Survey 2025 podaje, że 84% respondentów używa lub planuje używać narzędzi AI, w porównaniu z 76% rok wcześniej, a 51% profesjonalnych programistów korzysta z nich codziennie. Jednocześnie jednak 72% respondentów stwierdziło, że vibe kodowanie nie jest częścią ich pracy zawodowej. Pomoc AI stała się powszechna, a nie automatycznie chęć zaprzestania sprawdzania kodu.

Bardziej trzeźwą korektę dodał eksperyment METR z pierwszej połowy 2025. Szesnastu doświadczonych programistów open source rozwiązało 246 zadań we własnych repozytoriach, a ich praca trwała średnio o 19% dłużej przy użyciu ówczesnych narzędzi AI. To wąska migawka w czasie, a nie uniwersalny werdykt w sprawie programowania AI. Przypomina jednak, że szybka rozbudowa narzędzia sama w sobie nie świadczy o wyższej produktywności.

Programowanie konkurencyjne jest zatem interesującym kontrapunktem dla kodowania wibracyjnego. Kod możemy wygenerować bardzo dowolnie, ale ostatecznie musi on przejść precyzyjny tester. Wartością badawczą nie jest sama szybkość pisania, ale umiejętność przekształcenia niejasnego strumienia sugestii w zweryfikowany program.

Najpierw zasady: Codeforces, IOI i ICPC to nie ta sama dyscyplina

Liczba taka jak „85. percentyl w programowaniu” brzmi bardziej jednoznacznie, niż jest w rzeczywistości. Codeforces, Międzynarodowa Olimpiada Informatyczna i testy ICPC związane, ale różne umiejętności.

Ponadto metryki mierzą różne rzeczy:

Dlatego w artykule nie będę rysował ani jednej fałszywie gładkiej krzywej „ogólnej inteligencji programistycznej”. Dla każdego punktu na osi czasu podaję platformę, liczbę prób, narzędzia i sposób konwersji na ranking ludzki.

Oś czasu równoważna dla człowieka

Pierwsze systemy nie miały jeszcze wiarygodnego percentyla ludzkiego. DeepCoder w 2017 roku przyspieszył wyszukiwanie enumeracyjne krótkich programów o około rząd wielkości, ale działał w ograniczonym DSL i rozwiązywał jedynie problemy o trudności podobnej do najprostszych prac konkursowych. Codex osiągnął 28,8% pass@1 w HumanEval w 2021 r., ale HumanEval nie ma tabeli liderów składającej się z ludzkich konkurentów. Dlatego te kamienie milowe należą do osi, a nie do skali percentylowej.

Od 2022 r. mamy już kilka bezpośrednich, choć wciąż nie do końca wymiennych, porównań z ludźmi. Na wykresie umieściłem jedynie układ graniczny danego czasu i jego publicznie udokumentowany wynik:

• AlphaCode, Codeforces 2022: uzyskało wyniki lepsze od około 45,7% konkurentów, osiągając wyniki w okolicach mediany.
• AlphaCode 2, Codeforces 2023: przeszło średnio 85% uczestników. Jednak w dwóch najlepszych konkursach uzyskał lepsze wyniki niż ponad 99,5% uczestników. To właśnie ta rozbieżność pokazuje, dlaczego sama średnia skrywa ważną część historii.
• o1, Codeforces 2024: ogólne o1 osiągnęło 89. percentyl. Wariant dalej szkolony pod kątem IOI osiągnął Elo 1807 i 93. percentyl.
• o1-IOI, IOI 2024: Poniżej faktycznego limitu 50 zgłoszeń na zadanie zdobył 213 punktów i znalazł się na 49. percentylu elitarnych olimpijczyków szkół średnich.
• GPT-5, LiveOIBench 2025: uzyskał 81,76. percentyl w 403 zadaniach z olimpiad z lat 2023-2025. Autorzy zwracają uwagę, że najlepsi ludzie w tym zestawie zwykle znajdują się powyżej 90. percentyla.
• Gemini 2.5 Deep Think, ICPC 2025: dziesięć rozwiązanych problemów oznaczałoby drugie miejsce na 139 drużyn, lepsze niż około 98,6% rankingów. Jest to hipotetyczne przeliczenie, ponieważ Gemini nie była oficjalnie sklasyfikowaną drużyną uniwersytecką.

Łączę tylko linię między wynikami z tej samej rodziny Codeforces. IOI, ICPC i LiveOIBench pozostają odrębnymi punktami, ponieważ ich populacje i zasady są różne. Linia pionowa w AlphaCode 2 nie jest przedziałem ufności, ale różnicą pomiędzy średnią a dwoma najlepszymi konkursami. Zatem wykres pokazuje jednocześnie dwie prawdy: systemy graniczne w niektórych konkursach osiągnęły niemal 99 percentyl, podczas gdy w innej elitarnej dyscyplinie w tym samym roku utrzymywały się w okolicach mediany.

2021: HumanEval wykazało, że umiejętności to dystrybucja, a nie pojedyncza próba

W pracy Evaluating Large Language Models Trained on Code wprowadzono Codex, a wraz z nim HumanEval, 164 odręcznie napisane zadania programistyczne. Model otrzymał sygnaturę funkcji, dokumentację i kilka testów jednostkowych ukrytych przed generacją.

Codex rozwiązał 28,8% zadań za pierwszym razem. Kiedy jednak autorzy wygenerowali 100 programów na podstawie tego samego modelu, dla 70,2% problemów pojawiło się co najmniej jedno prawidłowe rozwiązanie.

Jest to jedna z najważniejszych różnic liczbowych w całej historii:

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

Zatem model często był w stanie wygenerować prawidłowe rozwiązanie, ale w jednej próbie nie udało się go wiarygodnie wyodrębnić. Dało to podstawę do dwóch odrębnych pytań badawczych:

1. jak usprawnić dystrybucję kandydatów;
2. jak rozpoznać właściwy program wśród stu podobnie przekonujących propozycji bez znajomości ukrytych testów.

PRZEŁOM 1: 28,8% ZMIENIONO NA 70,2%

Powtarzanie prób: wielokrotne zadawanie tej samej modelce tego samego zadania. Właściwy program pojawiał się znacznie częściej niż wskazywał pass@1. Pojawił się jednak problem selekcji: wyrocznia wie, który kandydat przejdzie ukryte testy, prawdziwy system tego nie wie.

APLIKACJE: zadaniem programisty nie było już tylko dodanie funkcji

W tym samym roku test porównawczy APPS przyniósł 10 000 problemów, od prostych zadań po konkurencyjne wyzwania algorytmiczne. Wprowadzanie danych odbywało się w języku naturalnym, a poprawność sprawdzano na podstawie przypadków testowych. W tamtym czasie GPT-Neo poradził sobie z około 20% indywidualnych testów dotyczących początkowych problemów, a nie 20% w pełni rozwiązanych, ciężkich zadań.

W aplikacji APPS wprowadzono ważne rozróżnienie, które czasami do dziś jest zatracane: procent pozytywnie zaliczonych przypadków testowych nie jest taki sam, jak odsetek w pełni rozwiązanych problemów. Program, który przejdzie dziewięć testów na dziesięć, może mieć praktycznie użyteczną podstawę. Ale w konkursie sprawdzania binarnego nadal dostaje zero.

2022: AlphaCode zmieniło generowanie kodu na wyszukiwanie populacji

AlphaCode był pierwszym systemem, który osiągnął mniej więcej średni poziom uczestników w nowych konkursach Codeforces. W ocenie wykorzystano dziesięć zawodów nowszych niż dane treningowe. Nie było to krótkie dodanie funkcji, ale długie zadanie wymagające kombinatoryki, wykresów, programowania dynamicznego i precyzyjnej analizy złożoności.

Architektura była ważniejsza niż pojedynczy punkt kontrolny:

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

AlphaCode wstępnie przeszkolił transformatory w zakresie kodu publicznego z GitHub i przeszkolił ich w zakresie zadań i rozwiązań konkurencyjnych. Podczas wnioskowania wygenerowano o rząd wielkości więcej programów niż poprzednie prace. Następnie przefiltrował, pogrupował i zredukował je do dziesięciu prób.

W symulacji zajmował średnio 54,3% najlepszych miejsc w tabeli liderów. Często jest to błędnie zapisywane jako 54. percentyl. To słusznie oznacza, że ​​około 45,7% uczestników miało gorszy wynik.

PRZEŁOM 2: MILIONY PROGRAMÓW, DZIESIĘĆ ZGŁOSZEŃ

Przeszukiwanie populacji: model nie był uczestnikiem, który napisał jedno rozwiązanie. Był generatorem populacji. Odrębna warstwa kompilacji, testowania, deduplikacji i selekcji decydowała o tym, którzy członkowie populacji otrzymają rzadką okazję do wysłania.

CodeContests: zbiór danych zawierał również błędne rozwiązania opracowane przez człowieka

Firma DeepMind udostępniła zbiór danych i narzędzia wykonawcze CodeContests. Dane obejmują zadania z Codeforces, AtCoder, CodeChef i innych źródeł, dane wejściowe i wyjściowe testów, a także prawidłowe i nieprawidłowe rozwiązania ludzkie.

Zły kod jest zaskakująco cenny dla szkolenia. Pozwala nauczyć się nie tylko „jak wygląda poprawne rozwiązanie”, ale także „jakie drobne zmiany sprawiają, że otrzymany program staje się programem prawie poprawnym”. Dla przyszłego modelu krytyki i naprawy ta granica jest bardziej użyteczna niż kolejny tysiąc doskonałych szablonów.

Tajna broń AlphaCode: grupowanie według zachowania, a nie tekstu

Dwa programy mogą wyglądać zupełnie inaczej, a mimo to implementować ten sam algorytm. I odwrotnie, dwie prawie identyczne implementacje mogą różnić się jednym znakiem i mieć różne zachowanie na granicy zakresu.

Dlatego AlphaCode nie wywodził różnorodności wyłącznie z podobieństwa tekstowego. Wygenerował dodatkowe dane wejściowe, uruchomił na nich programy kandydujące i dla każdego programu stworzył sygnaturę jego wyników:

testy = generate_inputs(problem)

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

clusters = group_by_similar_signature(programs)

Jeśli dziesięć tysięcy programów zwraca to samo na wszystkich wejściach diagnostycznych, nie ma sensu wysyłać dziesięciu ich kosmetycznych wariantów. Lepiej wybrać jednego przedstawiciela, a pozostały budżet na złożenie wniosku przeznaczyć na inne hipotezy behawioralne.

Jest to programowy odpowiednik głosowania nad znormalizowaną odpowiedzią matematyczną, ale ze znacznie bogatszym sygnałem. Nie głosujemy tylko nad ostateczną liczbą. Porównujemy funkcje pod kątem ich zachowania na podstawie pełnego zestawu ukierunkowanych pytań.

Dlaczego największy klaster nie jest automatycznie prawdziwy

Większość behawioralna działa, jeśli prawidłowy algorytm tworzy szeroki zakres podobnych implementacji, a błędy są fragmentaryczne. Ale może się to nie udać, jeśli modele podzielają ten sam popularny błąd. Typowym przykładem jest rozwiązanie, które przechodzi wersję demonstracyjną, ale ignoruje przepełnienia, zduplikowane wartości lub najgorszy asymptotyczny przypadek.

Dlatego rozmiar klastra nie jest dowodem. To jest przed. Trudne testy, przeciwne wpisy i osoba oceniająca jakość muszą zdecydować, czy największą grupą jest mądry tłum, czy tłum z tym samym błędem.

2023: AlphaCode 2, milion kandydatów zawężonych do dziesięciu

Raport techniczny AlphaCode 2 oferuje niezwykle specyficzną recepturę. Podstawą była rodzina modeli wywodząca się z Gemini Pro, a nie pojedynczy generator. Modele przeszły dwie rundy dostrajania na zaktualizowanym zbiorze danych CodeContests i zestawie uzupełniającym wyższej jakości.

Zaktualizowany korpus zawierał około 15 000 problemów i 30 milionów programów ludzkich. Stworzono rodzinę modeli polityki z różnymi hiperparametrami. Różnorodność nie była zatem pozostawiona przypadkowej temperaturze, ale została wbudowana w rodzinę generatorów.

Dla każdego z 77 problemów z dwunastu nowych konkursów Codeforces system wykonał następujące czynności:

1. wygenerowano do 1 000 000 programów w C++;
2. losowo zmieniona temperatura i metadane w monicie;
3. równomiernie podzielić budżet pomiędzy kilka modeli polityki;
4. wypuścił kandydatów na publiczne przykłady;
5. usunięto niekompilujące się i oczywiście złe programy;
6. stworzył klastry behawioralne spośród około 50 000 ocalałych;
7. opuścił dziesięć największych skupisk;
8. wybrał najlepszego przedstawiciela każdego skupienia wraz z wyszkolonym strzelcem Gemini;
9. wysłał nie więcej niż dziesięć programów.

Publiczne testy i kompilacje eliminowały średnio około 95% kandydatów. Jest to ważna zasada ekonomiczna: drogiego uczonego sędziego nie należy marnować na kod, który nie przejdzie nawet pierwszego przykładu.

Rezultatem było 43% problemów rozwiązanych w ciągu dziesięciu prób w porównaniu z 25% oryginalnego AlphaCode. Szacunkowa pozycja zmieniła się z wyników lepszych niż około 46% uczestników do wyników lepszych niż 85% uczestników.

Jeszcze większe wrażenie robi wydajność. Około 100 próbek AlphaCode 2 wystarczyło, aby osiągnąć wydajność oryginalnego AlphaCode przy milionie próbek. Autorzy zgłaszają zatem ponad dziesięciotysięczną poprawę wydajności próbki na tym poziomie porównawczym.

PRZERWA 3: 25% ZMIENIONO NA 43%, A ŚREDNIA NA 85. PROCENTYL

Różne zasady + wykonanie + grupowanie + punktacja: silniejszy model nie wyeliminował potrzeby wyszukiwania. Zmienił gospodarkę. Sto nowych próbek mogło być warte milion starych, ale ostateczny wynik i tak zależał od twardego filtra i selekcji.

Jak wygenerować milion kandydatów: próbkowanie to nie to samo, co przeszukiwanie drzewa

Intuicyjne wyjaśnienie jest często takie, że system przeszukiwał drzewo rozwiązań. Ale historia jest bardziej subtelna.

DeepCoder w 2017 roku faktycznie korzystał z wyszukiwania klasycznego. Sieć neuronowa oszacowała na podstawie przykładów, jakie cechy języka z ograniczeniami będą potrzebne w programie, a wyszukiwanie w głąb, solwer wyliczeniowy lub solwer SMT kierował się tymi prawdopodobieństwami. W ten sposób model zredukował i uporządkował wyraźną przestrzeń kombinatoryczną krótkich programów.

Z drugiej strony AlphaCode i AlphaCode 2 nie wygenerowały miliona kandydatów przy użyciu jednego gigantycznego wyszukiwania drzewa Monte Carlo. Transformator generatywny wielokrotnie autoregresywnie próbkował cały program token po tokenie. Poszczególne wdrożenia można uruchamiać niezależnie i masowo równolegle. Różnorodność została stworzona przez różne modele polityki, języki, podpowiedzi, metadane i losowo wybraną temperaturę. Tylko ukończone programy przeszły kompilację, testy publiczne, grupowanie behawioralne i ocenę.

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í

Dlaczego w ogóle poszedł zarobić milion? Programy konkursowe są stosunkowo krótkie, samplowanie można łatwo grupować na akceleratorach, a rollouty nie muszą na siebie czekać. Milion kandydatów nie oznacza miliona dopuszczonych zgłoszeń. AlphaCode 2 zredukował milion surowych programów do około 50 000 ocalałych po pierwszych filtrach, następnie dziesięciu klastrach behawioralnych i wreszcie dziesięciu rzeczywistych przesłanych.

W przypadku o1-IOI znamy interfejs zewnętrzny, a nie cały, autorski mechanizm. OpenAI twierdzi, że system pobrał próbę z wieloma kandydatami, wybierając 50 na podstawie publicznych i wygenerowanych testów oraz wyuczonej osoby oceniającej, a w opublikowanym eksperymencie pozwolił na przesłanie 10 000 zgłoszeń na stanowisko. Ale raport publiczny nie twierdzi, że MCTS wbiegł do środka. Wiemy, że o1 poprawia się wraz z dłuższym czasem testowania i że może skorygować swój własny postęp. Dokładny kształt rozgałęzień wewnętrznych nie został opublikowany.

Ponadto dzisiejsze systemy agentów nie tworzą różnorodności poprzez samo niezależne pobieranie próbek. Typowa pętla to plan -> wdrożenie -> kompilacja -> test zakończony niepowodzeniem -> poprawka docelowa. Nowy kandydat pojawi się jako gałąź wywołana konkretnym dowodem błędu. Na takiej pętli można zbudować wyszukiwanie wiązki, DFS lub MCTS, ale nie stanowią one automatycznego wyjaśnienia każdego modelu rozumowania.

Najważniejsza tendencja ma charakter ekonomiczny: bardziej rygorystyczna polityka radykalnie zmniejsza liczbę potrzebnych ślepych próbek. AlphaCode 2 osiągnął przy około 100 próbkach wydajność, do osiągnięcia której oryginalny AlphaCode potrzebował miliona. Dlatego też rozsądniej jest, aby HyperFusion tworzył dziesiątki celowo różnych planów, mierzył ich zachowanie i rozgałęział się tylko wtedy, gdy test wykaże konflikt, niż bezmyślnie produkować milion kosmetycznych wariantów.

Kompilator jest nie tylko sędzią, jest także nauczycielem

Programowanie oferuje wskazówki, których często nie ma w tekście matematycznym:

• parser pokaże błąd składniowy;
• kompilator zwraca typ problemu i linię;
• środowisko wykonawcze wykrywa wyjątek lub przepełnienie;
• profiler pokaże złożoność czasu lub pamięci;
• checker zwraca konkretne wejście, na którym rozwiązanie się nie powiodło;
• Testy różnicowe wykażą, gdzie kandydaci się różnią.

Nie wszystkie sygnały są równie cenne. Błąd kompilacji często bezpośrednio wskazuje na lokalną poprawkę. „Zła odpowiedź w ukrytym teście 37” nie mówi prawie nic. Dlatego najlepsze architektury nie postrzegają informacji zwrotnej o wykonaniu jako pojedynczego komunikatu, ale jako stopniowe udoskonalanie diagnozy.

Generowanie testu jako aktywny eksperyment

Najbardziej użytecznym testem nie jest losowe wprowadzanie danych. Jest to sygnał wejściowy, przy którym dwa prawdopodobne rozwiązania nie są zgodne. Ma dużą wartość informacyjną, ponieważ dzieli hipotezy.

Wyobraźmy sobie trzech kandydatów:

• I używa zachłannego algorytmu;
• B programowanie dynamiczne;
• C ta sama zachłanna procedura, ale naprawia duplikaty.

Losowy test może dać takie same wyniki dla każdego. Generator aktywny ma wyszukiwać mały przypadek z duplikacją, przypadek z zerem, maksymalny zakres i konstrukcję, w której zachłanność narusza globalne minimum. Tylko wtedy testowanie staje się eksperymentem naukowym, a nie loterią.

2024: o1-IOI dokładnie zmierzył wartość selektora

OpenAI oceniło wyspecjalizowany model wywodzący się z o1 podczas Międzynarodowej Olimpiady Informatycznej 2024. Według oficjalnego opisu system miał dziesięć godzin na sześć problemów i maksymalnie 50 zgłoszeń na każdy problem.

Dla każdego problemu wygenerował wielu kandydatów. Spośród pięćdziesięciu nadesłanych rozwiązań dokonał selekcji według trzech sygnałów:

1. wyniki w publicznych testach IOI;
2. wydajność testów generowanych przez model;
3. poznane funkcje scoringowe.

Wynik wyniósł 213 punktów i 49. percentyl konkurentów. Jednocześnie OpenAI oszacowało, że losowo wybrani kandydaci uzyskają średnio jedynie 156 punktów.

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

Jest to najczystsza dostępna ablacja wartości architektury kognitywnej. Odpowiednie programy były już w populacji. Prawie 60 punktów nie powstało dzięki dodatkowemu przeszkoleniu, ale możliwości zainwestowania limitowanych 50 zgłoszeń w lepszych kandydatów.

Kiedy limit został sztucznie obniżony do 10 000 zgłoszeń na zadanie, system uzyskał 362,14 punktów, czyli powyżej progu złotego medalu, nawet bez wyboru czasu testu. Wynik ten jest cenny jako eksperyment wyroczni, ale nie jest to uczciwy wynik konkurencyjny. Pokazuje górną granicę generatora przy niemal nieograniczonej liczbie prób, a nie możliwość pracy według zasad IOI.

PRZEŁOM 4: +57 PUNKTÓW BEZ ZMIANY GENERATORA

Testy publiczne + wygenerowane testy + zdobyta wiedza: selekcjoner zdecydował, które z wielu rozwiązań pochłonie ograniczony budżet zgłoszeń. Losowy wybór pozostawił znaczną część możliwości modelu niewykorzystaną.

Ocena Codeforces: ta sama rodzina, inny pogląd

OpenAI symulowało także konkursy Codeforces, w których dozwolone było dziesięć zgłoszeń. GPT-4o osiągnął Elo na poziomie 808, około 11 percentyla. o1-preview osiągnął Elo 1258 i 62. percentyl, o1 Elo 1673 i 89. percentyl, a wyspecjalizowany o1-IOI Elo 1807, 93. percentyl.

Liczb tych nie należy mylić z 49. percentylem IOI. IOI wybiera najbardziej utalentowanych olimpijczyków ze szkół średnich na świecie i stosuje inny rodzaj zadań i punktacji. To właśnie różnica między 93. percentylem Codeforces a 49. percentylem IOI przypomina nam, że „ludzki percentyl” zawsze potrzebuje mianownika.

2024: punkt odniesienia zaczął być odporny na zanieczyszczenia

HumanEval był niezbędny, ale zapewnia tylko 164 miejsca pracy i szybko stał się częścią ekosystemu publicznego. Gdy rozwiązania, testy i pochodne warianty pojawią się w danych szkoleniowych, wysokie wyniki mogą mierzyć pamięć i generalizację.

Dlatego LiveCodeBench stale zbiera nowe zadania od LeetCode, AtCoder i Codeforces. Pierwsza wersja zawierała 400 zadań opublikowanych w okresie od maja 2023 r. do maja 2024 r. Termin wydania zadań pozwala na przetestowanie modeli pod kątem problemów, które pojawiły się po ich prawdopodobnym odcięciu danych.

Ponadto LiveCodeBench nie tylko ocenia generowanie programu. Zawiera scenariusze dla:

• samodzielna naprawa wadliwego kodu;
• przewidywanie wyników programu;
• pracować z informacją zwrotną na temat wykonania;
• klasyczne generowanie rozwiązań.

Jest to istotne metodologicznie. Model, który potrafi napisać rozwiązanie, może nie być w stanie znaleźć konkretnego błędu. Model, który poprawnie naprawia znany błąd, nie musi umieć wymyślać algorytmu od zera. Pojedynczy wynik w kodowaniu niepotrzebnie obniża te umiejętności.

2025: Gemini Deep Think powołało do ICPC zespół złożony z wielu agentów

Finał ICPC to inny rodzaj presji. Zespół ma pięć godzin, jedno otrzymane zgłoszenie oznacza punkt, a każda nieudana próba dodaje karę czasową. Nie wystarczy mieć poprawne@1000. Trzeba szybko znaleźć odpowiedni algorytm, zaimplementować go i wiedzieć, kiedy go wysłać.

Zaawansowana wersja Gemini 2.5 Deep Think rozwiązana Światowe Finały ICPC 2025 zdalnie pod okiem organizatorów. Zaczęła dziesięć minut później niż ludzie, miała ten sam limit pięciu godzin i rozwiązała 10 z 12 zadań. Wykonała osiem zadań w ciągu pierwszych 45 minut, dwa kolejne w ciągu trzech godzin. Z łącznym czasem karnym wynoszącym 677 minut w porównaniu z oficjalną tabelą zajęliby drugie miejsce na 139 drużyn.

DeepMind opisał kilka kluczowych komponentów:

• rozumowanie wieloetapowe;
• myślenie równoległe;
• kilku agentów Gemini z własnymi projektami;
• dostęp do terminala;
• uruchamianie kodu i testów;
• iteracja zgodnie z wynikami wszystkich prób;
• uczenie się wzmacniające przy bardzo trudnych zadaniach programistycznych.

Opublikowano także ostateczne programy Gemini dla ICPC 2025. Jednakże nie można odtworzyć pełnej architektury, liczby próbek ani wszystkich wewnętrznych podpowiedzi. Jest to ważny kamień milowy w konkurencyjności, a nie otwarta recepta na jakość NuminaMath.

Przełom 5: 10 z 12 zadań w pięć godzin

Agenci równoległi + terminale + iteracja: agenci nie napisali po prostu kilku niezależnych programów. Zobaczyli wyniki egzekucji, poprawili się i wykorzystali poprzednie próby jako wspólną pamięć eksperymentalną.

Problem C: żaden zespół uniwersytecki nie znalazł rozwiązania

Gemini rozwiązało Problem C w około pół godziny, co nie zostało zaakceptowane przez żaden ludzki zespół. Zadanie wymagało optymalnej dystrybucji cieczy poprzez sieci kanałów i zbiorników z nieskończoną liczbą możliwych ustawień.

Zgodnie z opublikowanym opisem, Gemini zaimplementowało wartości priorytetów dla stosów. W przypadku stałych priorytetów najlepsze ustawienia kanałów można znaleźć poprzez programowanie dynamiczne. Następnie, używając argumentu minimax, przekształcił pierwotne zadanie w znalezienie priorytetów, które powodują najostrzejsze ograniczenia. Użył zagnieżdżonego wyszukiwania trójskładnikowego w przestrzeni wypukłej.

Ten przykład jest ważny, bo nie chodzi tylko o bezbłędną implementację znanego szablonu. Sukces wymagał wielokrotnych reprezentacji tego samego problemu:

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

To zdolność do zmiany reprezentacji oddziela silnego realizatora od odkrywania algorytmicznego.

2025 i 2026: trzeźwe daty przed zbyt szybkim zwycięstwem

Wiadomości o systemach medalowych mogą sprawiać wrażenie, że programy konkurencyjne są już rozstrzygnięte. Bardziej otwarte testy porównawcze pokazują bardziej złożony obraz.

LiveCodeBench Pro: zero procent na twardym, bez narzędzi

LiveCodeBench Pro został również opracowany przez badaczy i medalistów Międzynarodowych Olimpiad Algorytmicznych. Na bieżąco aktualizowali zadania z Codeforces, ICPC i IOI, opatrywali je adnotacjami według kategorii algorytmicznych i analizowali wadliwe rozwiązania modelowe linia po linii.

Bez narzędzi zewnętrznych najlepiej oceniany model uzyskał 53% pozytywnego wyniku @ 1 w przypadku zadań umiarkowanych i 0% w przypadku zadań trudnych. Autorzy odkryli, że modele są skuteczniejsze w przypadku problemów wymagających intensywnej implementacji niż w przypadku drobnoziarnistego rozumowania algorytmicznego i złożonej analizy przypadków. Często przedstawiali pewne, ale błędne uzasadnienia.

Nie przeczy to wynikowi Gemini. Pokazuje różnicę pomiędzy samodzielnym modelem bez narzędzi a kosztowną, zamkniętą architekturą wieloagentową z terminalami, wykonaniem i iteracją.

LiveOIBench: igrzyska olimpijskie offline z testem porównawczym na ludziach

LiveOIBench, którego trzecia wersja została wydana 8 lipca 2026 r., zawiera 403 fachowo wybrane zadania z 72 konkursów w 14 Olimpiadach Informatycznych z lat 2023-2025. Każde zadanie ma średnio około 60 oficjalnych przypadków testowych i szczegółową rubrykę podzadań. Całą ocenę można przeprowadzić w trybie offline.

Spośród 34 ocenianych modeli GPT-5 uzyskał 81,76. percentyl, wciąż poniżej najlepszych ludzkich konkurentów. Waga otwarta gpt-oss-120b uzyskała wynik w okolicach 60. percentyla. Co więcej, analiza śladów rozumowania wykazała, że ​​solidniejsze modele preferują dokładną analizę danych wejściowych od nadmiernego chaotycznego wyszukiwania.

PRZEŁOM 6: WZORNIK NIE JEST JUŻ WŁAŚNIE ZAAKCEPTOWANYMI ŚRODKAMI / ZŁA ODPOWIEDŹ

Nowe problemy + podzadania + percentyle ludzi: nowa generacja testów porównawczych śledzi datę zadania, punkty częściowe, zakres testów i bezpośrednie porównanie z elitarnymi ludźmi. Wysokie pass@k na małym zestawie statycznym już nie wystarczy.

Co tak naprawdę zwyciężyło w historii

1. Różnorodność algorytmów, nie tylko słów

Zmiana temperatury często powoduje utworzenie innego stylu tego samego algorytmu. Prawdziwa różnorodność oznacza inną strukturę danych, niezmiennik, asymptotykę lub dekompozycję problemu. AlphaCode 2 obsługiwał go za pomocą kilku dopracowanych zasad i zmienionych metadanych.

2. Twarde filtry przed drogim sędzią

Kompilacja, testy publiczne, limity, środki dezynfekujące i sprawdzanie statyczne są tańsze i bardziej niezawodne niż sędzia LLM. W ten sposób AlphaCode 2 wyeliminowało około 95% kandydatów jeszcze przed ostateczną selekcją.

3. Deduplikacja behawioralna

Tekstowo inny kod może być funkcjonalnie identyczny. Grupowanie według wyników i danych wejściowych diagnostycznych chroni budżet przedłożonych wniosków przed dziesięcioma kopiami tego samego błędu.

4. Aktywnie generowane kontrprzykłady

Najlepszy test odróżnia dwóch silnych kandydatów. Generator testów powinien maksymalizować przyrost informacji, a nie liczbę losowych wejść.

5. Uczony strzelec jako ostatnia warstwa, a nie jedyna prawda

Strzelec jest przydatny, gdy wykonanie nie zdecydowało. Nie powinno to zastępować faktu, że program uległ awarii, przekroczył limit lub nie przeszedł znanego testu.

6. Ukierunkowana naprawa

Kiedy znamy nieprawidłowe dane wejściowe, naprawiamy konkretny niezmiennik lub linię. Swobodna synteza dwóch programów może zniszczyć części, które były już poprawne.

7. Obliczenia w czasie testu z budżetem

Stu kandydatów bez selektora to eksperyment wyroczni. Prawdziwa architektura musi optymalizować oczekiwaną liczbę punktów na sekundę procesora graficznego, przy czym kompilacja i przesyłanie są dozwolone.

8. Katedra Zawodów

Planista, realizator, generator testów, krytyk i selektor mają różne cele. Jeden model może pełnić naprzemienne role, jednak protokół musi uniemożliwiać autorowi jedynie potwierdzenie własnego rozwiązania.

Co wręcz przeciwnie, wielokrotnie nie działało

1. Sto niemal identycznych realizacji

Zwiększają pass@k mniej niż sugeruje liczba próbek. Skorelowany błąd przetrwa zarówno głosowanie, jak i zmianę rankingu.

2. Optymalizacja tylko dla publicznych wersji demonstracyjnych

Przykładowy test wyjaśnia format, a nie pełną specyfikację. Model z łatwością uczy się poprawki dla trzech przykładów i pomija ogólny algorytm.

3. Głównym miernikiem jest „Kod wygląda dobrze”.

Sędzia językowy często woli czyste tytuły, komentarze i przekonujące wyjaśnienia. Ukryty kontroler nie dba o styl.

4. Losowe zgłoszenie

W eksperymencie o1-IOI zmierzono prawie 60-punktową różnicę między losową a inteligentną selekcją tej samej populacji.

5. Autorefleksja bez nowych dowodów

Podpowiedź „sprawdź siebie” często prowadzi do dłuższej racjonalizacji. Poprawka powinna uzyskać nowy test, śledzenie, kontrprzykład lub konflikt z innym kandydatem.

6. Łączenie Oracle@k z wydajnością, którą można wdrożyć

Dziesięć tysięcy zgłoszeń powyżej limitu złota nie oznacza złotego medalu poniżej limitu pięćdziesięciu prób. Oracle jest narzędziem diagnostycznym potencjału generatora.

7. Punkt odniesienia bez tymczasowego pochodzenia

W przypadku problemu publicznego potrzebujemy daty publikacji, daty granicznej modelu, dostępności rozwiązania i skrótu konkretnej wersji zbioru danych.

Jak zbudować z niego kod HyperFusion

Historia pokazuje architekturę, która nie jest prosta większością głosów. Jest to kontrolowany cykl eksperymentalny.

Oryginalna ilustracja otwierająca odgrywa tutaj bardziej precyzyjną rolę: przedstawia połączenie wielu niezależnych strumieni myśli, a nie samo programowanie.

Faza 1: ślad problemu

Router najpierw szacuje:

• domena algorytmiczna;
• oczekiwana złożoność;
• potrzeba dowodu matematycznego;
• ryzykowne przypadki graniczne;
• czy bardziej odpowiedni będzie C++, Python, czy inny język;
• na jaki budżet wnioskowania zasługuje dana praca.

Router nie powinien rozwiązać problemu od razu. Ma stworzyć plan eksperymentalny.

Faza 2: ślepy konkurs na projekt algorytmiczny

Trzy do pięciu różnych modeli lokalnych da jedynie projekt algorytmu, niezmienniki i estymację złożoności. Nie widzą sugestii innych. Zapobiega to przedwczesnemu zbieżności w stosunku do pierwszego pewnego pomysłu.

Propozycje pogrupowane są według aktualnej zasady:

• chciwy;
• programowanie dynamiczne;
• transformacja wykresu;
• przepływ lub dopasowanie;
• konstrukcja matematyczna;
• szukaj z przycinaniem;
• procedura losowa lub numeryczna.

Do kolejnego etapu przechodzi maksymalnie dwóch przedstawicieli każdej rodziny.

Faza 3: większa realizacja mocnych planów

Każdy zachowany plan jest realizowany przez co najmniej dwa modele. To oddziela błąd algorytmu od błędu zapisu. Jeśli dwie niezależne implementacje tego samego planu dadzą różne wyniki, otrzymamy bardzo cenny konflikt diagnostyczny.

Faza 4: kuźnia testowa

Samodzielny agent tworzy:

• minimalne przypadki;
• null i puste wejście, jeśli jest dozwolone;
• duplikaty i identyczne wartości;
• maksymalny rozmiar;
• wartości na granicach typów danych;
• przypadki naruszające zachłanną intuicję;
• dane wejściowe, którymi różnią się kandydaci;
• transformacja metamorficzna ze znaną zależnością wyników.

Jeśli znamy powolny algorytm referencyjny dla małychn, stosujemy testy różnicowe. W małych przypadkach wyczerpująco porównujemy szybkich kandydatów za pomocą brutalnej siły.

Etap 5: naprawa ukierunkowana

Kandydat otrzyma jedynie:

• oryginalny plan;
• kod niestandardowy;
• konkretne błędne dane wejściowe;
• oczekiwana i rzeczywista produkcja;
• ewentualnie diagnostyka środka dezynfekującego lub limitu.

Zadaniem nie jest „napisanie lepszego rozwiązania”, ale „znalezienie minimalnej przyczyny tej awarii i naprawienie jej bez zmiany pozostałych niezmienników”.

Etap 6: selekcjoner turnieju

Ranking kandydatów łączy w sobie twarde i miękkie sygnały:

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

Określone skale muszą być powiązane ze zbiorem walidacyjnym. Zestaw testowy służy wyłącznie do jednorazowego raportu.

Etap 7: przesłanie podlegające audytowi

System przechowuje:

• wszystkie projekty algorytmiczne;
• model źródłowy i materiał siewny;
• programy i ich skróty;
• kompilator i flagi;
• wszystkie wygenerowane testy;
• wyniki wykonania;
• poprawki i ich przyczyny;
• końcowy wynik selekcjonera;
• rzeczywisty wynik ukrytego sprawdzania.

Bez tego śladu nie da się określić, czy poprawę spowodował model, generator testowy, pętla naprawcza, czy po prostu większa liczba prób.

Pierwotny plan eksperymentu dla LUMI

Pierwotnie zaprojektowałem Exp05: Behavioral Code Fusion bez kosztownego modelu sędziego, wyłącznie z lokalnymi modelami, kompilatorem, sanitizerami, referencjami brute-force i porównaniem zachowania. Poniższa część zachowuje plan; zaraz po niej znajdują się wyniki rzeczywistego eksperymentu.

Zbiór danych

1. zestaw szkoleniowy do ustalania reguł i skal;
2. zestaw walidacyjny dla wyboru budżetu i reguły zatrzymania;
3. zablokowany zestaw testów według daty publikacji;
4. dodatkowe świeże wsparcie z LiveCodeBench lub LiveOIBench.

Podział musi odbywać się według problemów i ich źródła, a nie według poszczególnych programów. W przeciwnym razie dwa niemal identyczne warianty stanowisk mogą znaleźć się po obu stronach podziału.

Konfiguracja kandydata

Dla każdego problemu:

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

Jest to celowo mniejszy budżet niż milion próbek AlphaCode. Celem jest zmierzenie wydajności, jaką zapewni różnorodność modeli i informacje zwrotne na temat wykonania przy lokalnie realistycznej cenie.

Ablacja

Ta sekwencja dokładnie pokaże wartość odcięcia każdej warstwy. Gdy wariant E nie dodaje wydajności, generator testów nie generuje danych wejściowych informacyjnych. Kiedy G nie dodaje nic powyżej F, drogi strzelec nie jest potrzebny.

Metryki

Jeden procent to za mało:

• pass@1 najsilniejszego modelu;
• wyrocznia@18;
• wybrane@1;
• wybrane@3;
• średnia punktów z podzadań;
• luka Oracle i współczynnik odzyskiwania selektora;
• liczba skupień behawioralnych;
• korelacja błędów parami pomiędzy modelami;
• liczba kompilacji i uruchomień;
• Sekundy GPU, sekundy procesora i energia;
• czas do pierwszego zaakceptowanego rozwiązania;
• ile poprawek usunęło pierwotny błąd, a ile stworzyło nowy.

Kluczową metryką selektora może być:

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

Mówi, ile dostępnej luki wyroczni architektura była w stanie uzyskać bez dostępu do ukrytego rozwiązania.

Jaki byłby faktyczny wynik badań

Najcenniejszym osiągnięciem nie byłoby stwierdzenie „trzy modele są lepsze niż jeden”. Tego można się już spodziewać po pass@k. Przedmiotem zainteresowania badawczego są następujące pytania:

1. Czy różnorodność rodzin modeli jest cenniejsza niż taka sama liczba próbek najlepszego modelu?
2. Czy grupowanie behawioralne może przewidzieć skorelowany błąd?
3. Który typ autotestu najbardziej zwiększa regenerację selektora?
4. Kiedy naprawa pomaga, a kiedy odpowiedni podkład szkodzi?
5. Czy niepewność można oszacować lepiej na podstawie niezgody kandydatów niż na podstawie pewności samego modelu?
6. Jak zmienia się optymalna architektura wraz z pamięcią i budżetem czasowym?
7. Czy potrzebujemy wielkiego sędziego, czy też większość sporów będzie rozstrzygana w drodze egzekucji?

Od projektu do danych: naprawdę uruchomiłem eksperyment na LUMI

Na fińskim superkomputerze LUMI zbudowałem lokalny panel modeli open-weight oraz bezpieczny sandbox do wykonywania kodu. Użyłem warstwowej próbki 40 zadań LiveCodeBench opublikowanych od marca 2025 roku: 13 łatwych, 14 średnich i 13 trudnych, w tym 26 z AtCoder i 14 z LeetCode. gpt-oss-120b, Qwen2.5-72B, GLM-4.7-flash i Mistral-Small-3.2-24B działały lokalnie; Kimi K2.7-code i Kimi K3 przez API służyły jedynie jako punkt odniesienia dla górnej granicy.

Twardy sygnał musi rozróżniać kandydatów

Samo uruchomienie kodu nie wystarczyło. Kandydaci przechodzący wszystkie testy publiczne zwracali w nich identyczne poprawne wyniki, więc selektor pozostawał ślepy. W około jednej piątej zadań taki „public passer” później upadał na teście ukrytym. W kontrolowanym pilotażu mierzyłem wartość warstwy rozróżniającej poprzez czysty podział testów na część selekcyjną i niezależną część oceniającą. W systemie produkcyjnym tę rolę muszą przejąć generowane kontrprzykłady i differential testing.

Najważniejszy wynik z LUMI: najcenniejszym artefaktem nie musi być kolejny program. Może nim być jeden test, który oddziela rozwiązanie poprawne od kodu wyglądającego poprawnie na wszystkich publicznych przykładach.

Łączny oracle pozostał na poziomie 35/40, a jeden najmocniejszy model sam rozwiązał dokładnie te same 35 zadań. Praktyczna recepta nie brzmiała więc „jak najwięcej rodzin modeli”, lecz jeden silny model × więcej próbek × selekcja za pomocą testów rozróżniających.

Pięć najtrudniejszych zadań, cztery orkiestracje

Wyłącznie lokalnym gpt-oss-120b udało się przełamać 2 z 5 zadań, których nie rozwiązał żaden model panelu bazowego. Jedno z nich padło tylko w trybie proof-pilot, choć trzy pozostałe strategie uzyskały zero. Model nie wywoływał narzędzi sam (tool_calls = 0); wykonywaniem kodu i przekazywaniem konkretnych błędów sterował harness.

Kimi K3 ujawnił również pułapkę metodologiczną: przy limicie 12 000 tokenów uzyskał tylko 17/40, ponieważ 35% odpowiedzi kończyło się w połowie rozumowania. Po zwiększeniu limitu do 32 000 tokenów wynik wzrósł do 31/40. Bez biegu kontrolnego błąd harnessu wyglądałby jak słabość modelu.

Szybkość inferencji jako nowy wymiar aplikacji AI

W kursie Fast LLM Inference with Cerebras sprawdziłem przeciwną skrajność: co zmienia się, gdy oczekiwanie na duży model niemal znika? Katalog Cerebras podaje dla gpt-oss-120b około 3000 tokenów wyjściowych na sekundę. To deklaracja dostawcy; moje konkretne pomiary wyglądały następująco:

Podobny prompt z bilardem zajął w jednym biegu GPT-4.1 mini około 39 sekund. Nie jest to czysty benchmark sprzętowy, ponieważ różniły się modele, infrastruktura i ścieżka sieciowa. Różnica w sposobie pracy pozostaje jednak bardzo wyraźna.

Dwie sekundy do pierwszego grywalnego prototypu

Pierwszy Tetris był rzeczywiście grywalny: spadające tetromina, ruch, obrót, szybszy spadek, usuwanie wierszy i punktacja. Nie oznacza to gotowego produktu w dwie sekundy, lecz działającą bazę, którą można natychmiast uruchomić, testować i poprawiać.

Szachy były znacznie bardziej surowe: powstała plansza, sterowanie figurami, podstawowa kontrola ruchów i prosta odpowiedź komputera. Nie są kompletne regułowo i nie zastępują sprawdzonego silnika szachowego. Przejście od pustego promptu do gry interaktywnej w około dwie sekundy nadal robi wrażenie.

To więcej niż szybszy czat

Przy setkach lub tysiącach tokenów na sekundę w jednej interakcji mieszczą się liczni kandydaci, testy, poprawki i wybór wyniku. Dla HyperAdvisor i HyperFusion naturalne są trzy tryby:

Najlepszą metryką nie jest więc samo tokens/s, lecz: jak szybko i za jaką cenę system tworzy zweryfikowany poprawny wynik? Szybkość dostarcza więcej prób, a wykonanie i testy rozróżniające dają powód, by zaufać wybranemu rezultatowi.

Branża równoległa: programowanie konkurencyjne nie jest zwykłą inżynierią oprogramowania

HumanEval, Codeforces, IOI i ICPC mają jasną specyfikację, czyste dane wejściowe, oczekiwane wyniki i stosunkowo izolowany program. Prawdziwe repozytorium to inny świat. Dane wejściowe mogą być niekompletne, testy nieaktualne, a właściwa poprawka może wymagać zrozumienia setek plików.

Dlatego nie mieszałbym SWE-bencha i agentów naprawiających problemy z GitHubem na głównej osi czasu. Zasługuje na osobny artykuł. Zasady są powiązane, ale rola testów jest inna: w zawodach testy definiują prawdę, w prawdziwym rozwoju same mogą być częścią problemu.

Co zabrać

Historia konkurencyjnego programowania AI nie jest prostą historią coraz większych modeli. To historia coraz lepszej organizacji prób:

1. HumanEval ujawnił ogromną różnicę pomiędzy pass@1 i pass@100.
2. AlphaCode zmienił generowanie w wyszukiwanie populacji.
3. AlphaCode 2 połączył różne modele polityki, wykonanie, grupowanie zachowań i wyuczoną punktację.
4. o1-IOI zmierzyło, że wybór tej samej populacji był wart około 57 punktów.
5. LiveCodeBench dodał nowe dane i więcej możliwości niż tylko generowanie.
6. Gemini w ICPC korzystało z równoległych agentów, terminali i napraw iteracyjnych.
7. LiveCodeBench Pro i LiveOIBench pokazały, że elitarne rozumowanie algorytmiczne wciąż nie zostało rozwiązane.
8. Mój eksperyment na LUMI odzyskał dzięki testom rozróżniającym 80–83% dostępnej luki oracle.
9. Cztery orkiestracje tego samego lokalnego modelu przełamały dwa z pięciu najtrudniejszych zadań.
10. Cerebras pokazał drugą oś: generowanie, kontrola i poprawka mogą zmieścić się w jednej interakcji.

Ostateczna zasada: Najmądrzejszy system programowania to nie ten, który myśli najdłużej w jednym monologu. Jest to system, który może generować niezależne hipotezy, projektować eksperymenty, zbierać twarde dowody, naprawiać określone błędy i zarządzać ograniczonym budżetem zgłoszeń.

Programowanie może być idealnym laboratorium dla HyperFusion. Mamy tu coś, czego często brakuje w otwartych pytaniach humanistycznych: tani feedback z rzeczywistości. Jeśli dobrze z niego korzystamy, nie potrzebujemy jednego modelu, aby był idealny. Potrzebujemy, aby cały system mógł uczyć się na każdym nieudanym uruchomieniu.

Źródła pierwotne i materiały reprodukcyjne

• DeepCoder: Nauka pisania programów
• Ocena modeli wielkojęzykowych przeszkolonych w zakresie kodu, kodeksu i HumanEval
• Pomiar kompetencji w zakresie kodowania za pomocą aplikacji APPS
• Generowanie kodu na poziomie konkurencji za pomocą AlphaCode
• DeepMind: Programowanie konkurencyjne przy użyciu AlphaCode
• Zbiór danych i narzędzia wykonawcze CodeContests
• Raport techniczny AlphaCode 2
• OpenAI: Nauka rozumowania za pomocą LLM, sekcja dotycząca IOI i Codeforces
• LiveCodeBench
• Repozytorium LiveCodeBench i wiązka ewaluacyjna
• LiveCodeBench Pro
• LiveOIBench
• Gemini 2.5 Deep Think na światowych finałach ICPC 2025
• Opublikowano programy Gemini z ICPC 2025
• Oryginalny post Andreja Karpathy'ego na temat kodowania wibracji
• Słowo roku 2025 według Collinsa: kodowanie wibracji
• Ankieta dla programistów Stack Overflow 2025: AI i kodowanie wibracji
• METER: pomiar produktywności doświadczonych programistów open source za pomocą AI
• Fast LLM Inference with Cerebras, kurs DeepLearning.AI
• Katalog Cerebras Inference i deklarowana szybkość gpt-oss-120b
• Cerebras Cloud