HumanEval ist tot: Code-Benchmarks für LLMs verstehen im Jahr 2026

#Warum HumanEval tot ist

HumanEval ist der am häufigsten zitierte Code-Benchmark in der Geschichte der LLMs. Er wurde 2021 von OpenAI veröffentlicht und diente vier Jahre lang als Referenz. Das Problem: 2026 ist er gesättigt. Die besten Open-Weight-Code-Modelle erreichen dort 96 bis 98 % bei „pass@1“, das heißt, sie lösen nahezu alle Aufgaben beim ersten Versuch. Wenn alle 20 von 20 Punkten erreichen, lässt sich anhand der Note keine Rangfolge mehr bilden.

Ein gesättigter Benchmark misst keinen Fortschritt mehr: Er misst vor allem Rauschen. Ein Unterschied zwischen 96 % und 98 % bei zwei Modellen kann auf drei von hundert Aufgaben zurückgehen, die oft mehrdeutig oder schlecht formuliert sind. Das ist kein Unterschied in der Kompetenz, sondern liegt innerhalb der Fehlermarge. Im Jahr 2026 weiterhin ein Code-LLM anhand seines HumanEval-Scores auszuwählen, ist so, als würde man zwei Langstreckenläufer anhand eines Zehn-Meter-Sprints gegeneinander bewerten.

HumanEval ist nicht etwa schlecht geworden. Vielmehr haben die Modelle das übertroffen, was der Benchmark messen kann. Er bleibt als Regressionstest nützlich – ein Modell, das auf 70 % abfällt, hat ein echtes Problem –, eignet sich aber nicht mehr dazu, die Spitzenmodelle voneinander zu unterscheiden.

#Was HumanEval tatsächlich misst

Um zu verstehen, warum HumanEval an seine Messgrenzen stößt, muss man sich ansehen, was der Benchmark konkret testet. Er enthält 164 kleine Programmieraufgaben in Python. Jede gibt eine Funktionssignatur und einen Docstring vor, der das erwartete Verhalten beschreibt; das Modell muss den Funktionskörper schreiben, der anschließend anhand einer Reihe verborgener Unit-Tests überprüft wird.

Format

164 eigenständige Python-Funktionen zum Vervollständigen, jeweils mit einem Docstring und Unit-Tests.

Art der Aufgaben

Elementare Algorithmik: Listen und Zeichenketten verarbeiten, dazu etwas Mathematik. Jedes Problem lässt sich in einer einzigen Funktion ohne externe Abhängigkeiten lösen.

Was es testet

Die Fähigkeit, eine kurze und eindeutige Spezifikation in korrekten Code umzusetzen. Eine Schulaufgabe, keine Aufgabe aus der Praxis.

Was hier nicht getestet wird

In einem bestehenden Repository navigieren, mehrere Dateien lesen, bereits geschriebenen Code verstehen, einen echten Bug beheben, Tests schreiben, Abhängigkeiten verwalten. Mit anderen Worten: die eigentliche Arbeit.

Hier liegt der Unterschied. Eine einzelne Funktion anhand einer klaren Aufgabenstellung zu schreiben, ist eine Übung, die die Modelle von 2026 beherrschen. Die tatsächliche Arbeit eines Entwicklers – oder eines lokalen Codeassistenten, der mit Ihrem Editor verbunden ist – besteht darin, ein bestehendes Repository mit mehreren Tausend Zeilen zu ändern. Genau das versuchen die neuen Benchmarks zu messen.

#SWE-bench Verified erklärt

SWE-bench ist der Benchmark, der HumanEval als seriöse Referenz abgelöst hat. Die Idee ist grundlegend anders: Statt vereinfachter Übungsaufgaben verwendet er echte GitHub-„Issues“ aus beliebten Open-Source-Python-Projekten (Django, scikit-learn, Flask, sympy ...). Das Modell erhält das vollständige Repository und die Beschreibung des zu behebenden Bugs. Es muss einen Patch – einen Diff – erzeugen, der das Problem tatsächlich löst.

Die Korrektur wird weder von einem Menschen noch von einem anderen Modell bewertet: Der Patch wird auf das Repository angewendet, anschließend wird die Testsuite des Projekts ausgeführt. Wenn die zuvor fehlgeschlagenen Tests nun bestehen und die zuvor erfolgreichen Tests weiterhin bestehen, ist das Problem gelöst. Das ist ein objektives Kriterium, das der tatsächlichen Arbeit nahekommt.

SWE-bench Verified

500 manuell geprüfte Probleme. Der aktuelle Standard, um Modelle bei der Behebung realer Fehler zu vergleichen.

SWE-bench Lite

300 einfachere Probleme, deren Auswertung weniger kostet. Nützlich für schnelle Tests, aber weniger geeignet, Leistungsunterschiede sichtbar zu machen.

SWE-bench full

