25. Februar 2026 · Reviewer: Joseph Kisler & Claude Sonnet 4.6
Wir haben 7 führende LLMs mit identischem Prompt in einem realen Produktiv-Projekt getestet. Die Aufgabe: Einen kompletten CRUD-Endpoint mit Model, Schema, Service, Router, Migration und Tests implementieren – beim ersten Versuch, ohne Nachbesserung. Die Ergebnisse zeigen massive Abweichungen zu gängigen Benchmarks wie SWE-Bench.
Implementiere einen vollständigen FastAPI-Endpoint für ein Favoriten-System in einem produktiven Reise-SaaS-Projekt (PostgreSQL, 435 Reisen, 74 Felder pro Datensatz):
Jedes LLM erhält Zugriff auf die vollständige Codebasis eines bestehenden Produktiv-Projekts und muss sich an vorhandene Patterns halten (JWT-Auth, Service-Layer, ORM-Conventions).
| # | Modell | Beschreibung | Note |
|---|---|---|---|
| 1 | Claude Opus 4.5 | Kompaktester Code, gleiche Qualität wie Sonnet | 9.4 |
| 1 | Claude Sonnet 4.6 | Ausführlichste Migration + Dokumentation | 9.4 |
| 2 | GPT-5.2 Codex | Solide Projekt-Integration, alle Patterns korrekt | 8.8 |
| 3 | GLM-5 | 17 Tests, Auth-Tests, lauffähig | 7.8 |
| 4 | Gemini 2.5 Pro | Bestes Schema-Design, aber nicht lauffähig | 7.7 |
| 5 | MiniMax-M2.5 | Funktionale Grundstruktur, aber schwere Mängel | 4.4 |
| 6 | DeepSeek V3.2 | Kein Code erstellt, nur Doku die Implementierung vortäuscht | 0.5 |
Gegenüberstellung der offiziellen SWE-Bench Verified Scores (Feb. 2026, Bash-Only) mit unserer Praxis-Bewertung. SWE-Bench misst automatisierte Bug-Fixes in Open-Source-Repos. Unser Test bewertet vollständige Feature-Implementierung in einem bestehenden Produktiv-Projekt.
Quellen: swebench.com · Simon Willison (Feb. 2026) · Epoch AI · SEAL / Scale AI
Erkenntnis: MiniMax-M2.5 (SWE-Bench 75.8%) und DeepSeek V3.2 (70.8%) schneiden bei Benchmarks gut ab, versagen aber im Praxis-Test komplett (4.4 bzw. 0.5/10). Benchmarks ≠ reale Projekt-Arbeit.
Unsere Testergebnisse zeigen massive Abweichungen zwischen SWE-Bench-Scores und realer Leistung. Die Ursachen sind systemisch – und betreffen alle gängigen Code-Benchmarks.
| Modell | SWE-Bench | Praxis-Test | Differenz (norm.) |
|---|---|---|---|
| MiniMax-M2.5 | 75.8% | 4.4 / 10 | −31.8 |
| DeepSeek V3.2 | 70.8% | 0.5 / 10 | −65.8 |
| Gemini 2.5 Pro | 67.2% | 7.7 / 10 | +9.8 |
| Claude Opus 4.5 | 76.8% | 9.4 / 10 | +17.2 |
| GPT-5.2 Codex | 72.8% | 8.8 / 10 | +15.2 |
SWE-Bench testet: „Kann das Modell einen isolierten Bug in einem Open-Source-Repo fixen?“
Unser Test: „Kann das Modell ein komplettes Feature in ein bestehendes Produktiv-Projekt integrieren?“
Das erfordert Model, Schema, Service, Router, Migration, Tests – und bestehende Patterns einhalten, ohne etwas kaputt zu machen.
Die SWE-Bench-Repos (Django, Astropy, Matplotlib) sind öffentliche Trainingsdaten. Die Modelle haben sie hundertfach gesehen und erkennen Patterns wie „Django-Bug fixt man so“ – ohne echtes Verständnis. Unser Test nutzte ein privates Projekt mit eigenen Patterns, das kein Modell je gesehen hat.
SWE-Bench gibt dem Modell exakt die Datei(en), die geändert werden müssen. In der Praxis muss das Modell die Projektstruktur selbst verstehen, bestehende Patterns erkennen und einhalten, und wissen was es nicht anfassen darf. DeepSeek V3.2 schafft 70.8% bei isolierten Patches – aber produziert null Zeilen Code bei einer echten Aufgabe.
Die SWE-Bench-Scores nutzen „High Reasoning“ – das Modell darf länger nachdenken und mehrere Versuche machen. In der Praxis bekommt das Modell einen Prompt, keinen iterativen Dialog. Der Code muss beim ersten Mal stimmen. Es gibt kein „probier nochmal anders“.
SWE-Bench misst binär: Bug gefixt oder nicht. Es misst nicht: Code-Qualität, Type Hints, Security (SQL Injection, CORS), Architektur, Seiteneffekte oder Test-Qualität. MiniMax lieferte funktionierenden Code – aber mit SQL-Injection-Lücken, fehlenden Type Hints und kaputten Tests. Bei SWE-Bench wäre das als „resolved“ durchgegangen.
Modell-Anbieter optimieren gezielt auf Benchmarks, weil Marketing „Nr. 1 auf SWE-Bench“ verkaufen will. Das führt zu Training auf Benchmark-ähnlichen Daten, Spezial-Scaffolding für Benchmark-Formate und Cherry-Picking der besten Konfiguration (Temperatur, Reasoning-Budget, Retry-Logik).
Claude und GPT-5.2 zeigen
Konsistenz zwischen Benchmark und Realität – dort steckt echtes Code-Verständnis dahinter.
MiniMax und DeepSeek haben gelernt,
Benchmarks zu bestehen – nicht Code zu schreiben.
Der einzige zuverlässige Benchmark ist: Gib dem Modell eine echte Aufgabe in einem echten Projekt und schau was rauskommt.
Trotz Milliarden-Investitionen in KI existiert kein standardisiertes, unabhängiges Prüfverfahren für Code-Generierung. Die Gründe sind strukturell.
Jeder Anbieter wählt die Benchmarks, bei denen er gut abschneidet. Anthropic zeigt Arena-Scores, OpenAI zeigt MMLU, Google zeigt MATH. Eine einheitliche Norm würde Verlierer produzieren – und die haben kein Interesse daran.
DIN/ISO funktioniert, weil sich Stahl oder Beton nicht alle 3 Monate fundamental ändern. LLMs ändern sich alle paar Wochen. Bis ein Norm-Gremium einen Standard verabschiedet hat, sind die getesteten Modelle veraltet.
Es gibt keinen „TÜV für KI“. Die Benchmark-Ersteller sind entweder Akademiker (gute Absicht, kein Enforcement), Unternehmen mit eigenen Geschäftsinteressen (Scale AI, Chatbot Arena), oder die Modell-Anbieter selbst – offensichtlicher Interessenkonflikt.
Man kann messen: „Besteht der Test?“ Aber nicht: Ist die Architektur sinnvoll? Ist der Code wartbar? Passt er ins Projekt? Erzeugt er Sicherheitslücken? Das erfordert menschliches Urteil – teuer, langsam, subjektiv. Genau das macht eine Normung fast unmöglich.
Der EU AI Act schreibt ab 2026 Transparenzpflichten vor, aber keine standardisierten Code-Benchmarks. Fokus liegt auf Risiko-Klassifizierung, nicht auf Leistungsmessung. Bisher die einzige regulatorische Initiative – und sie reicht nicht aus.
| # | Modell | Empfehlung | Note | Fazit |
|---|---|---|---|---|
| 🏆 | Claude (Opus / Sonnet) | Programmierung | 9.4 | Beste Code-Qualität, Projekt-Integration, Tests, saubere Architektur. Klare Nr. 1. |
| 🔧 | GPT-5.2 Codex | Integration / Refactoring | 8.8 | Korrekte Patterns, Migration, CI-tauglicher Code. Solide Projekt-Integration. |
| ⚠️ | Alle anderen | Spielerei | < 8 | GLM-5, Gemini, MiniMax, DeepSeek – nur für explorative Experimente, nie ohne Review im Produktiv-Code einsetzen. |
Die folgenden Empfehlungen basieren auf einem konkreten Praxis-Test in einem bestehenden FastAPI-/SQLAlchemy-Projekt (Feb. 2026) mit echter Auth, Migrations und Tests. Sie richten sich an Backend- und Full-Stack-Developer, die LLMs für produktiven Code in realen Projekten einsetzen wollen.
| Modell | Empfehlung | Kurzbegründung |
|---|---|---|
| Claude Opus 4.5 / Sonnet 4.6 | Haupt-Coder im Projekt | Beste Kombination aus Code-Qualität, Projekt-Integration, Tests und Migrations. |
| GPT-5.2 Codex | Integrator & Refactoring | Versteht bestehende Architekturen gut, schreibt saubere Migrations und fügt sich korrekt ins Projekt ein. |
| GLM-5 | Tests, günstige Tasks | Viele gute Tests, Auth-Checks und solide Logik, aber weniger ausgereifte Architektur/Migrations. |
| Gemini 2.5 / 3 | Ideen & Schema-Design | Oft sehr gutes Design (Schemas, HTTP-Semantik, Eager Loading), aber Integration und Lauffähigkeit unzuverlässig. Nur mit Review. |
| MiniMax-M2.5 | Nur Experimente | Funktionale Grundstruktur, aber Sicherheits- und Konsistenzprobleme (Fake-Auth, destruktive Befehle, lügende Docstrings). |
| DeepSeek V3.2 | Nicht verwenden | Kein Code erzeugt, sondern nur Doku, die eine nicht existierende Implementierung vortäuscht. |
Hinweis: Diese Empfehlungen gelten für den Testzeitpunkt Februar 2026 und die getesteten Modell-Versionen. Die Ergebnisse stammen aus einem einzelnen, aber realistischen Projekt-Setup und ersetzen keine formale, standardisierte Benchmark-Suite – sie zeigen jedoch klar, dass echte Projekt-Tasks deutlich aussagekräftiger sind als reine Benchmark-Scores. [Turing: Real-World LLM Benchmarks]