FrontierCode Diamond: 13.4% poprawek do scalenia na 50 trudnych zadaniach (czerwiec 2026)

Dodatkowe materiały o konfigurowaniu narzędzi znajdziesz w dokumentacji Ailoot.

Czym jest FrontierCode i dlaczego jest ważny?#

Cognition to firma stojąca za Devinem (pierwszym autonomicznym inżynierem AI, zaprezentowanym w marcu 2024 r.) oraz Windsurf (przejętym w lipcu 2025 r.). Firma rozwija też własną serię modeli SWE-1.x. Benchmark opublikowano na publicznym blogu pod adresem cognition.com/blog/frontier-code.

Kluczowa zmiana nie dotyczy nowych liczb, lecz skali, według której mierzymy teraz te rzeczy.

Benchmark ma trzy poziomy trudności: Extended (150 zadań, cały zestaw), Main (100 najtrudniejszych, w tym Diamond) oraz Diamond (50 ekstremalnie trudnych zadań). Cognition celowo pozostawiło Diamond „w dużej mierze nienasycony” — nawet najlepszy model rozwiązuje mniej niż 15% zadań. Ma to zapewnić benchmarkowi zapas na rok i uchronić go przed nasyceniem w miesiąc, jak stało się z HumanEval.

Co mierzy FrontierCode: „Czy opiekun projektu zaakceptowałby ten PR?”#

Sześć obszarów oceny (według oficjalnego bloga Cognition):

1. Poprawność działania — czy poprawka rozwiązuje zadanie?
2. Bezpieczeństwo regresji — czy nie psuje istniejącego kodu?
3. Poprawność techniczna — czy przechodzi kompilację oraz kontrole lint i stylu?
4. Poprawność testów — czy testy napisane przez agenta są prawidłowe (testy przechodzące dla dowolnego kodu się nie liczą)?
5. Zakres — czy poprawka nie zmienia plików, których nie wskazano w zadaniu?
6. Jakość kodu — czy kod jest zgodny z konwencjami projektu i czytelny?

Aby poprawka została uznana za nadającą się do scalenia, musi zaliczyć wszystkie sześć obszarów. Wystarczy niezaliczenie jednego, by nie została scalona.

To zasadnicza zmiana perspektywy. Jak ujmuje to Cognition: „Poprawność to dziś podstawa”. Wcześniej benchmarki pytały: „Czy kod przeszedł testy?”. Teraz pytają: „Czy prawdziwy lider techniczny przyjąłby go do projektu?”.

Cognition wprowadziło trzy nowe techniki oceniania:

• Reverse-Classical: test napisany przez agenta musi nie przejść dla zepsutej wersji kodu. W przeciwnym razie test jest fikcją.
• Code Scope: automatyczny kontroler sprawdza, czy poprawka mieści się w uzgodnionym zakresie plików i liczbie wierszy.
• Adaptive Classical Grading: narzędzie LLM „mutagent” dostosowuje rygorystyczne testy do poprawnych wariantów rozwiązań.

Dlaczego stare benchmarki już się nie sprawdzają?#

Już w 2024 r. agenci AI osiągali znakomite wyniki w HumanEval. SWE-bench Verified niewiele się różni: w sierpniu 2025 r. OpenAI publicznie przyznało, że występuje problem zanieczyszczenia danych (modele „widziały” zbiór danych podczas treningu). Benchmarki straciły zdolność odróżniania najlepszych modeli.

Kluczowe badanie, które podważyło dawną miarę, ukazało się w marcu 2026 r.

Przebieg badania:

• Wybrano 4 aktywnych opiekunów z 3 repozytoriów (scikit-learn, Sphinx, pytest).
• Poproszono ich o ocenę 296 PR-ów wygenerowanych przez AI z SWE-bench Verified — wszystkie te PR-y przechodziły testy automatyczne.
• Porównano decyzje opiekunów z wynikami automatycznego ewaluatora.

Innymi słowy, benchmark mówi „zaliczone”, a opiekun projektu — „nie scalę”. Dzieje się tak średnio w jednej czwartej przypadków. Trzy najczęstsze powody odrzucenia, od najmniej do najbardziej poważnego:

1. Jakość kodu — nie pasuje do stylu repozytorium.
2. Psuje inny kod — powoduje błędy w sąsiednim kodzie.
3. Nie działa kluczowa funkcjonalność — nie rozwiązuje w pełni zadania, mimo że test przechodzi.

FrontierCode formalizuje właśnie ten problem. Cognition podjęło ten pomysł i rozwinęło go w pełny benchmark, angażując ponad 20 opiekunów zamiast 4.

Kolejnym ciosem jest badanie z grudnia 2025 r. dotyczące bezpieczeństwa poprawek generowanych przez AI.

W tym badaniu 61% rozwiązań SWE-Agent z Claude 4 Sonnet było poprawnych funkcjonalnie, ale tylko 10,5% z nich było bezpiecznych.

Kod przechodzi test, a mimo to co druga poprawka wprowadza lukę w zabezpieczeniach. W benchmarkach SWE-bench w ogóle tego nie widać — nie mierzą bezpieczeństwa. FrontierCode przynajmniej próbuje to wychwycić w obszarach „poprawności technicznej” i jakości kodu.

Ranking modeli: Opus 4.8 — 13,4%, GPT-5.5 — 6,3%#

Co zwraca uwagę w tabeli:

• Jeden wyraźny lider. Opus 4.8 od Anthropic wyprzedza najbliższego konkurenta mniej więcej dwukrotnie. Różnicę, którą trudno było dostrzec w SWE-bench, w FrontierCode widać wyraźnie.
• Otwarte modele jeszcze nie nadrobiły zaległości. Kimi K2.6 — najlepszy model open-code — uzyskuje 3,8% w Diamond. To 3–4 razy mniej niż Opus 4.8. Cognition nie opublikowało pełnej tabeli wyników Kimi K2.6 dla Main i Extended, więc nie da się jeszcze porównać go w całym zestawie.
• Cognition uczciwie umieściło własny model w dolnej części tabeli.

Podzbiór Diamond celowo pozostawiono „nienasycony”. Cognition zaprojektowało go z zapasem na lata. Wcześniejsze benchmarki nasycały się w ciągu 12–18 miesięcy, a FrontierCode ma wyższy pułap.

Co oznacza „13% nadających się do scalenia” dla vibe codera korzystającego z Claude Code?#

Najpierw ważna zmiana perspektywy: zestaw Diamond w FrontierCode celowo obejmuje wyjątkowo trudne zadania. Nie należy przenosić tego wyniku bez pomiaru na typowe zadania w nowym projekcie startupowym. Ten sam Opus 4.8 uzyskuje 51,8% poprawek nadających się do scalenia w Extended (150 zadań, pełny zestaw). To zupełnie inny obraz.

Wynik 51.8% dotyczy zestawu Extended benchmarku z 150 zadaniami. Jest wyższy niż wynik Diamond, ale żadna z tych liczb nie szacuje możliwości scalenia poprawek każdego modelu w Twoich zadaniach. Brak wyników Main lub Extended innych modeli nie uzasadnia dopisywania ich osiągów.

Co to oznacza dla vibe codera, który chce wdrażać kod na produkcję:

• Zielony test nie oznacza już „gotowe do scalenia”. Testy napisane przez samo AI mogą być bezwartościowe — mogą przechodzić dla dowolnego kodu. FrontierCode mierzy to bezpośrednio za pomocą Reverse-Classical: jeśli test nie wykrywa zepsutej wersji, nie jest zaliczany.
• Liczą się styl i konwencje repozytorium. Jeśli projekt ma ustalony wzorzec, a AI go nie przestrzega, prawdziwy współpracownik nie zaakceptuje zmiany. W prywatnych projektach bez zasad to niewielki problem. W zespole — problem numer jeden.
• Testy nie rozwiązują problemów bezpieczeństwa. Pamiętaj o wyniku przytoczonym wyżej: bezpiecznych jest tylko 10,5% poprawek, mimo że 61% jest poprawnych. Trzeba to sprawdzać osobno, za pomocą narzędzi wykrywających tokeny, pliki .env i domyślne hasła.
• Wykraczanie poza zakres zadania to typowy błąd AI. Prosisz o poprawienie funkcji autoryzacji, a dostajesz poprawkę, która zmieniła też warstwę wewnętrzną i logowanie. To jeden z 6 obszarów FrontierCode.

