# FrontierCode Diamond: 13,4 % übernahmefähige Patches bei 50 schweren Aufgaben (Juni 2026) > FrontierCode-Ergebnisse vom Juni 2026: 13,4 % bei Diamonds 50 schweren Aufgaben gegenüber 51,8 % auf Extended und die Prüfung eines KI-generierten Patches. Source: https://ailoot.ai/blog/de/frontiercode-benchmark-mergeable-ai-code/ Canonical: https://ailoot.ai/blog/de/frontiercode-benchmark-mergeable-ai-code/ Language: de Publisher: Ailoot (https://ailoot.ai/) Translation: guide-173 Revision: sha256-48754851b50e563f8b59fa02e3e5e62039edda30f8ec56abd74d135d76ba79e7
Das Wichtigste Am 8. Juni 2026 veröffentlichte Cognition FrontierCode, einen Benchmark, der misst, ob ein Maintainer eines echten Open-Source-Repositorys zustimmen würde, von KI generierten Code in sein Projekt zu übernehmen. Das Hauptergebnis: Selbst Claude Opus 4.8, das beste Modell der Branche, besteht nur 13.4 % der 50 schwierigsten Aufgaben. Ältere Benchmarks wie HumanEval und SWE-bench maßen „Funktioniert der Code?“; der neue misst „Würde der Maintainer diesen PR übernehmen?“ Das verändert den Maßstab für alle, die KI-generierten Code in die Produktion bringen.
Zusätzliche Materialien zur Konfiguration von Tools finden Sie in der [Ailoot-Dokumentation](https://ailoot.ai/docs/).
[Ailoot-Anleitungen](https://ailoot.ai/docs/)
## Was ist FrontierCode, und warum ist es wichtig?
Das Wichtigste FrontierCode ist ein Benchmark für die Codequalität von KI, den Cognition am 8. Juni 2026 veröffentlicht hat. Er bewertet, ob ein Patch die maintainerorientierten Übernahmekriterien des Benchmarks erfüllt. Das ist ein definierter Benchmarkausgang, keine allgemeine Produktionsreifequote sämtlichen KI-Codes. Mehr als 20 Maintainer großer Open-Source-Projekte haben jeweils über 40 Stunden pro Aufgabe investiert, um Szenarien zusammenzustellen, die nicht nur Korrektheit, sondern auch Stil, Sicherheit und Tests erfordern.
Cognition ist das Unternehmen hinter Devin (dem ersten autonomen KI-Entwickler, März 2024) und Windsurf (im Juli 2025 übernommen). Außerdem entwickeln sie ihre eigene Modellreihe SWE-1.x. Der Benchmark wurde im öffentlichen Blog unter `cognition.com/blog/frontier-code`veröffentlicht. Die entscheidende Veränderung betrifft nicht neue Zahlen. Sie betrifft **den Maßstab, mit dem Dinge jetzt gemessen werden**. Der Benchmark hat drei Schwierigkeitsstufen: **Extended** (150 Aufgaben, der vollständige Satz), **Main** (die 100 schwierigsten, einschließlich Diamond) und **Diamond** (50 knallharte Aufgaben). Cognition ließ Diamond bewusst „weitgehend unausgeschöpft“ – selbst das beste Modell löst weniger als 15 %. Damit soll der Benchmark noch ein Jahr Entwicklungsspielraum bieten und verhindern, dass er wie HumanEval innerhalb eines Monats ausgeschöpft wird. ## Was FrontierCode misst: „Würde der Maintainer diesen PR übernehmen?“
Das Wichtigste FrontierCode bewertet jede Lösung anhand von 6 Kriterien: ob der Patch die Aufgabe löst, keinen anderen Code beschädigt, Build- und Lint-Prüfungen besteht, gültige Tests enthält, den vorgegebenen Umfang einhält und lesbaren Code aufweist. Damit ein Patch als übernahmefähig gilt, muss er alle 6 Kriterien erfüllen. Scheitert er auch nur an einem, wird der PR nicht übernommen. Damit verlagert sich die Bewertung von automatisierten Tests zur Entscheidung eines echten Maintainers.
Die sechs Bewertungskriterien (aus Cognitions offiziellem Blog): 1. **Funktionale Korrektheit** — Löst der Patch die Aufgabe? 2. **Regressionssicherheit** — Vermeidet er, bestehenden Code zu beschädigen? 3. **Technische Sauberkeit** — Besteht er Build-, Lint- und Stilprüfungen? 4. **Testkorrektheit** — Sind die vom Agenten geschriebenen Tests gültig (Tests, die mit beliebigem Code bestehen, zählen nicht)? 5. **Umfang** — Vermeidet der Patch Änderungen an nicht angeforderten Dateien? 6. **Codequalität** — Folgt der Code den Konventionen des Projekts, und ist er lesbar? Damit ein Patch als übernahmefähig gilt, muss er **alle sechs Kriterien** erfüllen. Scheitert er auch nur an einem, wird er nicht übernommen. Das ist der wesentliche Perspektivwechsel. „Korrektheit ist jetzt Grundvoraussetzung“, wie Cognition es ausdrückt. Früher fragten Benchmarks: „Hat der Code die Tests bestanden?“ Jetzt fragen sie: „Würde ein echter Tech Lead diesen Code ins Projekt übernehmen?“ Cognition führte drei neue Bewertungsverfahren ein: - **Reverse-Classical**: Ein von einem Agenten geschriebener Test muss bei einer fehlerhaften Codeversion fehlschlagen. Andernfalls ist der Test eine Täuschung. - **Code Scope**: Ein automatisierter Prüfer stellt sicher, dass ein Patch innerhalb der für die Aufgabe vereinbarten Dateien und Zeilenzahl bleibt. - **Adaptive Classical Grading**: Das LLM-Tool „mutagent“ passt strenge Tests an gültige Lösungsvarianten an. ## Warum funktionieren die alten Benchmarks nicht mehr?
Das Wichtigste HumanEval (Codex, 2021) und SWE-bench prüfen, ob Code automatisierte Tests besteht. Sie erkennen nicht, wenn ein Test zwar besteht, aber niemand den PR akzeptieren wird: Der Code ist unsauber, beschädigt benachbarte Module oder überschreitet den Aufgabenbereich. Im März 2026 bewertete eine unabhängige Studie 296 von KI generierte PRs aus SWE-bench Verified mit 4 echten Maintainers: Die Entscheidungen der Maintainer lagen im Durchschnitt 24 Prozentpunkte unter den Bewertungen des automatisierten Prüfers. Das bedeutet, dass etwa die Hälfte der „erfolgreichen“ PRs nicht in ein echtes Repository übernommen wird.
KI-Agenten hatten HumanEval bereits bis 2024 mit Bravour bestanden. Bei SWE-bench Verified ist es ähnlich: Im August 2025 räumte OpenAI öffentlich das Kontaminationsproblem ein (die Modelle hatten den Datensatz während des Trainings „gesehen“). Benchmarks verloren ihre Fähigkeit, zwischen Spitzenmodellen zu unterscheiden. Die entscheidende Studie, die den alten Maßstab erschütterte, erschien im März 2026. Was sie untersuchten: - Sie wählten 4 aktive Maintainer aus 3 Repositories aus (scikit-learn, Sphinx, pytest). - Sie ließen sie 296 von KI generierte PRs aus SWE-bench Verified bewerten – alle diese PRs bestanden automatisierte Tests. - Sie verglichen die Entscheidungen der Maintainer mit denen des automatisierten Prüfers. Anders gesagt: Der Benchmark meldet „bestanden“, während der Maintainer sagt „wird nicht übernommen“ – und das passiert in durchschnittlich einem Viertel der Fälle. Die 3 häufigsten Ablehnungsgründe, vom weniger bis zum schwerwiegendsten: 1. **Codequalität** — Der Code entspricht nicht dem Stil des Repositorys. 2. **Beschädigt anderen Code** — Benachbarter Code wird beeinträchtigt. 3. **Zentrale Funktionalität fehlt** — Die Aufgabe wird nicht vollständig gelöst, obwohl der Test erfolgreich ist. FrontierCode formalisiert genau dieses Problem. Cognition nahm diese Idee auf und erweiterte sie zu einem vollständigen Benchmark mit mehr als 20 statt 4 Maintainers. Ein weiterer Sargnagel ist eine Studie vom Dezember 2025 zur Sicherheit von KI-generierten Patches. Darin waren 61 % der Lösungen von SWE-Agent mit Claude 4 Sonnet funktional korrekt, aber nur 10.5 % davon sicher. Der Code besteht den Test, und trotzdem enthält jeder zweite Patch eine Sicherheitslücke. Das ist in SWE-bench-Benchmarks überhaupt nicht zu erkennen – sie messen Sicherheit nicht. FrontierCode versucht zumindest, das über die Kriterien „technische Sauberkeit“ und Codequalität zu erfassen. ## Wie die Modelle abschneiden: Opus 4.8 bei 13.4 %, GPT-5.5 bei 6.3 %
Das Wichtigste Cognition veröffentlichte eine Rangliste von 12 Modellen in drei Teilmengen. Claude Opus 4.8 von Anthropic führt bei Diamond mit 13.4 %. Es folgen GPT-5.5 mit 6.3 %, Claude Opus 4.7 mit 5.2 % und Googles Gemini 3.1 Pro mit 4.7 %. Das beste Open-Code-Modell ist Kimi K2.6 von Moonshot mit 3.8 %. Cognitions eigenes Modell SWE-1.6 liegt mit 2.5 % im unteren Tabellenbereich. Das ist ein wichtiges Argument gegen Vorwürfe der Eigenwerbung.
| Modell | Diamond (50) | Main (100) | Extended (150) | |---------------------------------|--------------|------------|----------------| | **Claude Opus 4.8** (Anthropic) | **13.4%** | 34.3% | 51.8% | | GPT-5.5 (OpenAI) | 6.3% | \- | \- | | Claude Opus 4.7 (Anthropic) | 5.2% | \- | \- | | Gemini 3.1 Pro (Google) | 4.7% | \- | \- | | GPT-5.4-mini (OpenAI) | 4.6% | \- | \- | | Kimi K2.6 (bestes Open-Code-Modell) | 3.8% | \- | \- | | Claude Sonnet 4.6 | 3.5% | \- | \- | | **SWE-1.6** (Cognition) | **2.5%** | \- | \- | | MiniMax M2.7 | 2.4% | \- | \- | | MiniMax M2.5 | 1.1% | \- | \- | | Kimi K2.5 | 1.0% | \- | \- | | Gemini 3.1 Flash Lite | 0.7% | \- | \- | Was aus der Tabelle hervorsticht: - **Ein klarer Spitzenreiter.** Opus 4.8 von Anthropic liegt ungefähr doppelt so weit vorn wie der nächste Konkurrent. Der Abstand, der auf SWE-bench schwer zu erkennen war, ist bei FrontierCode deutlich sichtbar. - **Open-Source-Modelle haben noch nicht aufgeholt.** Kimi K2.6 – das beste Open-Code-Modell – erzielt bei Diamond 3.8 %. Das ist 3–4-mal weniger als Opus 4.8. Cognition veröffentlichte kein vollständiges Kimi-K2.6-Raster für Main und Extended, daher gibt es noch keinen Vergleich über den vollständigen Satz. - **Cognition setzte sein eigenes Modell ehrlich** in den unteren Tabellenbereich. Die Diamond-Teilmenge wurde bewusst „unausgeschöpft“ gelassen. Cognition hat für die kommenden Jahre einen Sicherheitsspielraum eingebaut. Wenn frühere Benchmarks innerhalb von 12–18 Monaten ausgeschöpft waren, ist FrontierCode auf eine höhere Obergrenze ausgelegt. ## Was bedeutet „13 % übernahmefähig“ für Vibe-Coder, die Claude Code verwenden?
Das Wichtigste Beim berichteten Opus-4.8-Lauf auf Diamonds 50 ausgewählten schweren Aufgaben erfüllten 13,4 % der Patches die Übernahmekriterien des Benchmarks und 86,6 % nicht. Das belegt weder, dass alle abgelehnten Patches richtig aussahen, noch dieselbe Quote bei gewöhnlicher Projektarbeit. Beim Vibe-Coding heißt das: Bei schwierigen Änderungen reicht es nicht, einen grünen Test zu sehen und den Code zu pushen. Einfache Änderungen in einem neuen Projekt sind eine andere Sache; damit kommt KI gut zurecht. Die Grenze zwischen „wann pushen und wann von Hand nachbessern“ hat sich verschoben.
Zunächst eine wichtige Einordnung: FrontierCodes **Diamond**-Set ist bewusst knallhart. Bei gewöhnlichen Aufgaben in einem frischen Startup-Projekt ohne vierzig abhängige Module schneidet ein KI-Agent merklich besser ab. Dasselbe Opus 4.8 erreicht bei Extended (150 Aufgaben, der vollständige Satz) 51.8 % übernahmefähige Lösungen. Das ergibt ein völlig anderes Bild. Die 51,8 % gelten für das Extended-Set dieses Benchmarks mit 150 Aufgaben. Der Wert liegt über Diamond, doch keiner schätzt die Übernahmefähigkeit sämtlicher Modellpatches in deinen Aufgaben. Fehlende Main- oder Extended-Werte anderer Modelle dürfen nicht durch vermutete Leistung ergänzt werden. Was das für Vibe-Coder bedeutet, die Code in die Produktion bringen: - **Ein grüner Test bedeutet nicht mehr „bereit zur Übernahme“.** Von der KI selbst geschriebene Tests können untauglich sein – sie bestehen mit beliebigem Code. FrontierCode misst dies direkt mit Reverse-Classical: Wenn ein Test bei einer fehlerhaften Version nicht fehlschlägt, zählt er nicht. - **Repository-Stil und Konventionen sind wichtig.** Wenn ein Projekt ein etabliertes Muster hat und die KI ihm nicht folgt, akzeptiert ein echter Mitwirkender die Änderung nicht. Bei Einzelprojekten ohne Regeln ist das kein großes Problem. Im Team ist es Problem Nummer eins. - **Tests lösen keine Sicherheitsprobleme.** Denken Sie an die Zahl oben: Nur 10.5 % der Patches sind sicher, obwohl 61 % korrekt sind. Das muss separat mit Tools geprüft werden, die Tokens, `.env`-Dateien und Standardpasswörter erkennen. - **Über die Aufgabe hinauszugehen, ist ein typischer KI-Fehler.** Man bittet sie, eine Autorisierungsfunktion zu reparieren, und erhält einen Patch, der auch die interne Ebene und die Protokollierung umgeschrieben hat. Das ist eines der 6 Kriterien von FrontierCode.
[Ailoot-Anleitungen](https://ailoot.ai/docs/)
## Welche 6 Fehlerkategorien treten bei KI bei schwierigen Aufgaben auf?
Das Wichtigste Die 6 FrontierCode-Kriterien entsprechen 6 Arten von Fehlern, die KI-Agenten regelmäßig machen. Es handelt sich um vorhersehbare Muster schwacher Ergebnisse. Prüft man einen beliebigen Patch von Claude oder Codex anhand dieser 6 Kriterien, wird ein echter Tech Lead ihn ablehnen, wenn auch nur ein Punkt nicht erfüllt ist. Um Code zuverlässig in die Produktion zu bringen, müssen Sie diese 6 Kriterien vor dem Mergen selbst prüfen.
Gehen wir jedes Kriterium in einfachen Worten durch: **1. Funktionale Korrektheit — löst der Patch die Aufgabe?** Das grundlegendste Kriterium. KI schreibt oft Code, der **wie eine Lösung aussieht**, aber das falsche Problem löst. Ich bitte sie, „eine Lesebestätigung für die Nachricht hinzuzufügen“, und erhalte eine `markAsRead`-Funktion, die aber nicht mit der Chat-Komponente selbst verbunden wurde. Der Funktionstest besteht. Die Geschäftsaufgabe ist nicht gelöst. **2. Regressionssicherheit — vermeidet der Patch, benachbarten Code zu beschädigen?** KI ändert ein Modul, und plötzlich funktioniert ein anderes nicht mehr. Der häufigste Fall: Ein KI-Agent ändert eine Funktionssignatur und vergisst, dass sie an 17 anderen Stellen aufgerufen wird. Das ist bei SWE-bench nicht sichtbar – dort werden nur Tests für eine Datei ausgeführt. Bei FrontierCode führen sie **die vollständige Testsuite des Repositorys** aus. **3. Technische Sauberkeit — besteht der Patch Build-, Lint- und Stilprüfungen?** KI kann Code erzeugen, der lokal kompiliert, aber in CI scheitert: ein fehlender Import, Tabs statt Leerzeichen, zwei nachgestellte Leerzeichen oder ein Fehler in `eslint.config.js`. In einem laufenden Projekt ist Stil keine Marotte, sondern eine Teamregel. **4. Testkorrektheit — sind die von der KI geschriebenen Tests gültig?** Das kniffligste Kriterium. KI schreibt einen Test, der besteht. Aber er **besteht mit beliebigem Code, auch fehlerhaftem**. Das habe ich oft erlebt: Der Test prüft „Ist das Skript abgestürzt?“, aber nicht „Hat es das richtige Ergebnis zurückgegeben?“ FrontierCodes Reverse-Classical erkennt genau diesen Fall. **5. Umfang — vermeidet der Patch Änderungen an nicht zusammenhängenden Dateien?** Ich bitte die KI, eine Funktion zu reparieren, und erhalte einen Patch für 12 Dateien, darunter Dateien ohne Bezug zur Aufgabe. Genau diese „Eigeninitiative“ der KI bringt ein Produktionsprojekt durcheinander, weil sie Dinge ändert, um die ich sie nicht gebeten habe. Dieses Kriterium ist bei FrontierCode ein hartes Ausschlusskriterium. **6. Codequalität — folgt der Code den Konventionen des Repositorys?** KI schreibt ihre eigene Funktion „von Grund auf“, statt vorhandene Hilfsfunktionen in `lib/` zu verwenden. Oder sie benennt Variablen anders als im Projekt üblich. Oder sie platziert Logik in der falschen Architekturschicht. Aus Sicht des Tests funktioniert alles. Aus Sicht des Tech Leads wird der Code nicht übernommen. ## Wie Sie KI-Code vor dem Push prüfen: 5 Schritte
Das Wichtigste Eine 5-Schritte-Checkliste deckt die 6 FrontierCode-Kriterien und eine Sicherheitsprüfung ab. Gehen Sie sie vor jeder Veröffentlichung eines Patches von Claude oder Codex durch. Die Liste ist kurz, und jeder Schritt dauert nur wenige Minuten. Der Aufwand lohnt sich: Investieren Sie 10 Minuten in die Checkliste, statt 4 Stunden damit, ein Produktionsprojekt mit git rewind zurückzurollen und die Datenbank aus einem Backup wiederherzustellen.
1. ### Führen Sie die vollständige Testsuite aus, nicht nur Tests zur Änderung KI ändert oft Code außerhalb des Aufgabenbereichs. Das Problem zeigt sich dann in benachbarten Tests. Ich führe die vollständige Testsuite aus (mit dem einzelnen Befehl `npm test`, ohne Pfad), nicht nur Tests für eine bestimmte Datei. Bei großen Projekten ist es praktisch, dies parallel mit einem git worktree zu tun (siehe [Git worktree in Claude Code](https://ailoot.ai/blog/de/claude-code-git-worktree/)). 2. ### Führen Sie Lint-, Stil- und Typprüfungen aus Drei Befehle der Reihe nach: `eslint .`, `prettier --check .`, `tsc --noEmit`. Ein KI-Agent übersieht leicht sowohl Tabs als auch ein zusätzliches nachgestelltes Leerzeichen. Wenn das Projekt strenge Prüfungen hat, führen Sie diese vor der Veröffentlichung lokal aus. 3. ### Prüfen Sie den Test selbst Die wichtigste der 5 Prüfungen. Ich baue einen kleinen Fehler in den Code ein (ändere `return true` zu `return false`). Der Test sollte fehlschlagen. Wenn der Test **nicht fehlschlägt**, hat die KI ihn nur zum Schein geschrieben, und er ist nutzlos. Ich lösche den Test und bitte die KI, ihn neu zu schreiben, mit der zwingenden Bedingung: Der Test muss bei der fehlerhaften Version fehlschlagen. 4. ### Prüfen Sie, welche Dateien die KI geändert hat Der Befehl `git diff --stat` zeigt, welche Dateien geändert wurden und wie viele Zeilen. Wenn die KI auf „Repariere das Kontaktformular“ 12 Dateien angefasst hat, ist sie über den Aufgabenbereich hinausgegangen. Ich mache die zusätzlichen Änderungen mit einem einzigen Befehl für die Datei rückgängig. 5. ### Führen Sie eine Sicherheitsprüfung mit einer fertigen Skill aus Tests erkennen keine SQL-Injections oder fest codierten Passwörter. Ich verwende eine fertige Sicherheits-Skill für Claude Code (siehe 754 fertige Sicherheits-Skills). Suchen Sie das Projekt mindestens manuell nach den Wörtern „password“, „secret“ und „key“ ab und prüfen Sie, ob `.env.example` vollständig ist. Alle 5 Schritte decken 5 der 6 FrontierCode-Kriterien ab (1–5). Das sechste Kriterium – Codequalität – wird automatisch durch Linting und eine manuelle Prüfung abgedeckt. ## Was verbessert tatsächlich die Chancen auf übernahmefähigen Code?
Das Wichtigste FrontierCode beschreibt das Problem. Die Lösung liegt in der Methodik der KI-Arbeit; ein Modellwechsel macht hier praktisch keinen Unterschied. Den Unterschied machen drei Praktiken: Projektregeln, eine Projektkarte und Context Engineering. Ohne sie erzeugt selbst Opus 4.8 plausiblen Unsinn. Sie geben dem Agenten klarere Grenzen. Auch schwierige Änderungen benötigen vor dem Merge weiterhin Repositoryprüfungen und Review.
Ein KI-Agent in einem unvorbereiteten Projekt sieht **nur die Datei, die Sie für ihn geöffnet haben**. Er kennt weder Ihre Entscheidungshistorie noch Ihre Konventionen und hat keinen Überblick über Ihre Module. Bei einfachen Änderungen ist das kein großes Problem. Bei schwierigen Änderungen ist fehlender Projektkontext ein zu behandelndes Risiko. Die Benchmarkquote von 13,4 % isoliert die Kontextqualität nicht als Ursache. Was Sie tun müssen, um aus diesen 13 % etwas zu machen, das Sie wirklich in die Produktion bringen können: **1. Projektregeln — damit die KI Ihre Überlegungen statt des Durchschnitts aus dem Internet reproduziert.** Das ist eine Sammlung Ihrer fertigen Lösungen, Gewohnheiten und erlernten Regeln in einem Format, das der KI-Agent bei jeder Anfrage liest. Ab 30+ Regeln hört die KI auf, den „Branchendurchschnitt“ zu erfinden, und beginnt, Vorschläge in Ihrem Stil zu machen. Dem Überschreiten des Aufgabenbereichs können Sie mit einer einzigen Zeile in den Regeln entgegenwirken: „Ändere keine Dateien, die nicht ausdrücklich in der Anfrage genannt sind.“ **2. Eine Projektkarte — ein Ordner, der das Projekt beschreibt.** Dort legen Sie Produkte, Zielgruppe, Wirtschaftlichkeit, Kennzahlen und Setups ab. Vor jeder Anfrage liest der KI-Agent das Inhaltsverzeichnis und versteht, **an welchem Teil des Geschäfts er arbeitet**. Dadurch werden zwei der oben genannten Ablehnungsgründe automatisch berücksichtigt: Stil und Beschädigung anderen Codes. **3. Context Engineering — steuern, was die KI vor der Anfrage sieht.** Es geht nicht darum, „wie man einen Prompt formuliert“, sondern darum, „was VOR dem Prompt in das Kontextfenster kommt“. CLAUDE.md, Voraussetzungen und gezielte Links zu Dateien. Das begegnet Fehlern bei der funktionalen Korrektheit und Codequalität. Nutzen Sie diese Kombination als Vorbereitung auf die Prüfungen, nicht als Nachweis für bereits bestandene fünf Kriterien. Prüfen Sie Verhalten, Regressionen, Tests, Umfang und Codequalität am tatsächlichen Patch vor der Annahme. Eine zusätzliche Ebene sind Review-Agenten: - **Cursor Bugbot** — prüft jeden PR. Laut Cursor verarbeitet das Tool rund 2 Millionen PRs im Monat. - **Verschachtelte Subagenten in Claude Code v2.1.172** — ein Agent schreibt den Code, ein zweiter prüft ihn, und ein dritter führt Tests aus. Das ist dieselbe Idee wie bei FrontierCode: die Rollen von „Autor“ und „Tech Lead“ zu trennen. Siehe auch: [Vibe-Coding-Sicherheit](https://ailoot.ai/blog/de/vibe-coding-security/), [So konfigurieren Sie Claude Code, damit es Ihr Projekt nachts nicht kaputt macht](https://ailoot.ai/blog/de/claude-code-safe-overnight-setup/) und Context Engineering als Konzept.
### Quellen - [Cognition – Introducing FrontierCode (8. Juni 2026)](https://cognition.com/blog/frontier-code) - [Cursor Bugbot – Code-Review-Agent](https://cursor.com/bugbot)
Zusätzliche Materialien zur Arbeit mit Tools finden Sie in der [Ailoot-Dokumentation](https://ailoot.ai/docs/).
[Ailoot-Anleitungen](https://ailoot.ai/docs/)
[Zu Ailoot](https://ailoot.ai/)
## Fragen und Antworten ### Bedeuten 13,4 %, dass nur dieser Anteil sämtlichen KI-Codes produktionsreif ist? Nein. Das ist die berichtete Übernahmequote von Opus 4.8 bei FrontierCode Diamonds 50 ausgewählten schweren Aufgaben. Dieselbe Tabelle nennt 51,8 % auf dem Extended-Set mit 150 Aufgaben. Keine Quote misst sämtlichen KI-generierten Code. ### Warum reicht ein bestandener Test nicht für einen Merge? Der Benchmark prüft auch Regressionen, Build und Stil, Fehlererkennung durch Tests, Umfang und Codequalität. Prüfen Sie den tatsächlichen Diff und Repository-Abnahmekriterien. Ein grüner Test allein bestätigt nicht sämtliche Bedingungen. ## Ailoot · Das Unternehmen und sein Projektportfolio Ailoot baut auf bewährte Betriebserfahrung, einen großen Kundenstamm, stabilen Service und kontinuierliche KPI-Kontrolle. Das Unternehmen und sein Projektportfolio: Millionen von Kunden; monatliche Umsätze in Milliardenhöhe. Ailoot nutzt diese Betriebserfahrung für den API-Zugang zu KI-Funktionen in Kundenprodukten, Agenten, Anwendungen und Automatisierungen.