Wie KI programmieren lernte: Von HumanEval zur ICPC-Goldmedaille

Programmieren hat gegenüber mathematischem Denken einen großen Vorteil: Wir können die Antwort ausführen. Ein Programm wird entweder kompiliert oder nicht. Für eine konkrete Eingabe liefert es eine konkrete Ausgabe. Wir können Zeit und Speicher messen und das Ergebnis mit einem verborgenen Checker vergleichen. In unserem kürzlich erschienenen Artikel über den Weg der KI von GSM8K zu Beweisagenten haben wir untersucht, wie mathematische Systeme mehrere Lösungswege erzeugen, abstimmen und Beweise überprüfen lernten. Dieser Artikel setzt dieselbe Geschichte in einer Umgebung fort, in der sich das Ergebnis nicht nur beurteilen, sondern tatsächlich ausführen lässt.

Dies führt zu der Idee, dass wettbewerbsorientiertes Programmieren für KI einfacher ist als Mathematik. Es ist tatsächlich ein härteres und saubereres Labor. Das Modell muss aus einer langen Eingabe einen versteckten Algorithmus ableiten, seine Richtigkeit beweisen, ihn in ein fehlerfreies Programm übersetzen und Eingaben überstehen, die es noch nie gesehen hat. Die einzige weggelassene Randbedingung bedeutet Null.

In fünf Jahren hat sich also nicht nur die Leistung der Modelle verändert, sondern die gesamte Art und Weise, wie wir KI programmieren lassen. Im Jahr 2021 haben wir gefragt, ob ein Modell die Kurzfunktion beim ersten Versuch absolvieren würde. Im Jahr 2025 entwarfen bereits mehrere Agenten parallel Algorithmen, führten den Compiler und Tests aus, tauschten gefundene Fehler aus und iterierten zu einer ICPC-Goldmedaillen-Lösung.

Dieser Text ist eine technische Geschichte dieser Transformation. Es geht nicht nur darum, welches Modell wie viele Punkte bekommen hat, sondern vor allem darum, welcher Algorithmus aus Inferenz, Auswahl und Verifizierung dieses Ergebnis hervorgebracht hat. Es sind diese Prinzipien, die auf HyperFusion und auf Experimente bei LUMI übertragbar sind.

Hauptschlussfolgerung: Den größten Sprung machte nicht das Modell, das ein weiteres perfektes Programm schrieb. Es wurde durch Systeme verursacht, die eine Population unterschiedlicher Algorithmen erstellten, offensichtliche Fehler kostengünstig aussortierten, nach Gegenbeispielen suchten, nur bewährte Fehler behoben und intelligent entschieden, welche Programme überhaupt einen Versand wert waren.

Vom Flüstern bis zum Vibe-Coding

Der Begriff Vibe-Codierung wurde am 2. Februar 2025 von Andrej Karpathy für eine Arbeitsweise eingeführt, bei der eine Person die Absicht in natürlicher Sprache beschreibt, große durch KI verursachte Änderungen akzeptiert und das System schrittweise steuert, ohne unbedingt jede Zeile lesen zu müssen. Innerhalb weniger Monate war der technische Slang zu einem kulturellen Begriff geworden, und Collins wählte ihn zum Wort des Jahres 2025.

ERKLÄRUNG: WAS IST VIBE CODING

In seiner reinen Form handelt es sich nicht nur um automatische Vervollständigung oder gelegentliche Chatbot-Ratschläge. Der Programmierer lenkt seine Aufmerksamkeit von der Syntax auf die Absicht, das Anwendungsverhalten und andere Anweisungen für das Modell. Der Code kann in großen Blöcken erstellt werden und der Autor muss ihn nicht im Detail verstehen. Das ist großartig für einen Prototyp, aber gefährlich überall dort, wo es an Tests, Sicherheitsüberprüfungen und jemandem mangelt, der das resultierende System versteht.

Es ist wichtig, das schnelle Wachstum von KI-Tools nicht mit reinem Vibe-Coding zu verwechseln. Stack Overflow Developer Survey 2025 berichtet, dass 84 % der Befragten KI-Tools verwenden oder dies planen, gegenüber 76 % im Vorjahr, und 51 % der professionellen Entwickler nutzen sie täglich. Gleichzeitig gaben jedoch 72 % der Befragten an, dass Vibe-Coding nicht zu ihrer beruflichen Tätigkeit gehört. KI-Unterstützung ist weit verbreitet, nicht automatisch die Bereitschaft, mit der Überprüfung des Codes aufzuhören.

Eine nüchternere Korrektur lieferte das METR-Experiment aus dem ersten Halbjahr 2025. Sechzehn erfahrene Open-Source-Entwickler lösten 246 Aufgaben in ihren eigenen Repositories und benötigten mit den damaligen KI-Werkzeugen im Durchschnitt 19 % mehr Zeit. Das ist eine enge Momentaufnahme und kein allgemeingültiges Urteil über KI-Programmierung. Es erinnert aber daran, dass die schnelle Verbreitung eines Werkzeugs noch keine höhere Produktivität beweist.

Wettbewerbsorientierte Programmierung ist daher ein interessanter Kontrapunkt zur Vibe-Codierung. Wir können den Code sehr frei generieren, aber am Ende muss er einen genauen Prüfer bestehen. Es ist nicht die Geschwindigkeit des Schreibens selbst, die für die Forschung von Bedeutung ist, sondern die Fähigkeit, einen vagen Strom von Vorschlägen in ein verifiziertes Programm umzuwandeln.

Zuerst die Regeln: Codeforces, IOI und ICPC sind nicht die gleiche Disziplin

Eine Zahl wie „85. Perzentil in der Programmierung“ klingt eindeutiger, als sie tatsächlich ist. Codeforces, Internationale Olympiade in Informatik und ICPC testbezogene, aber unterschiedliche Fähigkeiten.

Außerdem messen Metriken verschiedene Dinge:

Daher werde ich in dem Artikel keine einzige falsch glatte Kurve der „allgemeinen Programmierintelligenz“ zeichnen. Für jeden Punkt in der Zeitleiste liste ich die Plattform, die Anzahl der Versuche, die Tools und die Art und Weise der Konvertierung in ein menschliches Ranking auf.

Zeitleiste des menschlichen Äquivalents

Die ersten Systeme hatten noch kein glaubwürdiges menschliches Perzentil. DeepCoder beschleunigte 2017 die enumerative Suche nach Kurzprogrammen um etwa eine Größenordnung, funktionierte jedoch in einem begrenzten DSL und löste nur Probleme mit ähnlichen Schwierigkeitsgraden wie die einfachsten Wettbewerbsbeiträge. Codex erreichte im Jahr 2021 eine Pass@1-Bewertung von 28,8 % bei HumanEval, HumanEval verfügt jedoch nicht über eine Rangliste menschlicher Konkurrenten. Diese Meilensteine ​​gehören daher auf einer Achse und nicht auf einer Perzentilskala.

Ab 2022 haben wir bereits mehrere direkte, wenn auch noch nicht ganz austauschbare Vergleiche mit Menschen. Ich habe nur das Grenzsystem der gegebenen Zeit und sein öffentlich dokumentiertes Ergebnis in die Grafik eingefügt:

• AlphaCode, Codeforces 2022: übertraf etwa 45,7 % der Wettbewerber und lag damit etwa im Mittelwert.
• AlphaCode 2, Codeforces 2023: haben durchschnittlich 85 % der Teilnehmer bestanden. In den ersten beiden Wettbewerben übertraf er jedoch mehr als 99,5 % der Teilnehmer. Es ist diese Varianz, die zeigt, warum der Durchschnitt selbst einen wichtigen Teil der Geschichte verbirgt.
• o1, Codeforces 2024: allgemein o1 erreichte das 89. Perzentil. Eine für IOI weiter trainierte Variante erreichte Elo 1807 und das 93. Perzentil.
• o1-IOI, IOI 2024: Unter der tatsächlichen Grenze von 50 Einsendungen pro Aufgabe erzielte er 213 Punkte und lag im 49. Perzentil der Elite-Highschool-Olympioniken.
• GPT-5, LiveOIBench 2025: erzielte bei den Olympischen Spielen 2023 bis 2025 bei 403 Aufgaben eine Punktzahl von 81,76. Perzentil. Die Autoren weisen darauf hin, dass die besten Leute in dieser Gruppe tendenziell über dem 90. Perzentil liegen.
• Gemini 2.5 Deep Think, ICPC 2025: Zehn gelöste Probleme würden den zweiten Platz von 139 Teams bedeuten, besser als etwa 98,6 % der Bestenliste. Dies ist eine hypothetische Neuberechnung, da Gemini kein offiziell eingestuftes Uni-Team war.

Ich verbinde nur die Linie zwischen Ergebnissen aus derselben Codeforces-Familie. IOI, ICPC und LiveOIBench bleiben separate Punkte, da ihre Populationen und Regeln unterschiedlich sind. Die vertikale Linie in AlphaCode 2 ist kein Konfidenzintervall, sondern die Differenz zwischen dem Durchschnitt und den beiden besten Wettbewerben. Somit zeigt die Grafik zwei Wahrheiten gleichzeitig: Grenzsysteme erreichten in einigen Wettbewerben fast das 99. Perzentil, während sie in einer anderen Elitedisziplin im selben Jahr etwa im Median blieben.

2021: HumanEval hat gezeigt, dass Fähigkeit eine Verteilung und kein einzelner Versuch ist

Die Arbeit Evaluating Large Language Models Trained on Code] führte Codex und damit HumanEval ein, 164 handgeschriebene Programmieraufgaben. Das Modell verfügt über eine Funktionssignatur, einen Dokumentstring und mehrere vor der Generierung verborgene Komponententests.

Codex löste 28,8 % der Aufgaben beim ersten Versuch. Als die Autoren jedoch 100 Programme aus demselben Modell generierten, ergab sich für 70,2 % der Probleme mindestens eine richtige Lösung.

Dies ist einer der wichtigsten numerischen Unterschiede in der gesamten Geschichte:

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

Daher konnte das Modell oft die richtige Lösung generieren, aber ein Versuch schlug fehl, sie zuverlässig zu extrahieren. Daraus ergaben sich zwei unterschiedliche Forschungsfragen:

1. wie man die Verteilung der Kandidaten verbessert;
2. wie man unter hundert ähnlich überzeugenden Vorschlägen das richtige Programm erkennt, ohne Kenntnis von versteckten Tests.

DURCHBRUCH 1: 28,8 % VERÄNDERT SICH IN 70,2 %

Wiederholte Probenahme: Stellen Sie demselben Modell mehrmals dieselbe Aufgabe. Das richtige Programm erschien viel häufiger als durch pass@1 angegeben. Aber es entstand ein Auswahlproblem: Das Orakel weiß, welcher Kandidat die versteckten Tests bestehen wird, das reale System jedoch nicht.

APPS: Die Aufgabe des Programmierers bestand nicht mehr nur darin, eine Funktion hinzuzufügen

Der APPS-Benchmark im selben Jahr ergab 10.000 Probleme, die von einfachen Aufgaben bis hin zu kompetitiven algorithmischen Herausforderungen reichten. Die Eingabe erfolgte in natürlicher Sprache und die Richtigkeit wurde durch Testfälle ermittelt. Das damalige GPT-Neo schaffte etwa 20 % der Einzeltests bei anfänglichen Problemen, nicht 20 % der vollständig gelösten schweren Aufgaben.

APPS führte eine wichtige Unterscheidung ein, die bis heute manchmal verloren geht: Der Prozentsatz der bestandenen Testfälle ist nicht dasselbe wie der Prozentsatz der vollständig gelösten Probleme. Ein Programm, das neun von zehn Tests besteht, kann eine praktisch nützliche Grundlage haben. Aber in einem binären Checker-Wettbewerb erhält es immer noch eine Null.

2022: AlphaCode hat die Codegenerierung auf Bevölkerungssuche umgestellt

AlphaCode war das erste System, das in den neuen Codeforces-Wettbewerben ungefähr die mittlere Teilnehmerzahl erreichte. Für die Auswertung wurden zehn Wettkämpfe verwendet, die aktueller sind als die Trainingsdaten. Es handelte sich nicht um eine kurze Funktionserweiterung, sondern um eine lange Aufgabe, die Kombinatorik, Graphen, dynamische Programmierung und präzise Komplexitätsanalyse erforderte.

Architektur war wichtiger als ein einzelner Kontrollpunkt:

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

AlphaCode hat Transformatoren mit öffentlichem Code von GitHub vorab trainiert und sie auf Wettbewerbsaufgaben und -lösungen umgeschult. Während der Inferenz generierte es eine Größenordnung mehr Programme als frühere Arbeiten. Anschließend filterte, gruppierte er sie und reduzierte sie auf zehn Versuche.

In der Simulation landete er im Durchschnitt unter den besten 54,3 % der Bestenliste. Dies wird oft fälschlicherweise als 54. Perzentil geschrieben. Dies bedeutet korrekterweise, dass etwa 45,7 % der Teilnehmer ein schlechteres Ergebnis hatten.

DURCHBRUCH 2: MILLIONEN PROGRAMME, ZEHN EINREICHUNGEN

Bevölkerungssuche: Das Modell war kein Kandidat, der eine Lösung geschrieben hat. Er war ein Bevölkerungsgenerator. Eine separate Ebene der Zusammenstellung, Prüfung, Deduplizierung und Auswahl entschied darüber, welche Mitglieder der Bevölkerung die seltene Gelegenheit erhalten würden, geschickt zu werden.

CodeContests: Der Datensatz enthielt auch fehlerhafte menschliche Lösungen

DeepMind hat den CodeContests-Datensatz und die Ausführungstools veröffentlicht. Die Daten umfassen Aufgaben von Codeforces, AtCoder, CodeChef und anderen Quellen, Testeingaben und -ausgaben sowie richtige und falsche menschliche Lösungen.

Schlechter Code ist überraschend wertvoll für das Training. Damit lässt sich nicht nur lehren, „wie die richtige Lösung aussieht“, sondern auch, „welche kleinen Änderungen das empfangene Programm in ein nahezu korrektes Programm verwandeln“. Für das zukünftige Kritik- und Reparaturmodell ist diese Grenze nützlicher als weitere tausend fehlerfreie Vorlagen.