Jakie 6 kategorii błędów AI popełnia przy trudnych zadaniach?#

Przyjrzyjmy się każdemu obszarowi prostym językiem:

1. Poprawność działania — czy poprawka rozwiązuje zadanie?

To najbardziej podstawowy obszar. AI często pisze kod, który wygląda jak rozwiązanie, ale rozwiązuje niewłaściwy problem. Proszę o „dodanie potwierdzenia odczytu do wiadomości” i dostaję funkcję markAsRead, która nie została jednak podłączona do samego komponentu czatu. Test funkcji przechodzi. Zadanie biznesowe nie jest rozwiązane.

2. Bezpieczeństwo regresji — czy poprawka nie psuje sąsiedniego kodu?

AI zmienia jeden moduł, a inny przestaje działać. Najczęstszy przypadek: agent AI zmienia sygnaturę funkcji i zapomina, że jest wywoływana w 17 innych miejscach. W SWE-bench tego nie widać — uruchamiają testy tylko dla jednego pliku. FrontierCode uruchamia pełny zestaw testów repozytorium.

3. Poprawność techniczna — czy poprawka przechodzi kompilację oraz kontrole lint i stylu?

AI może wygenerować kod, który kompiluje się lokalnie, ale nie przechodzi CI: brakuje importu, tabulatory zastępują spacje, na końcu wiersza są dwie zbędne spacje albo pojawia się błąd w eslint.config.js. W działającym projekcie styl nie jest kaprysem, lecz zasadą zespołu.

4. Poprawność testów — czy testy napisane przez AI są prawidłowe?

Najtrudniejszy obszar. AI pisze test, który przechodzi. Ale przechodzi dla dowolnego kodu, także błędnego. Widziałem to wiele razy: test sprawdza „czy skrypt się zawiesił”, a nie „czy zwrócił poprawny wynik”. Reverse-Classical w FrontierCode wychwytuje właśnie taki przypadek.

5. Zakres — czy poprawka nie zmienia niezwiązanych plików?

Proszę o naprawienie jednej funkcji, a dostaję poprawkę obejmującą 12 plików, w tym niezwiązane z zadaniem. To właśnie ta „inicjatywa” AI, która psuje projekt produkcyjny przez zmiany, o które nie prosiłem. W FrontierCode ten obszar jest bezwzględną przeszkodą.

6. Jakość kodu — czy kod jest zgodny z konwencjami repozytorium?

AI pisze własną funkcję „od zera”, zamiast użyć istniejących narzędzi pomocniczych w lib/. Albo nazywa zmienne w sposób niezgodny ze stylem projektu. Albo umieszcza logikę w niewłaściwej warstwie architektury. Z punktu widzenia testu wszystko działa. Z punktu widzenia lidera technicznego kod nie zostanie scalony.

Jak sprawdzić kod AI przed wypchnięciem: 5 kroków#

1. Uruchom cały zestaw testów, a nie tylko testy związane ze zmianą

   AI często zmienia kod wykraczający poza zakres zadania. Problem ujawni się w sąsiednich testach. Uruchamiam cały zestaw testów pojedynczym poleceniem npm test (bez ścieżki), a nie tylko testy dla konkretnego pliku. W dużych projektach warto robić to równolegle, używając git worktree (zobacz Git worktree w Claude Code).

2. Uruchom kontrole lint, stylu i typów

   Wykonaj po kolei trzy polecenia: eslint ., prettier --check ., tsc --noEmit. Agent AI może przeoczyć zarówno tabulatory, jak i dodatkową spację na końcu wiersza. Jeśli projekt ma rygorystyczne kontrole, uruchom je lokalnie przed wydaniem.

3. Sprawdź sam test

   To najważniejsza z 5 kontroli. Wprowadzam niewielki „błąd” w kodzie (zmieniam return true na return false). Test powinien zakończyć się niepowodzeniem. Jeśli nie kończy się niepowodzeniem, AI napisało go tylko na pokaz, więc jest bezużyteczny. Usuwam taki test i proszę AI o napisanie go od nowa z obowiązkowym warunkiem: test musi nie przejść dla zepsutej wersji.