Mehr als 2000 Aufgaben, von denen einige fehlerhaft sind. Niedrigere, verrauschte Scores; für Vergleiche vermeiden.

Die Größenordnungen sagen viel über die Schwierigkeit aus. Während HumanEval bei 98 % an seine Grenze stößt, erreichen die besten agentischen Modelle auf SWE-bench Verified 60 bis 70 %, und gute lokal installierbare Modelle mit offenen Gewichten liegen eher zwischen 40 und 55 %. Endlich gibt es Spielraum für Verbesserungen – und damit auch die Möglichkeit, Unterschiede zwischen den Modellen festzustellen.

#LiveCodeBench und die Kontamination

SWE-bench misst die Behebung von Bugs in echtem Code. LiveCodeBench adressiert ein anderes Problem: die Kontamination. Das Prinzip steckt im Namen – „live“. Der Benchmark sammelt laufend neue Aufgaben aus Programmierwettbewerben (LeetCode, AtCoder, Codeforces) und versieht sie mit Zeitstempeln. So lässt sich ein Modell ausschließlich anhand von Aufgaben bewerten, die NACH seinem Trainingsdatum veröffentlicht wurden.

Das ist grundlegend. Wenn ein Problem vor dem Training eines Modells bereits im Internet existierte, hat das Modell die Lösung möglicherweise während des Trainings gesehen. Sein Ergebnis spiegelt dann keine Schlussfolgerungen wider, sondern das Abrufen auswendig gelernter Inhalte. Durch die Filterung nach Datum stellt LiveCodeBench sicher, dass das Modell Probleme löst, die es zuvor gar nicht gesehen haben konnte.

Art

Aufgaben aus der Wettbewerbsprogrammierung, mit Zeitstempeln versehen und laufend erneuert.

Zeitliche Aufteilung

Man wählt einen Zeitraum nach dem Training des getesteten Modells. So ist kein Datenleck in die Trainingsdaten möglich.

Was es misst

Reines algorithmisches Schlussfolgern bei neuartigen Problemen – ähnlich dem Ansatz von HumanEval, aber ohne Sättigung oder Kontamination.

Hinweis zur Interpretation

Immer den angegebenen Zeitraum prüfen. Ein LiveCodeBench-Score für einen Zeitraum vor dem Erscheinen des Modells ist nichts wert.

LiveCodeBench und SWE-bench ergänzen sich, statt miteinander zu konkurrieren. Der erste Benchmark misst das algorithmische Schlussfolgern anhand neuer Probleme; der zweite die Fähigkeit, in einem echten Repository zu arbeiten. Ein gutes Code-LLM muss bei beiden überzeugen – ein Modell, das in der Algorithmik stark ist, sich aber in einem Projekt nicht zurechtfindet, ist im Alltag ein schlechter Assistent.

#Das Problem der Kontamination, verständlich erklärt

Kontamination ist DER Grund, warum man den angegebenen Scores misstrauen sollte. LLMs werden mit riesigen Teilen des Webs trainiert, einschließlich GitHub. Wenn die Aufgaben eines Benchmarks und ihre Lösungen online zu finden sind, landen sie wahrscheinlich in den Trainingsdaten. Das Modell löst das Problem nicht mehr: Es gibt es auswendig wieder.

Ein Warnsignal: Ein Modell übertrifft auf einem alten, statischen Benchmark alle anderen deutlich, erzielt auf einem „Live“-Benchmark oder einem gerade veröffentlichten Benchmark jedoch nur gewöhnliche Ergebnisse. Der Unterschied zwischen beiden ist ein gutes Maß dafür, welchen Anteil das Auswendiglernen am Ergebnis hat. Genau dafür wurde LiveCodeBench entwickelt: um diesen Anteil sichtbar zu machen.

#Die Scores eines lokalen Modells lesen

Wenn Sie sich die Modellkarte eines Open-Weight-Modells ansehen (auf Hugging Face oder in der Ankündigung des Herausgebers), werden die Ergebnisse bei Code-Benchmarks fast immer hervorgehoben. Die folgende Orientierungshilfe zeigt Ihnen, worauf Sie achten müssen, um sich nicht täuschen zu lassen.

1. 01
   Identifizieren Sie die genaue Version des Benchmarks

   « SWE-bench » allein bedeutet nichts. Suchen Sie nach « Verified ». Für LiveCodeBench suchen Sie die Version (v5, v6...) und das Zeitfenster. Ohne diese Angaben ist die Zahl nicht vergleichbar mit anderen.
2. 02
   Prüfen Sie den pass@k-Wert

   Ein pass@1-Wert und ein pass@10-Wert lassen sich niemals miteinander vergleichen. Die Anbieter zeigen manchmal den günstigeren der beiden Werte. Wenn genauere Angaben fehlen, gehen Sie für Ihren tatsächlichen Einsatz vom ungünstigsten Fall aus: Im Alltag zählt die erste Antwort.