Die Geheimwaffe von AlphaCode: Clustering nach Verhalten, nicht nach Text

Zwei Programme können völlig unterschiedlich aussehen und dennoch den gleichen Algorithmus implementieren. Umgekehrt können sich zwei nahezu identische Implementierungen durch ein einziges Vorzeichen unterscheiden und an der Bereichsgrenze ein unterschiedliches Verhalten aufweisen.

Daher hat AlphaCode die Vielfalt nicht allein aus der Textähnlichkeit abgeleitet. Er generierte zusätzliche Eingaben, ließ darauf Kandidatenprogramme laufen und erstellte für jedes Programm eine Signatur seiner Ausgaben:

testy = generate_inputs(problem)

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

clusters = group_by_similar_signature(programs)

Wenn zehntausend Programme bei allen Diagnoseeingängen das Gleiche zurückgeben, macht es keinen Sinn, zehn kosmetische Varianten davon zu senden. Es ist besser, einen Vertreter auszuwählen und das verbleibende Einreichungsbudget anderen Verhaltenshypothesen zu widmen.

Dies ist das Programmieräquivalent zur Abstimmung über eine normalisierte mathematische Antwort, jedoch mit einem viel reichhaltigeren Signal. Wir stimmen nicht nur über die endgültige Zahl ab. Wir vergleichen Funktionen anhand ihres Verhaltens bei einem vollständigen Satz gezielter Fragen.

Warum der größte Cluster nicht automatisch wahr ist

Verhaltensmehrheit funktioniert, wenn der richtige Algorithmus einen großen Bereich ähnlicher Implementierungen erzeugt und die Fehler fragmentiert sind. Aber es kann scheitern, wenn Modelle denselben weit verbreiteten Irrtum teilen. Ein typisches Beispiel ist eine Lösung, die die Demo besteht, aber Überläufe, doppelte Werte oder den asymptotischen Worst Case ignoriert.

Daher ist die Clustergröße kein Beweis. Es ist ein Prior. Harte Tests, kontroverse Einträge und ein guter Punktezähler müssen entscheiden, ob die größte Gruppe die weise Gruppe oder die Gruppe mit dem gleichen Fehler ist.

2023: AlphaCode 2, eine Million Kandidaten auf zehn eingegrenzt

AlphaCode Tech Report 2 bietet ein äußerst spezifisches Rezept. Die Basis bildete eine vom Gemini Pro abgeleitete Modellfamilie, kein einzelner Generator. Die Modelle durchliefen zwei Runden der Feinabstimmung des aktualisierten CodeContests-Datensatzes und eines höherwertigen Ergänzungssatzes.

Das aktualisierte Korpus enthielt etwa 15.000 Probleme und 30 Millionen menschliche Programme. Es wurde eine Familie von Richtlinienmodellen mit unterschiedlichen Hyperparametern erstellt. Diversität wurde also nicht einfach einer zufälligen Temperatur überlassen, sondern in die Generatorfamilie eingebaut.

Für jedes der 77 Probleme aus den zwölf neuen Codeforces-Wettbewerben hat das System Folgendes getan:

1. generierte bis zu 1.000.000 C++-Programme;
2. Zufällig geänderte Temperatur und Metadaten in der Eingabeaufforderung;
3. das Budget gleichmäßig auf mehrere politische Modelle aufteilen;
4. in öffentliche Beispiele eingeführte Kandidaten;
5. nicht kompilierbare und offensichtlich fehlerhafte Programme entfernt;
6. erstellte Verhaltenscluster von etwa 50.000 Überlebenden;
7. verließ die zehn größten Cluster;
8. wählte mit einem ausgebildeten Gemini-Scorer den besten Vertreter jedes Clusters aus;
9. nicht mehr als zehn Programme gesendet.

Öffentliche Tests und Zusammenstellungen eliminierten im Durchschnitt etwa 95 % der Kandidaten. Dies ist ein wichtiger wirtschaftlicher Grundsatz: Der liebe, gebildete Richter sollte nicht mit Code verschwendet werden, der nicht einmal das erste Beispiel besteht.

Das Ergebnis war, dass 43 % der Probleme innerhalb von zehn Versuchen gelöst wurden, gegenüber 25 % des ursprünglichen AlphaCode. Der geschätzte Rang veränderte sich von einer Leistung, die besser als etwa 46 % der Teilnehmer war, zu einer Leistung, die besser als 85 % der Teilnehmer war.

Noch beeindruckender ist die Effizienz. Etwa 100 Samples von AlphaCode 2 reichten aus, um die Leistung des ursprünglichen AlphaCode mit einer Million Samples zu erreichen. Die Autoren berichten daher von einer mehr als zehntausendfachen Verbesserung der Probeneffizienz auf diesem Vergleichsniveau.

PAUSE 3: 25 % VERÄNDERT SICH AUF 43 % UND DER MEDIAN AUF DAS 85. PERZENTIL

Diverse Richtlinien + Ausführung + Clustering + Scorer: Ein stärkeres Modell machte die Suche nicht überflüssig. Er veränderte seine Wirtschaft. Hundert neue Proben könnten eine Million alte wert sein, aber das Endergebnis hing immer noch von einem harten Filter und einer strengen Auswahl ab.

So generieren Sie eine Million Kandidaten: Sampling ist nicht dasselbe wie Baumsuche

Die intuitive Erklärung ist oft, dass das System den Lösungsbaum durchsucht hat. Aber die Geschichte ist subtiler.

DeepCoder verwendete 2017 tatsächlich die klassische Suche. Das neuronale Netzwerk schätzte anhand der Beispiele, welche Funktionen der eingeschränkten Sprache im Programm benötigt würden, und die Tiefensuche, der Aufzählungslöser oder der SMT-Löser folgten diesen Wahrscheinlichkeiten. Somit reduzierte und ordnete das Modell den expliziten kombinatorischen Raum von Kurzprogrammen.

AlphaCode und AlphaCode 2 hingegen generierten nicht eine Million Kandidaten mithilfe einer riesigen Monte-Carlo-Baumsuche. Der generative Transformator hat wiederholt autoregressiv das gesamte Programm Token für Token abgetastet. Einzelne Rollouts könnten unabhängig voneinander und massiv parallel durchgeführt werden. Die Vielfalt wurde durch unterschiedliche Richtlinienmodelle, Sprachen, Eingabeaufforderungen, Metadaten und zufällig ausgewählte Temperaturen geschaffen. Nur fertige Programme durchliefen die Kompilierung, öffentliche Tests, Verhaltens-Clustering und Scorer.

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í

Warum hat er überhaupt eine Million verdient? Wettbewerbsprogramme sind relativ kurz, die Probenahme kann problemlos auf Beschleunigern gestapelt werden und die Einführungen müssen nicht aufeinander warten. Eine Million Kandidaten bedeutet nicht, dass eine Million zugelassene Einreichungen möglich sind. AlphaCode 2 reduzierte eine Million Rohprogramme nach den ersten Filtern, dann zehn Verhaltensclustern und schließlich zehn tatsächlichen Übermittlungen auf etwa 50.000 Überlebende.

