Welches KI-Modell schreibt den besten Code?

Warum Code der schwerste Benchmark zum Faken ist

Code ist unnachgiebig auf eine Weise, die die meisten Aufgaben für Sprachmodelle nicht sind. Prosa kann ungefähr stimmen und trotzdem nützlich sein; Code ist entweder korrekt oder er crasht. Ein Modell, das eine Funktion schreibt, die plausibel wirkt, aber Edge Cases falsch behandelt, produziert eine Testsuite, die grün leuchtet, und einen Produktionsvorfall, der rot leuchtet. Es gibt keine Version dieser Arbeit, bei der Teilpunkte zählen.

Damit ist Coding der Benchmark, der am schwersten zu manipulieren ist. Ein Anbieter kann einen Leaderboard-Score auf einem kuratierten Testset veröffentlichen, aber jeder Entwickler mit API-Zugang kann das Modell innerhalb von Minuten gegen einen echten Bug aus dem eigenen Backlog testen. Der Community-Konsens darüber, welches Modell den besten Code schreibt, ist offiziellen Leaderboards meist Monate voraus — und kommt zuverlässig zum gleichen Ergebnis. Beobachte, zu welchen Tools die besten Engineers tatsächlich greifen, nicht was Marketingseiten behaupten.

Die Arbeit hat sich auch verändert. Vor zwei Jahren bedeutete Coding-Unterstützung Single-Turn-Vervollständigungen: einen Kommentar tippen, einen Vorschlag annehmen, weitermachen. Heute erstreckt sich derselbe Workflow über agentische Loops, die Dateien lesen, Tests ausführen, Code bearbeiten und ohne Aufsicht iterieren. Das Modell muss nicht nur gut darin sein, Code zu schreiben, sondern auch darin zu entscheiden, was es schreibt, nach Fehlern zu erholen und aufzuhören, wenn es fertig ist. Andere Fähigkeiten, andere Spitzenreiter, andere Preisprofile.

Fünf Dinge trennen die Modelle, die es wert sind, von denen, die es nicht sind: rohe Korrektheit, Tool-Use-Disziplin, Long-Context-Verständnis, Sprachabdeckung und die Gesamtkosten einer Aufgabe von Anfang bis Ende. Das vollständige Bild zählt mehr als jede einzelne Dimension.

Das Tempo des Fortschritts beeinflusst auch die Bauweise. Ein Coding-Stack, der einen einzigen Modellnamen fest verdrahtet, veraltet schnell. Die besten Teams behandeln das Modell als austauschbare Komponente hinter ihrer Agent-Schicht und führen jedes Quartal einen erneuten Benchmark durch. Ein neues Release, das auf dem eigenen Backlog zehn Prozent mehr Aufgaben löst, ist mehr wert als jedes Feature, das man im gleichen Quartal bauen würde — und der einzige Weg, es zu entdecken, ist, weiterzutesten.

Die fünf Dimensionen, die entscheiden, welches Modell gewinnt

Das sind die Achsen, nach denen unsere Scorecard jedes Modell bewertet, das in der Nähe einer echten Codebasis eingesetzt wird. Die Gewichtung hängt davon ab, ob das Modell in einer IDE, einem Agent-Loop oder einem Batch-Job läuft — aber jedes Modell muss auf allen fünf eine Mindestschwelle überschreiten.

1. 01 — Korrektheit beim ersten Versuch

   Läuft der Code — und tut er das Richtige?

   Generierung, die kompiliert, aber einen Null-Wert falsch behandelt, ist schlimmer als gar keine Generierung — der Engineer liest sie, vertraut ihr und deployt sie. Der zuverlässigste Prädiktor für die Eignung eines Modells für Coding-Arbeit ist der Anteil der Aufgaben, den es vollständig und ohne zweiten Durchlauf korrekt löst.

2. 02 — Tool-Use und Agent-Loops

   Kann es einen Workflow steuern, nicht nur eine Frage beantworten?

   Moderne Coding-Agents rufen Tools auf: eine Datei lesen, eine Codebasis durchsuchen, einen Test ausführen, einen Patch anwenden. Das Modell muss wissen, wann es welches Tool aufruft, wann es aufhört und wie es sich erholt, wenn das Tool Unsinn zurückliefert. Für Chat trainierte Modelle scheitern hier lautlos; für agentische Loops trainierte Modelle arbeiten durch.