3. 03
   Identifizieren Sie das Agenten-Setup für SWE-bench

   Ein SWE-bench-Score ist untrennbar mit dem Agenten verbunden, der ihn erzielt hat. „52 % mit OpenHands“ ist nicht „52 % mit Aider“. Wenn der Anbieter den Agenten nicht angibt, ist die Zahl nur eingeschränkt aussagekräftig.
4. 04
   Seien Sie skeptisch gegenüber selbst veröffentlichten Benchmark-Ergebnissen

   Die Zahlen in der Modellkarte stammen vom Herausgeber, der ein Interesse daran hat, gut dazustehen. Suchen Sie nach einer unabhängigen Reproduktion der Ergebnisse (öffentliche Rangliste, Artikel eines Dritten). Ein nie reproduzierter Score bleibt eine Werbeaussage.
5. 05
   Vergleichen Sie mindestens zwei Benchmarks

   Ein Modell, das überall stark abschneidet, ist ein gutes Zeichen; ein Modell, das nur bei einem einzigen Benchmark glänzt und bei den anderen untergeht, deutet auf Spezialisierung hin — oder auf Kontamination.

#Welche Benchmarks für die Auswahl eines Code-LLMs relevant sind

Je nachdem, was Sie von Ihrem lokalen Assistenten erwarten, sind unterschiedliche Benchmarks relevant. So können Sie sie je nach Anwendungsfall priorisieren.

Agentischer Assistent (Aider, Cline, Continue)

SWE-bench Verified hat Vorrang. Dieser Benchmark kommt „mein Repository selbstständig bearbeiten“ am nächsten. Hier zeigt sich der tatsächliche Nutzen eines Agenten.

Autovervollständigung und kleine Funktionen

LiveCodeBench und ergänzend HumanEval als zusätzliche Absicherung. Für die Codevervollständigung während des Tippens zählt algorithmisches Denken mehr als die Navigation im Projekt.

Code von Grund auf generieren

LiveCodeBench (Schlussfolgern bei neuen Aufgaben), kombiniert mit einem Benchmark für mehrere Programmiersprachen, wenn Sie nicht nur in Python programmieren — HumanEval und SWE-bench sind stark auf Python ausgerichtet.

Codeüberprüfung und Fehlererkennung

Durch öffentliche Benchmarks weniger gut abgedeckt. SWE-bench bleibt der beste Näherungsindikator, aber ein eigener Test mit Ihren eigenen Diffs ist hier unerlässlich.

#Fallstricke vermeiden

Verschiedene k-Werte vergleichen

pass@1 mit pass@10 vergleichen: der häufigste Fehler. Der zweite Wert lässt den Score zwangsläufig höher ausfallen. Vor einer Schlussfolgerung immer denselben Wert für k verwenden.

Die Quantisierung vergessen

Die veröffentlichten Ergebnisse werden mit voller Präzision (BF16/FP16) gemessen. Lokal werden Sie Modelle in Q4_K_M oder Q5_K_M betreiben, wobei etwas Qualität verloren geht. Ein Modell, das in FP16 bei SWE-bench 50 % erreicht, wird nach der Quantisierung etwas schlechter abschneiden.

Den Benchmark für das eigentliche Ziel halten

Ein Modell, das gezielt DARAUF optimiert wurde, einen Benchmark zu bestehen („Benchmark-Hacking“), kann bei echtem Code enttäuschen. Der Score ist ein Anhaltspunkt, keine Garantie.

Das Datum des Benchmarks ignorieren

Ein LiveCodeBench-Score für einen Zeitraum vor dem Training des Modells ist wahrscheinlich kontaminiert. Immer prüfen, ob der Zeitraum nach dem Training liegt.

Modell und Agent verwechseln

„Dieses Modell erreicht 55 % bei SWE-bench“ bedeutet oft eigentlich „dieses Modell IN genau diesem Agenten“. Wechseln Sie den Agenten, und der Wert verändert sich.

#Weiterführende Informationen

Wenn Sie wissen, wie Sie die Benchmarks einordnen können, besteht der nächste logische Schritt darin, ein Modell auszuwählen, anschließend zu installieren und an Ihrem eigenen Code zu testen:

Bestes lokales LLM zum Coden 2026

Unser Vergleich selbst hostbarer Modelle zum Programmieren (Devstral, Qwen3-Coder und Alternativen), mit Scores, dem benötigten VRAM und einer Empfehlung, welches Modell Sie je nach GPU wählen sollten.

Quantisierung wählen (Q4, Q5, Q8, FP16)

Um zu verstehen, wie viel Qualität ein Modell beim Wechsel zu Q4_K_M verliert – die Differenz zwischen dem angegebenen Score und dem Modell, das Sie tatsächlich betreiben werden.

Ollama installieren (Windows, macOS, Linux)

Die Voraussetzung, um ein Code-Modell lokal auf Port 11434 zu testen und es in wenigen Minuten mit Ihrem Editor zu verbinden.