Für o1-IOI kennen wir die externe Schnittstelle, nicht den vollständigen proprietären Mechanismus. Laut OpenAI hat das System viele Kandidaten befragt, 50 mithilfe öffentlicher und generierter Tests und eines erfahrenen Bewerters ausgewählt und in einem veröffentlichten Experiment 10.000 Einreichungen pro Job zugelassen. Der öffentliche Bericht behauptet jedoch nicht, dass MCTS im Inneren lief. Wir wissen, dass o1 mit längerer Testzeit die Rechenleistung verbessert und seinen eigenen Fortschritt korrigieren kann. Die genaue Form der internen Verzweigung wurde nicht veröffentlicht.

Darüber hinaus schaffen heutige Agentensysteme Diversität nicht allein durch unabhängige Stichproben. Eine typische Schleife ist planen -> implementieren -> kompilieren -> fehlgeschlagener Test -> gezielte Korrektur. Ein neuer Kandidat wird als Zweig entstehen, der durch einen bestimmten Fehlernachweis ausgelöst wird. Beam Search, DFS oder MCTS können über eine solche Schleife aufgebaut werden, sie sind jedoch keine automatische Erklärung für jedes Argumentationsmodell.

Der wichtigste Trend ist wirtschaftlicher Natur: Strengere politische Maßnahmen reduzieren die Anzahl der benötigten Blindproben drastisch. AlphaCode 2 erreichte mit etwa 100 Samples die Leistung, für deren Erreichung der ursprüngliche AlphaCode eine Million benötigte. Daher ist es für HyperFusion sinnvoller, Dutzende bewusst unterschiedlicher Pläne zu erstellen, deren Verhalten zu messen und nur dann zu verzweigen, wenn ein Test einen Konflikt aufdeckt, als gedankenlos eine Million kosmetischer Varianten zu produzieren.

Der Compiler ist nicht nur Schiedsrichter, er ist auch Lehrer

Die Programmierung bietet Hinweise, die Mathematiktexte oft nicht bieten:

• der Parser zeigt einen Syntaxfehler an;
• Der Compiler gibt den Problemtyp und die Problemzeile zurück.
• Die Laufzeit erkennt eine Ausnahme oder einen Überlauf.
• Der Profiler zeigt die Zeit- oder Speicherkomplexität an.
• Der Checker gibt die spezifische Eingabe zurück, bei der die Lösung fehlgeschlagen ist.
• Differenzialtests werden zeigen, wo die Kandidaten voneinander abweichen.

Nicht alle Signale sind gleich wertvoll. Ein Kompilierungsfehler weist oft direkt auf einen lokalen Fix hin. „Falsche Antwort auf versteckten Test 37“ sagt fast nichts. Daher betrachten die besten Architekturen das Ausführungsfeedback nicht als eine einzelne Nachricht, sondern als eine schrittweise Verfeinerung der Diagnose.

Testgenerierung als aktives Experiment

Der nützlichste Test ist keine zufällige Eingabe. Es ist die Eingabe, bei der zwei plausible Lösungen nicht übereinstimmen. Es hat einen hohen Informationswert, da es die Hypothesen aufspaltet.

Stellen wir uns drei Kandidaten vor:

• Und es verwendet einen gierigen Algorithmus;
• B dynamische Programmierung;
• C gleiches gieriges Verfahren, behebt jedoch Duplikate.

Ein Zufallstest kann für alle die gleichen Ergebnisse liefern. Der aktive Generator soll nach dem kleinen Fall mit Duplikation, dem Fall mit Null, der maximalen Reichweite und der Konstruktion suchen, bei der Greedy das globale Optimum verletzt. Erst dann wird das Testen zu einem wissenschaftlichen Experiment und nicht zu einer Lotterie.

2024: o1-IOI hat den Selektorwert genau gemessen

OpenAI evaluierte bei der Internationalen Informatikolympiade 2024 ein von o1 abgeleitetes Spezialmodell. Laut offizieller Beschreibung hatte das System zehn Stunden für sechs Aufgaben und maximal 50 Einreichungen pro Problem.

Er hat für jedes Problem viele Kandidaten generiert. Er wählte die fünfzig eingereichten Lösungen nach drei Signalen aus:

1. Leistung bei öffentlichen IOI-Tests;
2. Leistung bei vom Modell generierten Tests;
3. erlernte Scoring-Funktionen.

Das Ergebnis waren 213 Punkte und das 49. Perzentil der Konkurrenten. Gleichzeitig schätzte OpenAI, dass eine zufällige Auswahl von Kandidaten im Durchschnitt nur 156 Punkte erreichen würde.

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

Dies ist die reinste Ablation des kognitiven Architekturwerts, die es gibt. Die richtigen Programme waren bereits in der Bevölkerung. Knapp 60 Punkte wurden nicht durch zusätzliches Vortraining geschaffen, sondern durch die Möglichkeit, die begrenzten 50 Einreichungen in bessere Kandidaten zu investieren.

Als die Grenze künstlich auf 10.000 Einreichungen pro Problem gelockert wurde, erreichte das System 362,14 Punkte und lag damit über der Goldmedaillenschwelle, auch ohne Auswahl der Testzeit. Dieses Ergebnis ist als Orakelexperiment wertvoll, aber kein faires Wettbewerbsergebnis. Es zeigt die Obergrenze des Generators bei nahezu unbegrenzten Versuchen an, nicht die Fähigkeit, nach den IOI-Regeln zu arbeiten.

DURCHBRUCH 4: +57 PUNKTE OHNE DEN GENERATOR ZU WECHSELN

Öffentliche Tests + generierte Tests + erlernter Punktezähler: Der Selektor entschied, welche der vielen Lösungen das begrenzte Einreichungsbudget verbrauchen würde. Durch die zufällige Auswahl blieb ein Großteil der Fähigkeiten des Modells ungenutzt.

Codeforces-Bewertung: gleiche Familie, andere Ansicht

OpenAI simulierte auch Codeforces-Wettbewerbe mit zehn zulässigen Einsendungen. GPT-4o erreichte einen Elo von 808, etwa im 11. Perzentil. o1-preview erreichte Elo 1258 und das 62. Perzentil, o1 Elo 1673 und das 89. Perzentil und spezialisiertes o1-IOI Elo 1807, das 93. Perzentil.

Diese Zahlen sind nicht mit dem 49. Perzentil des IOI zu verwechseln. IOI wählt die talentiertesten High-School-Olympioniken der Welt aus und verwendet eine andere Art von Aufgaben und Bewertung. Es ist der Unterschied zwischen dem 93. Perzentil von Codeforces und dem 49. Perzentil von IOI, der uns daran erinnert, dass das „menschliche Perzentil“ immer einen Nenner benötigt.

2024: Der Benchmark beginnt, einer Kontamination zu widerstehen

HumanEval war wichtig, hat aber nur 164 Arbeitsplätze und wurde schnell Teil des öffentlichen Ökosystems. Sobald die Lösungen, Tests und abgeleiteten Varianten in den Trainingsdaten erscheinen, können hohe Werte sowohl das Gedächtnis als auch die Generalisierung messen.

