FrontierCode Diamond: 13,4 % slučitelných patchů na 50 těžkých úlohách (červen 2026)

Další materiály o konfiguraci nástrojů najdete v dokumentaci Ailoot.

Co je FrontierCode a proč na něm záleží?#

Cognition stojí za Devinem (prvním autonomním AI inženýrem, březen 2024) a Windsurfem (koupeným v červenci 2025). Vyvíjí také vlastní řadu modelů SWE-1.x. Benchmark byl zveřejněn na veřejném blogu na adrese cognition.com/blog/frontier-code.

Klíčová změna nespočívá v nových číslech. Jde o měřítko, kterým se nyní věci posuzují.

Benchmark má tři úrovně obtížnosti: Extended (150 úloh, úplná sada), Main (100 nejtěžších úloh, včetně Diamond) a Diamond (50 mimořádně náročných úloh). Cognition záměrně ponechala Diamond „z velké části nenasycený“ — i nejlepší model vyřeší méně než 15 %. Cílem je dát benchmarku roční rezervu a zabránit tomu, aby se nasytil za měsíc, jako se to stalo HumanEval.

Jak FrontierCode hodnotí, zda je změna kódu vhodná ke sloučení?#

Šest hodnoticích os (podle oficiálního blogu Cognition):

1. Správnost chování — řeší patch úlohu?
2. Bezpečnost z hlediska regresí — nepoškozuje existující kód?
3. Technická čistota — projde sestavením, kontrolami lint a stylu?
4. Správnost testů — jsou testy napsané agentem platné (testy, které projdou při jakémkoli kódu, se nepočítají)?
5. Rozsah — nedotýká se patch souborů, které nebyly vyžádány?
6. Kvalita kódu — dodržuje kód konvence projektu a je čitelný?

Aby byl patch považován za vhodný ke sloučení, musí projít všemi šesti osami. Stačí selhat v jediné a nebude sloučen.

To je hlavní změna pohledu. „Správnost je nyní samozřejmost,“ jak říká Cognition. Dříve se benchmarky ptaly: „Prošel kód testy?“ Nyní se ptají: „Přijal by tento kód do projektu skutečný technický vedoucí?“

Cognition zavedla tři nové techniky hodnocení:

• Reverse-Classical: test napsaný agentem musí selhat na nefunkční verzi kódu. Jinak je test podvodný.
• Code Scope: automatická kontrola ověřuje, že patch zůstává v mezích souborů a počtu řádků dohodnutých pro úlohu.
• Adaptive Classical Grading: nástroj LLM „mutagent“ přizpůsobuje přísné testy platným variantám řešení.

Proč už staré benchmarky nefungují?#

AI agenti už do roku 2024 dosahovali na HumanEval skvělých výsledků. SWE-bench Verified je na tom podobně: v srpnu 2025 OpenAI veřejně přiznala problém kontaminace (modely během trénování „viděly“ datovou sadu). Benchmarky ztratily schopnost rozlišovat mezi nejlepšími modely.

Klíčová studie, která zpochybnila staré měřítko, vyšla v březnu 2026.

Co udělali:

• Vybrali 4 aktivní maintainer y ze 3 repozitářů (scikit-learn, Sphinx, pytest).
• Nechali je vyhodnotit 296 PR vytvořených AI ze SWE-bench Verified — všechny tyto PR prošly automatizovanými testy.
• Porovnali rozhodnutí maintainerů s rozhodnutími automatického evaluátoru.

Jinými slovy, benchmark říká „prošlo“, zatímco maintainer říká „nesloučí se“ — a v průměru se to stává ve čtvrtině případů. Tři hlavní důvody zamítnutí, od nejméně po nejzávažnější:

1. Kvalita kódu — neodpovídá stylu repozitáře.
2. Rozbíjí jiný kód — poškozuje sousední kód.
3. Selhání klíčové funkčnosti — neřeší úlohu úplně, přestože test svítí zeleně.

FrontierCode formalizuje přesně tento problém. Cognition převzala tuto myšlenku a rozšířila ji na celý benchmark s více než 20 maintainer y namísto 4.

Další hřebíček do rakve představuje studie z prosince 2025 o bezpečnosti patchů generovaných AI.

V ní bylo 61 % řešení SWE-Agent s Claude 4 Sonnet funkčně správných, ale bezpečných bylo pouze 10,5 %.

Kód projde testem, a přesto každý druhý patch přináší bezpečnostní díru. Na benchmarcích SWE-bench to vůbec nevidíte — bezpečnost neměří. FrontierCode se ji alespoň snaží zachytit pomocí os „technická čistota“ a „kvalita kódu“.

Jak si modely vedou: Opus 4.8 má 13,4 %, GPT-5.5 má 6,3 %#

Co z tabulky vyčnívá:

• Jeden jasný lídr. Opus 4.8 od Anthropic vede přibližně dvojnásobně před nejbližším konkurentem. Rozdíl, kterého si na SWE-bench bylo těžké všimnout, je na FrontierCode zřetelně vidět.
• Open modely zatím nedohnaly náskok. Kimi K2.6 — nejlepší open-code model — dosahuje v Diamond 3,8 %. To je 3–4krát méně než u Opus 4.8. Cognition nezveřejnila úplnou tabulku Kimi K2.6 pro Main a Extended, takže zatím není k dispozici srovnání celé sady.
• Cognition poctivě umístila vlastní model do dolní části tabulky.

Podmnožina Diamond byla záměrně ponechána „nenasycená“. Cognition do ní zabudovala bezpečnostní rezervu na několik dalších let. Pokud se předchozí benchmarky nasytily za 12–18 měsíců, FrontierCode má vyšší strop.

Co znamená „13 % vhodných ke sloučení“ pro vibe codera používajícího Claude Code?#

Nejprve důležité zasazení do kontextu: sada FrontierCode Diamond je záměrně mimořádně náročná. U běžných úloh v novém startupovém projektu bez čtyřiceti závislých modulů si AI agent vede znatelně lépe. Stejný Opus 4.8 dosahuje na Extended (150 úloh, úplná sada) 51,8 % patchů vhodných ke sloučení. To je úplně jiný obrázek.

Výsledek 51,8 % patří 150 úlohám Extended daného benchmarku. Je vyšší než Diamond, ani číslo ale neodhaduje slučitelnost patchů všech modelů na vašich úkolech. Chybějící skóre Main či Extended jiných modelů neopravňuje k odhadnutí jejich výkonu.

Co to znamená pro vibe codera, který nasazuje do produkce:

• Zelený test už neznamená „připraveno ke sloučení“. Testy napsané samotnou AI mohou být bezcenné — projdou při jakémkoli kódu. FrontierCode to přímo měří pomocí Reverse-Classical: pokud test neselže na nefunkční verzi, nepočítá se.
• Na stylu a konvencích repozitáře záleží. Pokud má projekt zavedený vzor a AI ho nedodržuje, skutečný spolupracovník změnu nepřijme. V samostatném projektu bez pravidel to není velký problém. V týmu je to problém číslo jedna.
• Testy neřeší zabezpečení. Vzpomeňte si na údaj výše: bezpečných je pouze 10,5 % patchů, přestože 61 % je správných. To je třeba kontrolovat samostatně pomocí nástrojů, které zachytí tokeny, soubory .env a výchozí hesla.
• Překračování rozsahu úlohy je typická chyba AI. Požádáte ji o opravu autorizační funkce a dostanete patch, který také přepsal interní vrstvu a logování. To je jedna ze 6 os FrontierCode.

Jakých 6 kategorií chyb dělá AI při náročných úlohách?#

Pojďme si jednotlivé osy projít jednoduše:

1. Správnost chování — řeší patch úlohu?

Nejzákladnější osa. AI často napíše kód, který vypadá jako řešení, ale řeší nesprávný problém. Požádám ji, aby „přidala potvrzení přečtení zprávy“, a dostanu funkci markAsRead, která ale není propojená se samotnou komponentou chatu. Test funkce projde. Obchodní úloha vyřešena není.

2. Bezpečnost z hlediska regresí — nepoškozuje sousední kód?

AI změní jeden modul a jiný přestane fungovat. Nejčastější případ: AI agent změní signaturu funkce a zapomene, že se volá na dalších 17 místech. Na SWE-bench to neuvidíte — testy se spouštějí jen pro jeden soubor. Na FrontierCode se spouští celá testovací sada repozitáře.

3. Technická čistota — projde sestavením, kontrolami lint a stylu?

AI může vytvořit kód, který se lokálně zkompiluje, ale selže v CI: chybí import, jsou použity tabulátory místo mezer, na konci řádku jsou dvě mezery nebo došlo k chybě v eslint.config.js. V živém projektu není styl rozmar; je to týmové pravidlo.

4. Správnost testů — jsou testy napsané AI platné?

Nejzáludnější osa. AI napíše test, který projde. Ale projde při jakémkoli kódu, včetně nefunkčního. Viděl jsem to mnohokrát: test kontroluje „zhroutil se skript?“, ale ne „vrátil správný výsledek?“ Reverse-Classical ve FrontierCode zachytí přesně tento případ.

5. Rozsah — vyhýbá se patch úpravám nesouvisejících souborů?

Požádám o opravu jedné funkce a dostanu patch pro 12 souborů, včetně těch, které s úlohou nesouvisejí. Právě taková „iniciativa“ AI rozbije produkční projekt tím, že změní věci, o jejichž změnu jsem nežádal. Tato osa je ve FrontierCode zásadní překážkou.

6. Kvalita kódu — dodržuje kód konvence repozitáře?

