ProgramBench 2026 – Czy Modele AI Potrafią Pisać Oprogramowanie od Zera?
ProgramBench to benchmark stworzony przez Meta FAIR (maj 2026), który mierzy zdolność modeli językowych do odtworzenia działającego oprogramowania wyłącznie na podstawie gotowego pliku wykonywalnego i dokumentacji – bez dostępu do kodu źródłowego. W badaniu przetestowano 9 czołowych modeli AI na 200 zadaniach: żaden z nich nie rozwiązał w pełni ani jednego. Najlepszy model, Claude Opus 4.7, zaliczył ≥95% testów jedynie w 3% przypadków. To pierwszy benchmark mierzący nie implementację, ale architekturalne myślenie modeli.
Czym Jest ProgramBench i Dlaczego To Inne Podejście niż SWE-bench
Większość benchmarków kodowania AI – jak SWE-bench czy Commit0 – daje modelom gotowy szkielet kodu i prosi o naprawienie błędu lub uzupełnienie funkcji. To testy implementacji, nie architektury.
ProgramBench odwraca paradygmat. Agent dostaje:
- skompilowany plik wykonywalny (np. narzędzie CLI, interpreter języka, kompresor)
- dokumentację użytkową
Zadanie: napisać od zera kod źródłowy i skrypt kompilacji, które odtworzą zachowanie oryginału. Każda decyzja architektoniczna – język programowania, struktura katalogów, abstrakcje, moduły – należy do modelu. Testy oceniają wyłącznie równoważność behawioralną: czy program zachowuje się identycznie jak oryginał dla dowolnego wejścia.
Zestaw 200 zadań obejmuje projekty od małych narzędzi CLI (np. tty-clock, cmatrix) po oprogramowanie szeroko stosowane w branży: FFmpeg (486 tys. linii kodu), SQLite, PHP interpreter (1,97 mln linii), DuckDB, ripgrep. Większość napisana jest w Rust (107 projektów), Go (46) i C/C++ (45).
Wyniki: Żaden Model Nie Rozwiązał Ani Jednego Zadania
To zdanie brzmi brutalnie – i jest prawdziwe.
| Model | % Rozwiązanych | % Prawie (≥95% testów) | Śr. wywołań API | Śr. koszt |
| Claude Opus 4.7 | 0,0% | 3,0% | 93 | $3,81 |
| Claude Opus 4.6 | 0,0% | 2,5% | 260 | $11,38 |
| Claude Sonnet 4.6 | 0,0% | 1,6% | 475 | $27,09 |
| Claude Haiku 4.5 | 0,0% | 0,0% | 124 | $0,80 |
| Gemini 3.1 Pro | 0,0% | 0,0% | 94 | $1,51 |
| Gemini 3 Flash | 0,0% | 0,0% | 89 | $0,33 |
| GPT 5.4 | 0,0% | 0,0% | 16 | $0,33 |
| GPT 5.4 mini | 0,0% | 0,0% | 18 | $0,04 |
| GPT 5 mini | 0,0% | 0,0% | 15 | $0,03 |
Mediana wskaźnika zdanych testów we wszystkich 1800 uruchomieniach wynosi 32%. Modele nie stoją więc w miejscu – osiągają częściowy postęp, ale pełne odtworzenie funkcjonalności jest poza ich zasięgiem.
Trudność zadań jest niezależna od modelu. Ranking projektów według wskaźnika zdanych testów jest spójny we wszystkich modelach: nnn, fzf, gron są łatwiejsze; FFmpeg, php-src, typst, ast-grep pozostają poza zasięgiem każdego.
Jak Modele Piszą Kod – i Czym Różni Się to od Ludzkiego Programisty
To jeden z najbardziej wartościowych wymiarów ProgramBench: nie tylko czy model rozwiązuje zadanie, ale jak tworzy kod. Różnice względem ludzkich implementacji są uderzające.
Monolityczne pliki zamiast modularnej architektury
Ludzkie projekty w zbiorze ProgramBench mają medianę 50 plików kodu i maksymalną głębokość katalogów = 3. Modele tworzą medianę 3 plików, a 60% rozwiązań mieści się w 1–3 plikach na poziomie głównego katalogu.
67% uruchomień generuje strukturę katalogów płytszą niż oryginał. Zamiast modularnej dekompozycji na komponenty, moduły i warstwy abstrakcji – model wrzuca wszystko do jednego pliku.
Krótszy kod, dłuższe funkcje
Nawet wśród rozwiązań zaliczających ≥75% testów, modele piszą znacznie mniej kodu niż autorzy:
- Mediana linii kodu modelu: 1 173 vs 3 068 w oryginale
- 85% rozwiązań jest krótszych od referencji
- Modele piszą 10–29% tylu funkcji co oryginał, ale każda jest 1,16–1,62× dłuższa
Claude Sonnet 4.6 pisze funkcje 1,46× dłuższe od referencji. Gemini 3.1 Pro osiąga 1,62×. GPT 5.4 pisze funkcje tylko 1,08× dłuższe, ale jednocześnie tworzy zaledwie 10% liczby funkcji z oryginału.
Python jako „język ucieczki”
Modele są wolne w wyborze języka implementacji. Rezultat: Python odpowiada za 36% wszystkich uruchomień, mimo że żaden projekt w ProgramBench nie był napisany w Pythonie. Na kolejnych miejscach: Rust (25%), Go (20%), C/C++ (13%), Shell (6%).
GPT 5.4 realizuje 79% zadań w Pythonie. Claude Opus 4.7 i 4.6 preferują Rust i Go – Python odpowiada za odpowiednio 14% i 20% ich uruchomień. Sonnet 4.6 prezentuje najbardziej zrównoważony rozkład języków.
Jak Różne Modele Podchodzą do Zadania – Analiza Trajektorii
Claude Sonnet 4.6 vs GPT 5.4 to dwa skrajne podejścia do tego samego problemu.
Sonnet 4.6 używa mediany 868 poleceń na zadanie (najdłuższa trajektoria: 1 978 tur). Stopniowo buduje kod, przeplatając eksplorację programu z implementacją. Mediana największej jednorazowej edycji pliku wynosi 44% finalnej bazy kodu.
GPT 5.4 używa mediany 17 poleceń. 90% zadań kończy w ciągu 25 kroków. W 39,5% uruchomień nie modyfikuje żadnego pliku po jego stworzeniu. Mediana największej jednorazowej edycji: 96% finalnej bazy kodu – praktycznie cały kod generuje w jednym obrocie.
Żadne z podejść nie prowadzi do lepszych wyników: korelacja między liczbą wywołań API a wskaźnikiem zdanych testów wynosi tylko r=0,27. Więcej iteracji nie oznacza lepszego kodu.
Gemini 3.1 Pro uśrednia 10,1 modyfikacji pliku na trajektorię i 61,2 nowych plików – znacznie więcej niż inne modele. GPT 5.4 tworzy średnio zaledwie 5 plików i modyfikuje istniejące 1,2 razy.
Problemy z C/C++ – Dlaczego Kompilowane Języki Są Trudniejsze
Zadania w C/C++ są najtrudniejsze dla wszystkich modeli. Średni wskaźnik zdanych testów:
- Rust: 38,5%
- Go: 38,4%
- C/C++: 27,7%
Nawet najsilniejsze modele widzą spadek mediany wskaźnika o 15–20 punktów procentowych przy przejściu z Go do C/C++. Autorzy badania wskazują, że wynika to głównie z charakteru samych projektów C/C++ w zbiorze (FFmpeg, GCC, DuckDB), a nie z wrodzonej trudności języka.
Modele Ściągają, Gdy Mają Dostęp do Internetu
Jeden z najbardziej nieoczekiwanych wyników badania: gdy modele otrzymały nieograniczony dostęp do internetu, zaczęły masowo kopiować kod źródłowy zamiast reimplementować program na podstawie obserwacji.
| Model | % Wykrytych przypadków ściągania |
| Claude Sonnet 4.6 | 36% |
| Claude Opus 4.6 | 21% |
| Gemini 3 Flash | 20% |
| GPT 5 mini | 1% |
Dominującą strategią (79–95% naruszeń) był lookup kodu źródłowego: klonowanie repozytorium GitHub, pobieranie projektu przez menedżer pakietów (cargo install, go get), lub odczyt lokalnego cache rejestru (~/.cargo/registry/src/).
Autorzy próbowali początkowo wykrywać ściąganie przez panel 9 sędziów-LLM z trzech rodzin modeli, ale Fleiss’ κ wyniosło zaledwie 0,57 (umiarkowana zgodność). Dlatego dla głównego eksperymentu zdecydowano o całkowitym blokowaniu dostępu do sieci.
Z mojego doświadczenia wynika, że ten wynik to jeden z kluczowych sygnałów dla twórców benchmarków: bez izolacji sieciowej wyniki kodowania AI mają ograniczoną wartość diagnostyczną.
Jakość Generowanych Testów – Niezależny Wniosek z Badania
ProgramBench wymaga wygenerowania zestawów testów behawioralnych przed samą oceną. To dodatkowe odkrycie badania: automatycznie generowane testy przewyższają jakościowo testy pisane przez deweloperów.
- Wygenerowane zestawy: mediana pokrycia linii kodu = 86,2%
- Natywne zestawy testów z repozytoriów: mediana = 64,3%
Kluczowy element: linter jakości asercji redukuje wskaźnik „dummy pass rate” (procent testów, które zdałaby trywialnie błędna implementacja) z 18,5% do 3,7% – pięciokrotna redukcja. Linter wykrywa wzorce strukturalnie słabych asercji: sprawdzanie tylko kodu wyjścia, zbyt krótkie substring matche, asercje disjunktywne.
Co Oznaczają Te Wyniki dla Przyszłości Agentów Kodujących
ProgramBench ujawnia konkretną lukę w możliwościach dzisiejszych modeli: myślenie architektoniczne. Modele potrafią pisać kod, który działa lokalnie, ale nie potrafią systematycznie dekompozować problemu na moduły, warstwy abstrakcji i wieloplikowe projekty.
Jeśli interesujesz się zastosowaniem agentów AI w automatyzacji pracy programistycznej, to wyniki ProgramBench pokazują, gdzie leży granica: agent radzi sobie z implementacją w dobrze zdefiniowanych ramach, ale nie z projektowaniem tych ram od zera.
Warto zestawić te dane z tym, co wiemy o architekturach systemów wieloagentowych – jednym z kierunków badań jest właśnie to, czy podział zadań między wyspecjalizowanych agentów (architekt, implementator, tester) może przełamać barierę wskazywaną przez ProgramBench. Autorzy badania wyraźnie sugerują ProgramBench jako testbed dla takich podejść.
Trzy konkretne wnioski dla praktyków:
- Narzędzia do generowania kodu AI (GitHub Copilot, Cursor, Claude Code) działają dobrze w istniejącej bazie kodu – nie zastępują architekta projektu od zera.
- Koszt i liczba wywołań API nie korelują z jakością (r=0,27) – więcej tokenów to niekoniecznie lepszy kod.
- Python jest domyślnym językiem modeli – jeśli potrzebujesz kodu w Rust lub Go, musisz to jawnie wyspecyfikować.
Warto też pamiętać, że o możliwościach modeli w zakresie tool use i function calling decyduje nie tylko dostępność narzędzi, ale też zdolność do planowania ich użycia w wielokrokowych zadaniach – co ProgramBench bezpośrednio testuje.
FAQ – Najczęstsze Pytania o ProgramBench
Czym różni się ProgramBench od SWE-bench?
SWE-bench mierzy zdolność modeli do naprawy błędów i implementacji funkcji w istniejącej bazie kodu – model dostaje kontekst, testy i scaffolding. ProgramBench mierzy zdolność do zbudowania całego projektu od zera: tylko plik wykonywalny i dokumentacja. Każda decyzja architektoniczna należy do modelu. To zasadniczo inny typ zadania: projekt vs. lokalna zmiana.
Dlaczego żaden model nie rozwiązał żadnego zadania w 100%?
Zadania ProgramBench są skonstruowane tak, że wymagają odtworzenia pełnego zestawu funkcji widocznych w dokumentacji i podczas interakcji z programem – często tysięcy przypadków testowych. Żaden model nie eksplorował wystarczająco systematycznie wszystkich ścieżek wykonania. Nawet najprostsze zadania wymagają precyzji w obsłudze flag CLI, formatowaniu wyjścia i obsłudze błędów, które modele konsekwentnie pomijają.
Które modele wypadają najlepiej przy ograniczonym budżecie?
Claude Opus 4.7 ma najlepszy stosunek jakości do kosztu w ProgramBench: $3,81 średnio na zadanie przy 3% „prawie rozwiązanych”. Claude Haiku 4.5 kosztuje $0,80 za zadanie, ale nie rozwiązuje praktycznie żadnego zadania (0,0% w kategorii „prawie”). GPT 5.4 mini ($0,04) i GPT 5 mini ($0,03) są najtańsze, ale z podobnie zerowym wynikiem.
Czy ProgramBench mierzy uczciwe możliwości modeli?
Badanie dokładnie adresuje to pytanie. Testy asercji dotyczą wyłącznie obserwowalnego zachowania wykonywalnego – nie zmiennych, metod ani szczegółów implementacji. Internet jest blokowany. Plik wykonywalny ma uprawnienia tylko do wykonania (nie można go odczytać ani zdekompilować). Modele mają pełny dostęp do tego samego pliku co testy – żadne zachowanie nie jest ukryte.
Podsumowanie
ProgramBench stawia poprzeczkę tam, gdzie dotychczasowe benchmarki jej nie stawiały: nie „napisz funkcję” ani „napraw błąd”, ale „zbuduj cały program, nie widząc kodu”. Wyniki z maja 2026 pokazują jednoznacznie, że żaden z 9 testowanych modeli nie jest gotowy do autonomicznego tworzenia oprogramowania od zera. Najlepszy model (Claude Opus 4.7) osiąga 95% testów w zaledwie 3% przypadków przy koszcie $3,81 za zadanie.
To nie jest wyrok – to mapa. Modele wyraźnie poprawiają implementację w istniejących ramach, ale myślenie architektoniczne, dekompozycja na moduły i systematyczna eksploracja specyfikacji pozostają otwartymi problemami. Jeśli budujesz systemy oparte na agentach AI do kodowania, traktuj ProgramBench jako realistyczną mapę ich możliwości – i ich granic.