LiveCodeBench sammelt daher kontinuierlich neue Aufgaben von LeetCode, AtCoder und Codeforces. Die erste Veröffentlichung enthielt 400 Aufgaben, die von Mai 2023 bis Mai 2024 veröffentlicht wurden. Das Veröffentlichungsdatum der Aufgaben ermöglicht es, die Modelle auf Probleme zu testen, die nach ihrem wahrscheinlichen Datenschnitt aufgetreten sind.

Darüber hinaus wertet LiveCodeBench nicht nur die Programmgenerierung aus. Enthält Szenarien für:

• Selbstreparatur von fehlerhaftem Code;
• Vorhersage der Programmausgabe;
• mit Ausführungsfeedback arbeiten;
• klassische Lösungsgenerierung.

Dies ist methodisch wichtig. Ein Modell, das eine Lösung schreiben kann, ist möglicherweise nicht in der Lage, einen bestimmten Fehler zu finden. Ein Modell, das einen bekannten Fehler korrekt behebt, muss nicht in der Lage sein, einen Algorithmus von Grund auf zu erfinden. Ein einziger Codierungs-Score lässt diese Fähigkeiten unnötigerweise außer Acht.

2025: Gemini Deep Think brachte ein Multi-Agenten-Team zum ICPC

Das ICPC-Finale ist eine andere Art von Druck. Das Team hat fünf Stunden Zeit, eine einzelne erhaltene Einreichung bedeutet einen Punkt und jeder Fehlversuch bringt eine Zeitstrafe mit sich. Es reicht nicht aus, korrekt@1000 zu haben. Sie müssen schnell den richtigen Algorithmus finden, ihn implementieren und wissen, wann er gesendet werden muss.

Erweiterte Version von Gemini 2.5 Deep Think löste ICPC World Finals 2025 aus der Ferne unter Aufsicht der Organisatoren. Sie begann zehn Minuten später als die Menschen, hatte das gleiche Zeitlimit von fünf Stunden und löste zehn der zwölf Aufgaben. Acht Aufgaben bewältigte sie in den ersten 45 Minuten, zwei weitere innerhalb von drei Stunden. Mit einer kombinierten Strafzeit von 677 Minuten würden sie im Vergleich zur offiziellen Tabelle Zweiter von 139 Teams werden.

DeepMind beschrieb mehrere Schlüsselkomponenten:

• mehrstufiges Denken;
• paralleles Denken;
• mehrere Gemini-Agenten mit eigenen Designs;
• Terminalzugang;
• Ausführen von Code und Tests;
• Iteration entsprechend den Ergebnissen aller Versuche;
• Verstärkungslernen bei sehr schwierigen Programmieraufgaben.

Die endgültigen Gemini-Programme für ICPC 2025 wurden ebenfalls veröffentlicht. Allerdings können die vollständige Architektur, die Probenanzahl und alle internen Eingabeaufforderungen nicht reproduziert werden. Dies ist ein wichtiger Wettbewerbsmeilenstein und kein offenes NuminaMath-Qualitätsrezept.

DURCHBRUCH 5: 10 VON 12 AUFGABEN IN FÜNF STUNDEN

Parallele Agenten + Terminals + Iteration: Agenten haben nicht nur mehrere unabhängige Programme geschrieben. Sie sahen die Ergebnisse der Hinrichtung, korrigierten sich und nutzten die vorangegangenen Prozesse als gemeinsame experimentelle Erinnerung.

Problem C: Kein Universitätsteam hat eine Lösung gefunden

Gemini löste Problem C in etwa einer halben Stunde, was von keinem menschlichen Team akzeptiert wurde. Die Aufgabe erforderte eine optimale Flüssigkeitsverteilung durch Netzwerke von Kanälen und Reservoirs mit unendlich vielen möglichen Einstellungen.

Laut der veröffentlichten Beschreibung hat Gemini Prioritätswerte für Stacks implementiert. Für feste Prioritäten könnten die besten Kanaleinstellungen durch dynamische Programmierung gefunden werden. Mithilfe des Minimax-Arguments wandelte er dann die ursprüngliche Aufgabe dahingehend um, die Prioritäten zu finden, die die engsten Einschränkungen erzeugen. Er verwendete eine verschachtelte ternäre Suche im konvexen Raum.

Dieses Beispiel ist wichtig, da es sich nicht nur um eine einwandfreie Implementierung einer bekannten Vorlage handelt. Für den Erfolg waren mehrere Darstellungen desselben Problems erforderlich:

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

Es ist die Fähigkeit, die Darstellung zu ändern, die einen starken Implementierer von der algorithmischen Entdeckung unterscheidet.

2025 und 2026: nüchterne Termine gegen zu schnellen Sieg

Nachrichten über Medaillensysteme können den Eindruck erwecken, dass die Wettbewerbsprogrammierung geklärt sei. Offenere Benchmarks zeigen ein komplexeres Bild.

LiveCodeBench Pro: null Prozent auf hart ohne Werkzeug

LiveCodeBench Pro wurde auch von Forschern und Medaillengewinnern der Internationalen Algorithmischen Olympiaden zusammengestellt. Sie aktualisierten kontinuierlich Aufgaben von Codeforces, ICPC und IOI, kommentierten sie nach algorithmischen Kategorien und analysierten die fehlerhaften Modelllösungen Zeile für Zeile.

Ohne externe Tools erreichte das am besten bewertete Modell 53 % „Pass@1“ bei mittelschweren Aufgaben und 0 % bei schwierigen Aufgaben. Die Autoren fanden heraus, dass die Modelle bei umsetzungsintensiven Problemen leistungsfähiger sind als bei feinkörnigen algorithmischen Überlegungen und komplexen Fallanalysen. Sie brachten oft selbstsichere, aber falsche Begründungen vor.

Dies steht nicht im Widerspruch zum Gemini-Ergebnis. Es zeigt den Unterschied zwischen eigenständigem Modell ohne Tools und teurer geschlossener Multi-Agenten-Architektur mit Terminals, Ausführung und Iteration.

LiveOIBench: Offline-Olympiade mit menschlichem Benchmarking

LiveOIBench, dessen dritte Version am 8. Juli 2026 veröffentlicht wurde, enthält 403 von Experten ausgewählte Aufgaben aus 72 Wettbewerben in 14 Informatikolympiaden von 2023 bis 2025. Jede Aufgabe verfügt im Durchschnitt über etwa 60 offizielle Testfälle und eine detaillierte Unteraufgabenrubrik. Die gesamte Bewertung kann offline durchgeführt werden.

Von 34 bewerteten Modellen erreichte GPT-5 81,76. Perzentil, immer noch unter den besten menschlichen Konkurrenten. Das offene Gewicht gpt-oss-120b erreichte etwa das 60. Perzentil. Darüber hinaus zeigte die Analyse der Argumentationsspuren, dass robustere Modelle eine genaue Eingabeanalyse einer übermäßigen chaotischen Suche vorziehen.

DURCHBRUCH 6: BENCHMARK KEINE MASSNAHMEN MEHR NUR AKZEPTIERT / FALSCHE ANTWORT