3. 03 — Long-Context-Verständnis

   Kann es ein ganzes Repository im Kopf behalten?

   Ein Kontext von einer Million Tokens ist bedeutungslos, wenn das Modell nur die ersten und letzten Seiten beachtet. Teste Long-Context-Performance mit Retrieval-Probes auf mehreren Tiefen in eigenen Dateien. In der Praxis profitiert Coding mehr von Aufmerksamkeitstiefe als von reiner Kontextgröße.

4. 04 — Sprach- und Framework-Abdeckung

   Kennt es deinen Stack — oder nur Python und JavaScript?

   Alle Frontier-Modelle beherrschen die gängigsten Sprachen. Die Qualität sinkt deutlich, sobald man zu Rust, Zig, Elixir, Clojure oder einem darauf aufbauenden DSL wechselt. Die Framework-Abdeckung ist noch ungleichmäßiger: Ein Modell, das React souverän beherrscht, kann bei Phoenix LiveView ins Straucheln geraten. Benchmark immer auf dem eigenen Stack.

5. 05 — Kosten pro gelöster Aufgabe

   Was zahlst du wirklich dafür, die Änderung zu shippen?

   Agent-Loops multiplizieren Kosten schnell. Ein Modell, das pro Token doppelt so viel kostet, die Aufgabe aber in einem Versuch statt in drei löst, ist die günstigere Wahl. Messe immer End-to-End: jeden Read, jeden Retry, jeden Tool-Aufruf — und die Zeit, die der Engineer für die Review des Ergebnisses aufwendet.

Tokonomix Top-5-Picks für Code heute

Was folgt, ist das, was wir einem Entwickler diese Woche tatsächlich geben würden. Jedes Modell steht aus einem Grund auf der Liste, der es davon ausschließt, auf jeder Liste zu stehen — es gibt kein Modell, das gleichzeitig bei Inline-Vervollständigungen, agentischen Refactorings, repo-weiten Reviews und Self-Hosted-Inference gewinnt. Teams, die heute das Meiste aus Coding-Assistenten herausholen, betreiben zwei davon parallel: ein schnelles Modell bei jedem Tastendruck und ein schwereres Modell, das der Agent aufruft, wenn das erste nicht weiterkommt.

Ausgabepreis pro Million Tokens

Beim Coding dominiert der Output-Preis, weil der Assistent den Großteil seiner Tokens damit verbringt, Code zu schreiben, statt deinen Prompt zu lesen. Das Diagramm zeigt den aktuellen Listenpreis für jedes der fünf Modelle oben.

Feldleitfaden: welches Modell für welche Aufgabe

Die folgende Zuordnung ist die, die wir verwenden würden, um ein Team zu beraten, das von Grund auf neu beginnt. Betrachte sie als Ausgangspunkt, nicht als Urteil — ein kleiner Benchmark auf dem eigenen Backlog schlägt jede allgemeine Empfehlung.

Benchmark auf dem eigenen Backlog, bevor du dich festlegst

Ein solcher Leitfaden kann nur über Durchschnitte nachdenken — und Durchschnitte shippen dein nächstes Release nicht. Zieh zehn bis zwanzig abgeschlossene Tickets aus deinem letzten Sprint heraus — die unordentlichen, nicht die einfachen — und spiele sie gegen zwei oder drei Kandidaten durch. Verwende für jeden denselben Agent-Loop und denselben System-Prompt. Ein Nachmittag reicht.

Dann lies die Diffs nebeneinander. Lief die Änderung beim ersten Versuch? Hat das Modell die richtigen Tools aufgerufen? Hat es die Teile der Codebasis verstanden, die es berühren, aber nicht modifizieren sollte? Blieb es innerhalb der Framework-Konventionen? Was hat jeder Versuch inklusive Retries von Anfang bis Ende gekostet? Wähle den Gewinner anhand der eigenen Daten, auch wenn auf jedem Leaderboard ein anderes Modell vorn liegt.