AI napíše vlastní funkci „od nuly“ místo použití existujících pomocných funkcí v lib/. Nebo pojmenuje proměnné způsobem, který neodpovídá stylu projektu. Nebo umístí logiku do nesprávné architektonické vrstvy. Z pohledu testu vše funguje. Z pohledu technického vedoucího se patch nesloučí.

Jak kontrolovat kód AI před odesláním: 5 kroků#

1. Spusťte celou testovací sadu, nejen testy související se změnou

   AI často mění kód nad rámec úlohy. Problém se projeví v sousedních testech. Spouštím kompletní testovací sadu (jediným příkazem npm test, bez cesty), nikoli pouze testy konkrétního souboru. U velkých projektů je praktické spouštět ji paralelně pomocí git worktree (viz Git worktree v Claude Code).

2. Spusťte kontroly lint, stylu a typů

   Tři příkazy v pořadí: eslint ., prettier --check ., tsc --noEmit. AI agent může přehlédnout jak tabulátory, tak jednu nadbytečnou koncovou mezeru. Pokud má projekt přísné kontroly, spusťte je před vydáním lokálně.

3. Otestujte samotný test

   Nejdůležitější z 5 kontrol. Provedu v kódu malou „poruchu“ (změním return true na return false). Test by měl selhat. Pokud neselže, AI ho napsala jen naoko a je k ničemu. Test smažu a požádám AI, aby jej napsala znovu s povinnou podmínkou: test musí selhat na nefunkční verzi.

4. Zkontrolujte, kterých souborů se AI dotkla

   Příkaz git diff --stat ukáže, které soubory se změnily a kolik řádků. Pokud AI kvůli požadavku „oprav kontaktní formulář“ změnila 12 souborů, překročila rozsah úlohy. Nadbytečné změny vrátím jediným příkazem pro daný soubor.

5. Proveďte bezpečnostní kontrolu pomocí hotové dovednosti

   Testy nezachytí SQL injection ani natvrdo zadaná hesla. Používám hotovou bezpečnostní dovednost pro Claude Code (viz 754 hotových bezpečnostních dovedností). Minimálně ručně vyhledejte v projektu slova „password“, „secret“ a „key“ a zkontrolujte, zda je .env.example úplný.

Všech 5 kroků pokrývá 5 ze 6 os FrontierCode (1–5). Šestá osa — kvalita kódu — se kontroluje automaticky pomocí lintování a také lidskou revizí.

Co skutečně zvyšuje šanci na kód vhodný ke sloučení?#

AI agent v nepřipraveném projektu vidí jen soubor, který jste mu otevřeli. Nezná historii vašich rozhodnutí, vaše konvence ani mapu modulů. U jednoduchých změn to nevadí. U náročných změn je chybějící kontext riziko, které stojí za řešení. Hodnota benchmarku 13,4 % neizoluje kvalitu kontextu jako příčinu.

Co musíte udělat, abyste těch 13 % změnili na něco, co můžete skutečně nasadit do produkce:

1. Pravidla projektu — aby AI napodobovala vaše uvažování, a ne průměr internetu.

Jde o soubor vašich hotových řešení, návyků a osvojených pravidel ve formátu, který AI agent čte při každém požadavku. Jakmile pravidel bude 30+, AI přestane vymýšlet „průměr oboru“ a začne navrhovat řešení ve vašem stylu. Překračování rozsahu úlohy lze řešit jedním řádkem v pravidlech: „Nedotýkej se souborů, které nejsou výslovně uvedené v požadavku.“

2. Mapa projektu — složka, která projekt popisuje.

Sem ukládáte produkty, publikum, ekonomiku, metriky a nastavení. Před každým požadavkem si AI agent přečte obsah a pochopí, na které části podnikání pracuje. Tím se automaticky řeší dva z výše uvedených důvodů zamítnutí: styl a rozbíjení jiného kódu.

3. Context Engineering — řízení toho, co AI vidí před zadáním.

Nejde o to, „jak formulovat prompt“, ale „co dát do kontextového okna PŘED promptem“. CLAUDE.md, předpoklady a cílené odkazy na soubory. Tím se řeší selhání správnosti chování a kvality kódu.

Kombinaci použijte jako přípravu kontrol, nikoli důkaz splnění pěti os. Před přijetím ověřte chování, regrese, testy, rozsah a kvalitu kódu na skutečném patchi.

Další vrstvou jsou agenti pro revizi:

• Cursor Bugbot — provádí revizi každého PR. Podle Cursoru nástroj zpracuje přibližně 2 miliony PR za měsíc.
• Vnoření subagenti v Claude Code v2.1.172 — jeden agent píše kód, druhý ho reviduje a třetí spouští testy. Je to stejný princip jako u FrontierCode: oddělení rolí „autora“ a „technického vedoucího“.

Viz také: Zabezpečení při vibe codingu, Jak nakonfigurovat Claude Code, aby v noci nerozbíjel váš projekt a pojem Context Engineering.

Další materiály o práci s nástroji najdete v dokumentaci Ailoot.