Neue Probleme + Unteraufgaben + menschliche Perzentile: Eine neue Generation von Benchmarks verfolgt das Aufgabendatum, Teilpunkte, Testabdeckung und den direkten Vergleich mit Elite-Menschen. Ein Hochpass@k auf einem kleinen statischen Satz reicht nicht mehr aus.

Was wirklich in der Geschichte gewonnen hat

1. Vielfalt der Algorithmen, nicht nur der Wörter

Eine Änderung der Temperatur führt häufig zu einem anderen Stil desselben Algorithmus. Echte Diversität bedeutet eine andere Datenstruktur, Invariante, Asymptotik oder Zerlegung des Problems. AlphaCode 2 unterstützte es mit mehreren fein abgestimmten Richtlinien und geänderten Metadaten.

2. Harte Filter vor dem teuren Richter

Zusammenstellung, öffentliche Tests, Grenzwerte, Desinfektionsmittel und statische Prüfungen sind kostengünstiger und zuverlässiger als LLM-Richter. AlphaCode 2 eliminierte somit bereits vor der Endauswahl rund 95 % der Kandidaten.

3. Verhaltensdeduplizierung

Textlich unterschiedlicher Code kann funktional identisch sein. Durch die Gruppierung nach Ausgaben und Diagnoseeingaben wird das Einreichungsbudget vor zehn Kopien desselben Fehlers geschützt.

4. Aktiv generierte Gegenbeispiele

Der beste Test unterscheidet zwischen zwei starken Kandidaten. Der Testgenerator sollte den Informationsgewinn maximieren, nicht die Anzahl der zufälligen Eingaben.

5. Gelehrter Torschütze als letzte Schicht, nicht die einzige Wahrheit

Der Torschütze ist nützlich, wenn die Ausführung noch nicht entschieden hat. Es sollte nicht die Tatsache überschreiben, dass das Programm abgestürzt ist, einen Grenzwert verletzt hat oder einen bekannten Test nicht bestanden hat.

6. Gezielte Reparatur

Wenn wir die fehlerhafte Eingabe kennen, korrigieren wir eine bestimmte Invariante oder Zeile. Die freie Synthese zweier Programme kann Teile zerstören, die bereits korrekt waren.

7. Testzeitberechnung mit Budget

Hundert Kandidaten ohne Selektor sind ein Orakelexperiment. Eine echte Architektur muss die erwartete Anzahl von Punkten pro GPU-Sekunde, die Kompilierung und die zulässige Übermittlung optimieren.

8. Abteilung für Berufe

Der Planer, Implementierer, Testgenerator, Kritiker und Selektor haben unterschiedliche Ziele. Ein Modell kann die Rollen wechseln, aber das Protokoll muss verhindern, dass der Autor nur seine eigene Lösung bestätigt.

Was im Gegenteil immer wieder nicht funktionierte

1. Einhundert nahezu identische Implementierungen

Sie erhöhen pass@k weniger, als die Stichprobenanzahl vermuten lässt. Der korrelierte Fehler überlebt sowohl die Abstimmung als auch die Neubewertung.

2. Optimierung nur für öffentliche Demos

Der Beispieltest erläutert das Format, nicht die vollständige Spezifikation. Das Modell lernt den Patch für die drei Beispiele leicht und verfehlt den allgemeinen Algorithmus.

3. „Code sieht richtig aus“ als Hauptmetrik

Ein Sprachjuror bevorzugt häufig klare Titel, Kommentare und überzeugende Erklärungen. Hidden Checker kümmert sich nicht um Stil.

4. Zufällige Einreichung

Das o1-IOI-Experiment ergab einen Unterschied von fast 60 Punkten zwischen zufälliger und intelligenter Auswahl derselben Population.

5. Selbstreflexion ohne neue Beweise

Die Aufforderung „Überprüfen Sie sich selbst“ führt oft zu einer längeren Rationalisierung. Ein Fix sollte einen neuen Test, eine Rückverfolgung, ein Gegenbeispiel oder einen Konflikt mit einem anderen Kandidaten erhalten.

6. Kombination von Oracle@k mit bereitstellbarer Leistung

Zehntausend Einsendungen über der Goldgrenze bedeuten keine Goldmedaille unter der Grenze von fünfzig Versuchen. Oracle ist ein Generatorpotenzialdiagnosegerät.

7. Benchmark ohne zeitliche Provenienz

Für ein öffentliches Problem benötigen wir das Veröffentlichungsdatum, den Stichtag des Modells, die Verfügbarkeit der Lösung und den Hash der spezifischen Version des Datensatzes.

Wie würde ich daraus HyperFusion-Code erstellen?

Die Geschichte zeigt eine Architektur, die nicht durch Mehrheitsbeschluss einfach ist. Es handelt sich um einen kontrollierten experimentellen Zyklus.

Die ursprüngliche Eröffnungsillustration übernimmt hier eine präzisere Rolle: Sie zeigt die Verschmelzung mehrerer unabhängiger Gedankenströme, nicht die Programmierung selbst.

Phase 1: Problem-Footprint

Der Router schätzt zunächst:

• algorithmische Domäne;
• erwartete Komplexität;
• die Notwendigkeit eines mathematischen Beweises;
• riskante Grenzfälle;
• ob C++, Python oder eine andere Sprache besser geeignet ist;
• wie viel Inferenzbudget der Job verdient.

Der Router soll das Problem nicht sofort lösen. Er soll einen Versuchsplan erstellen.

Phase 2: Wettbewerb für blindes algorithmisches Design

Drei bis fünf verschiedene lokale Modelle erzeugen lediglich Algorithmusdesign, Invarianten und Komplexitätsschätzung. Sie können die Vorschläge anderer nicht sehen. Dies verhindert eine vorzeitige Konvergenz bei der ersten sicheren Idee.

Die Vorschläge werden nach dem aktuellen Prinzip gruppiert:

• gierig;
• dynamische Programmierung;
• Graphtransformation;
• Fluss oder Anpassung;
• mathematische Konstruktion;
• Suche mit Beschneiden;
• randomisiertes oder numerisches Verfahren.

Maximal zwei Vertreter jeder Familie gelangen in die nächste Stufe.

Phase 3: stärkere Umsetzung starker Pläne

Jeder überlebende Plan wird von mindestens zwei Modellen umgesetzt. Dadurch wird der Algorithmusfehler vom Schreibfehler getrennt. Wenn zwei unabhängige Implementierungen desselben Plans unterschiedliche Ergebnisse liefern, erhalten wir einen sehr wertvollen diagnostischen Konflikt.

Phase 4: Testschmiede

Ein eigenständiger Agent erstellt:

• minimale Fälle;
• null und leere Eingabe, falls zulässig;
• Duplikate und identische Werte;
• maximale Größe;
• Werte an Datentypgrenzen;
• Fälle, die die gierige Intuition verletzen;
• Eingaben, bei denen die Kandidaten unterschiedlicher Meinung sind;
• metamorphe Transformation mit einem bekannten Verhältnis der Ergebnisse.

Wenn wir einen langsamen Referenzalgorithmus für kleinenkennen, verwenden wir Differentialtests. Für kleine Fälle vergleichen wir schnelle Kandidaten ausführlich mit roher Gewalt.

Stufe 5: gezielte Reparatur