4. Sprawdź, które pliki zmieniło AI

   Polecenie git diff --stat pokazuje zmienione pliki i liczbę wierszy. Jeśli AI zmieniło 12 plików w odpowiedzi na prośbę „napraw formularz kontaktowy”, wykroczyło poza zakres zadania. Przywracam dodatkowe zmiany pojedynczym poleceniem dla danego pliku.

5. Przeprowadź kontrolę bezpieczeństwa z gotową umiejętnością

   Testy nie wykrywają wstrzyknięć SQL ani haseł wpisanych na stałe w kodzie. Używam gotowej umiejętności bezpieczeństwa dla Claude Code (zobacz 754 gotowe umiejętności bezpieczeństwa). Co najmniej ręcznie wyszukuję w kodzie projektu słowa „password”, „secret” i „key”, a także sprawdzam, czy .env.example jest kompletny.

Wszystkie 5 kroków obejmuje 5 z 6 obszarów FrontierCode (1–5). Szósty obszar — jakość kodu — sprawdza się automatycznie za pomocą lint oraz podczas przeglądu przeprowadzanego przez człowieka.

Co naprawdę zwiększa szanse na kod nadający się do scalenia?#

Agent AI w nieprzygotowanym projekcie widzi tylko otwarty przez ciebie plik. Nie zna historii twoich decyzji, konwencji ani mapy modułów. Przy prostych zmianach nie stanowi to dużego problemu. Przy trudnych zmianach brak kontekstu projektu jest ryzykiem, którym warto się zająć. Wynik 13.4% benchmarku nie izoluje jakości kontekstu jako swojej przyczyny.

Jak przygotować projekt i sprawdzić rzeczywistą poprawkę przed wdrożeniem na produkcję:

1. Zasady projektu — żeby AI odtwarzało twój sposób rozumowania, a nie przeciętną z internetu.

To zestaw gotowych rozwiązań, nawyków i wyuczonych reguł, zapisany w formacie czytanym przez agenta AI przy każdym żądaniu. Gdy reguł jest ponad 30, AI przestaje wymyślać „średnią branżową” i zaczyna podpowiadać rozwiązania w twoim stylu. Problem wykraczania poza zakres zadania można rozwiązać jednym wierszem reguł: „nie zmieniaj plików poza tymi wyraźnie wskazanymi w żądaniu”.

2. Mapa projektu — folder, który opisuje projekt.

Umieszczasz w nim informacje o produktach, odbiorcach, ekonomii, metrykach i konfiguracjach. Przed każdym żądaniem agent AI odczytuje spis treści i rozumie, nad którą częścią firmy pracuje. Pomaga to przygotować kontekst dla dwóch wymienionych obszarów: stylu i regresji w innym kodzie; zaliczenie obu trzeba sprawdzić na poprawce.

3. Context Engineering — zarządzanie tym, co AI widzi przed otrzymaniem żądania.

Nie chodzi o to, „jak sformułować prompt”, lecz o to, „co umieścić w oknie kontekstowym PRZED promptem”. CLAUDE.md, wymagania wstępne i bezpośrednie odsyłacze do plików. Pomaga to rozwiązać problemy z poprawnością działania i jakością kodu.

Używaj tej kombinacji jako przygotowania do sprawdzeń, a nie dowodu zaliczenia pięciu obszarów. Przed akceptacją sprawdź zachowanie, regresje, testy, zakres i jakość kodu rzeczywistej poprawki.

Dodatkową warstwę stanowią agenci przeglądający kod:

• Cursor Bugbot — przeprowadza przegląd każdego PR. Według Cursor narzędzie obsługuje około 2 milionów PR-ów miesięcznie.
• Zagnieżdżone subagenty w Claude Code v2.1.172 — jeden agent pisze kod, drugi go przegląda, a trzeci uruchamia testy. To ta sama idea co w FrontierCode: rozdzielenie ról „autora” i „lidera technicznego”.

Zobacz też: Bezpieczeństwo vibe codingu, Jak skonfigurować Claude Code, by nie psuł projektu nocą oraz Context Engineering jako koncepcję.

Dodatkowe materiały o pracy z narzędziami znajdziesz w dokumentacji Ailoot.