Der Kandidat erhält lediglich:

• ursprünglicher Plan;
• benutzerdefinierter Code;
• spezifische fehlerhafte Eingabe;
• erwarteter und tatsächlicher Output;
• möglicherweise Diagnose des Desinfektionsmittels oder des Grenzwerts.

Die Aufgabe besteht nicht darin, „eine bessere Lösung zu schreiben“, sondern darin, „die minimale Ursache für diesen Fehler zu finden und ihn zu beheben, ohne die anderen Invarianten zu ändern“.

Stufe 6: Turnierauswahl

Das Ranking der Kandidaten kombiniert harte und weiche Signale:

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

Bestimmte Skalen müssen an den Validierungssatz gebunden sein. Das Testset wird nur für einen einmaligen Bericht verwendet.

Stufe 7: überprüfbare Einreichung

Das System speichert:

• alle algorithmischen Designs;
• Quellmodell und Seed;
• Programme und ihre Hashes;
• Compiler und Flags;
• alle generierten Tests;
• Ausführungsergebnisse;
• Korrekturen und ihre Gründe;
• Endergebnis des Wählers;
• das tatsächliche Ergebnis des versteckten Prüfers.

Ohne diese Spur lässt sich nicht feststellen, ob die Verbesserung durch das Modell, den Testgenerator, die Reparaturschleife oder einfach durch eine größere Anzahl von Versuchen herbeigeführt wurde.

Der ursprüngliche Versuchsplan für LUMI

Ursprünglich entwarf ich Exp05: Behavioral Code Fusion ohne teures Judge-Modell, nur mit lokalen Lösungsmodellen, Compiler, Sanitizern, Brute-Force-Referenzen und Verhaltensvergleich. Der folgende Abschnitt hält diesen Plan fest; direkt danach folgen die Ergebnisse des tatsächlich ausgeführten Experiments.

Datensatz

1. Trainingsset zum Festlegen von Regeln und Maßstäben;
2. Validierungssatz für Budgetauswahl und Stoppregel;
3. gesperrte Testsuite nach Veröffentlichungsdatum;
4. zusätzliches frisches Holdout von LiveCodeBench oder LiveOIBench.

Die Aufteilung muss nach Problemen und deren Ursprung erfolgen, nicht nach einzelnen Programmen. Andernfalls könnten auf beiden Seiten der Spaltung zwei nahezu identische Jobvarianten landen.

Kandidatenkonfiguration

Für jedes Problem:

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

Dies ist absichtlich ein kleineres Budget als eine Million AlphaCode-Beispiele. Ziel ist es, zu messen, wie viel Leistung durch die Vielfalt der Modelle und das Ausführungsfeedback zu einem lokal realistischen Preis erzielt wird.

Ablation

Diese Sequenz zeigt den Cutoff-Wert jeder Ebene genau an. Wenn Variante E keine Leistungssteigerung bringt, erzeugt der Testgenerator keine informativen Eingaben. Wenn G über F nichts hinzufügt, ist kein teurer Scorer erforderlich.

Metriken

Ein Prozent ist nicht genug:

• pass@1 des stärksten Modells;
• Orakel@18;
• ausgewählt@1;
• ausgewählt@3;
• Durchschnittspunktzahl aus Teilaufgaben;
• Oracle-Lücke und Selektor-Wiederherstellungsrate;
• Anzahl der Verhaltenscluster;
• paarweise Fehlerkorrelation zwischen Modellen;
• Anzahl der Kompilierungen und Läufe;
• GPU-Sekunden, CPU-Sekunden und Energie;
• Zeit bis zur ersten akzeptierten Lösung;
• Wie viele Korrekturen haben den ursprünglichen Fehler behoben und wie viele haben einen neuen Fehler verursacht?

Eine Schlüsselauswahlmetrik kann sein:

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

Es gibt an, wie viel von der verfügbaren Oracle-Lücke die Architektur tatsächlich ohne Zugriff auf die versteckte Lösung erhalten konnte.

Was wäre das tatsächliche Ergebnis der Forschung?

Der wertvollste Output wäre nicht die Aussage „drei Modelle sind besser als eines“. Dies ist bereits von pass@k zu erwarten. Folgende Fragen sind von Forschungsinteresse:

1. Ist die Vielfalt der Modellfamilien wertvoller als die gleiche Anzahl an Stichproben des besten Modells?
2. Kann Verhaltensclusterung korrelierte Fehler vorhersagen?
3. Welche Art von Autotest erhöht die Selektorwiederherstellung am meisten?
4. Wann hilft eine Reparatur und wann tut ein ordentliches Fundament weh?
5. Kann die Unsicherheit anhand der Meinungsverschiedenheiten der Kandidaten besser eingeschätzt werden als anhand der eigenen Zuversicht des Modells?
6. Wie verändert sich die optimale Architektur mit Speicher- und Zeitbudget?
7. Brauchen wir einen großen Richter oder werden die meisten Streitigkeiten durch Hinrichtung entschieden?

Vom Entwurf zu Daten: Ich habe das Experiment tatsächlich auf LUMI ausgeführt

Auf dem finnischen Supercomputer LUMI baute ich ein lokales Panel aus Open-Weight-Modellen und eine sichere Ausführungs-Sandbox. Die geschichtete Stichprobe umfasste 40 seit März 2025 veröffentlichte LiveCodeBench-Aufgaben: 13 leichte, 14 mittlere und 13 schwere, davon 26 von AtCoder und 14 von LeetCode. gpt-oss-120b, Qwen2.5-72B, GLM-4.7-flash und Mistral-Small-3.2-24B liefen lokal; Kimi K2.7-code und Kimi K3 dienten per API nur als Referenz für die Obergrenze.

Ein hartes Signal muss Kandidaten unterscheiden

Den Code lediglich auszuführen reichte nicht. Kandidaten, die alle öffentlichen Tests bestanden, lieferten dort dieselben korrekten Ausgaben; der Selektor blieb blind. Bei ungefähr jeder fünften Aufgabe scheiterte ein solcher „Public Passer“ später an einem versteckten Test. Im kontrollierten Piloten maß ich den Wert der diskriminierenden Schicht durch eine saubere Trennung von Auswahltests und unabhängigem Scoring. In einem Produktivsystem müssen generierte Gegenbeispiele und Differential Testing diese Rolle übernehmen.

Das wichtigste LUMI-Ergebnis: Das wertvollste Artefakt ist möglicherweise nicht ein weiteres Programm, sondern der eine Test, der eine richtige Lösung von Code trennt, der nur auf allen öffentlichen Beispielen richtig aussah.

Das gemeinsame Oracle blieb bei 35/40; ein einzelner starker Coder löste bereits genau diese 35 Aufgaben. Das praktische Rezept lautete daher nicht „möglichst viele Modellfamilien“, sondern ein starkes Modell × mehr Samples × diskriminierende Testauswahl.

Die fünf schwersten Aufgaben, vier Orchestrierungen

Nur mit dem lokalen gpt-oss-120b ließen sich 2 der 5 Aufgaben knacken, die kein Modell des Basispanels gelöst hatte. Eine davon fiel ausschließlich im Proof-pilot-Modus, obwohl die anderen drei Verfahren bei null blieben. Das Modell rief die Werkzeuge nicht selbst auf (tool_calls = 0); der Harness steuerte Ausführung und konkrete Rückmeldung.

Kimi K3 zeigte außerdem eine methodische Falle: Mit einem Limit von 12.000 Token erreichte es nur 17/40, weil 35 % der Antworten mitten im Denken endeten. Nach der Erhöhung auf 32.000 Token stieg das Ergebnis auf 31/40. Ohne Kontrolllauf wäre ein Fehler des Harness als Modellschwäche erschienen.

Inferenzgeschwindigkeit als neue Dimension von KI-Anwendungen

Im Kurs Fast LLM Inference with Cerebras testete ich das andere Extrem: Was ändert sich, wenn das Warten auf ein großes Modell beinahe verschwindet? Der Cerebras-Modellkatalog nennt für gpt-oss-120b ungefähr 3.000 Ausgabetoken pro Sekunde. Das ist eine Anbieterangabe; meine konkreten Messungen waren:

Ein ähnlicher Billard-Prompt dauerte in einem Lauf mit GPT-4.1 mini ungefähr 39 Sekunden. Das ist kein sauberer Hardware-Benchmark, denn Modelle, Infrastruktur und Netzwerkpfade waren unterschiedlich. Der Unterschied im Arbeitsgefühl ist dennoch deutlich.

Zwei Sekunden bis zum ersten spielbaren Prototyp

Die erste Tetris-Ausgabe war tatsächlich spielbar: fallende Tetrominos, Bewegung, Drehung, schneller Fall, gelöschte Reihen und Punktestand. Das bedeutet nicht „fertiges Produkt in zwei Sekunden“, sondern eine funktionierende Grundlage, die sofort getestet und verbessert werden kann.

Das Schachspiel war deutlich gröber: Brett, Figurensteuerung, grundlegende Zugprüfung und eine einfache Antwort des Computers. Es ist weder regelvollständig noch ein Ersatz für eine bewährte Schachengine. Von einem leeren Prompt in etwa zwei Sekunden zu einem interaktiven Spiel zu gelangen, bleibt dennoch bemerkenswert.

Mehr als nur ein schnellerer Chat

Bei Hunderten oder Tausenden Token pro Sekunde passen mehrere Kandidaten, Tests, Reparaturen und eine Auswahl in dieselbe Interaktion. Für HyperAdvisor und HyperFusion ergeben sich drei Modi:

Die beste Kennzahl ist daher nicht tokens/s allein, sondern: Wie schnell und zu welchen Kosten erzeugt das System ein verifiziert richtiges Ergebnis? Geschwindigkeit liefert mehr Versuche; Ausführung und diskriminierende Tests liefern den Grund, dem ausgewählten Ergebnis zu vertrauen.

Parallelzweig: Wettbewerbscode ist keine gewöhnliche Softwareentwicklung

HumanEval, Codeforces, IOI und ICPC verfügen über eine klare Spezifikation, saubere Eingabe, erwartete Ausgabe und ein relativ isoliertes Programm. Das eigentliche Endlager ist eine andere Welt. Die Eingabe kann unvollständig sein, die Tests sind veraltet und für eine ordnungsgemäße Lösung kann es erforderlich sein, Hunderte von Dateien zu verstehen.

Daher würde ich SWE-Bench und Agenten, die GitHub-Probleme beheben, nicht in der Hauptzeitleiste mischen. Es verdient einen separaten Artikel. Die Prinzipien sind verwandt, aber die Rolle der Tests ist eine andere: Im Wettbewerb definieren die Tests die Wahrheit, in der realen Entwicklung können sie selbst Teil des Problems sein.

Was zum Mitnehmen

Die Geschichte der wettbewerbsfähigen KI-Programmierung ist keine einfache Geschichte immer größerer Modelle. Es ist eine Geschichte immer besserer Organisation von Versuchen:

1. HumanEval zeigte einen großen Unterschied zwischen pass@1 und pass@100.
2. AlphaCode hat die Generierung in eine Bevölkerungssuche verwandelt.
3. AlphaCode 2 kombinierte verschiedene Richtlinienmodelle, Ausführung, Verhaltensclustering und erlernte Scorer.
4. o1-IOI hat gemessen, dass die Auswahl derselben Population etwa 57 Punkte wert war.
5. LiveCodeBench hat neue Daten und mehr Funktionen als nur das Generieren hinzugefügt.
6. Gemini am ICPC nutzte parallele Agenten, Terminals und iterative Reparatur.
7. LiveCodeBench Pro und LiveOIBench haben gezeigt, dass das Elitealgorithmus-Denken immer noch nicht gelöst ist.
8. Mein LUMI-Experiment gewann mit diskriminierenden Tests 80–83 % der verfügbaren Oracle-Lücke zurück.
9. Vier Orchestrierungen desselben lokalen Modells knackten zwei der fünf schwersten Aufgaben.
10. Cerebras zeigte eine zweite Achse: Generierung, Prüfung und Reparatur können in eine Interaktion passen.

Letztes Prinzip: Das intelligenteste Programmiersystem ist nicht dasjenige, das in einem Monolog am längsten denkt. Es handelt sich um ein System, das unabhängige Hypothesen erstellen, Experimente entwerfen, eindeutige Beweise sammeln, spezifische Fehler beheben und ein begrenztes Einreichungsbudget verwalten kann.

Die Programmierung kann das ideale Labor für HyperFusion sein. Hier haben wir etwas, was bei offenen geisteswissenschaftlichen Fragen oft fehlt: billiges Feedback aus der Realität. Wenn wir es gut nutzen, brauchen wir nicht ein Modell, um perfekt zu sein. Wir brauchen das gesamte System, um aus jedem fehlgeschlagenen Lauf lernen zu können.

Primärquellen und Reproduktionsmaterialien

• DeepCoder: Lernen, Programme zu schreiben
• Bewertung großer Sprachmodelle, die auf Code, Codex und HumanEval trainiert wurden
• Messung der Coding-Challenge-Kompetenz mit APPS
• Codegenerierung auf Wettbewerbsebene mit AlphaCode
• DeepMind: Wettbewerbsfähige Programmierung mit AlphaCode
• CodeContests-Datensatz und Ausführungstools
• AlphaCode 2 Technischer Bericht
• OpenAI: Mit LLMs schlussfolgern lernen, Abschnitt über IOI und Codeforces
• LiveCodeBench
• LiveCodeBench-Repository und Evaluierungs-Harness
• LiveCodeBench Pro
• LiveOIBench
• Gemini 2.5 Deep Think beim ICPC World Finals 2025
• Veröffentlichte Gemini-Programme von ICPC 2025
• Originalbeitrag von Andrej Karpathy zum Vibe-Coding
• Collins Wort des Jahres 2025: Vibe-Codierung
• Stack Overflow Developer Survey 2025: KI und Vibe-Codierung
• METER: Messung der Produktivität erfahrener Open-Source-Entwickler mit AI
• Fast LLM Inference with Cerebras, Kurs von DeepLearning.AI
• Cerebras-Inferenzkatalog und angegebene Geschwindigkeit von gpt-oss-120b
• Cerebras Cloud