Kod Ludzki z 2020 roku pokonał agentów kodowanych wibacyjnie w testach agenckich

ChatGPT i inne narzędzia do vibe coding przetestowano w niemal 40 000 meczów. Przegrały z kodem studentów studiów magisterskich napisanym przed powstaniem dużych modeli językowych.W nowym brytyjskim badaniu agenci napisani przez ludzi zmierzyli się z agentami stworzonymi metodą vibe coding przy użyciu najnowszych dużych modeli językowych — m.in. GPT-5 i Claude. Agenci bez pomocy AI łatwo wygrali. Obie grupy stworzyły różne roczniki studentów laboratorium AI na EPFL. Agenci bez AI powstali na zajęciach w 2020 r., dwa lata przed ChatGPT, a nowych agentów zbudowali obecni studenci z pomocą najlepszych LLM. Nawet przy przewadze przyznanej AI rozwiązania vibe-coded nie zwyciężyły. Pierwsze pięć miejsc zajęli agenci napisani ręcznie, a 33 z 40 agentów LLM przegrało z prostymi agentami bazowymi w 38 304 pojedynkach. Autorzy piszą:

„Nasza praca pokazuje, że choć najnowocześniejsze LLM potrafią generować działający kod bez błędów składni, rozwiązania te nie konkurują z projektami ludzi pod względem planowania strategicznego, optymalizacji ani rywalizacji wielu agentów.”

„Badanie wskazuje nową granicę generowania kodu i ma wspierać rozwój benchmarków, zbiorów danych i otwartych punktów odniesienia wymagających syntezy kodu opartej na rozumowaniu.”

Zadanie polegało na kreatywnym udziale w aukcjach według różnych strategii i planowaniu logistyki dostawy wygranych zleceń. LLM otrzymały przywileje, w tym możliwość poprawiania kodu, której nie miały rozwiązania z 2020 r. Nawet gdy pokazano im kod, który poprawiłby wyniki, nie potrafiły go wykorzystać:

„W naszym benchmarku LLM nadal nie potrafi wykorzystać dobrego rozwiązania, nawet gdy pokazujemy je w kontekście.”

„Wynik rodzi pytania o granice uczenia kontekstowego i rozwiązywania złożonych problemów wspomaganego wyszukiwaniem.”

Testowano GPT-5 Thinking, Gemini 2.5 Pro, Claude Opus 4.1 oraz DeepSeek R1*. Nowa publikacja nosi tytuł Can Vibe Coding Beat Graduate CS Students? An LLM vs. Human Coding Tournament on Market-driven Strategic Planning i pochodzi od autorów z University of Southampton oraz University of Oxford i Alan Turing Institute. Benchmark ma zostać wkrótce udostępniony.

Metoda

Autorzy zauważają, że tradycyjne testy opierają się na binarnych odpowiedziach: poprawne lub niepoprawne, sprawdzanych przez testy jednostkowe. Aby lepiej badać ograniczenia kodu wspomaganego LLM, zaprojektowali złożone zadanie z wieloma etapami, w którym zwycięstwo jest możliwe, lecz trudne: Porównanie standardowego podejścia opartego na testach jednostkowych (u góry) z bardziej otwartym wyzwaniem autorów (na niebiesko, u dołu). Źródło Problem Auction, Pickup and Delivery Problem (APDP) wybrano m.in. dlatego, że dostępny był korpus prac studentów z 2020 r. dotyczących agentów automatycznych. Obecni studenci dostali ten sam opis zadania, lecz mogli używać nowych narzędzi. Autorzy unikali popularnych benchmarków, takich jak HumanEval, BigCodeBench i WebDev Arena, ponieważ mogą być zanieczyszczone danymi, gdy system uczył się na danych testowych zamiast przestrzegać prawidłowego podziału danych.Aukcjach odwrotnych i wyznaczaniu tras pojazdów opiera się dwuetapowy APDP. Najpierw agenci licytują kwotę za realizację dostaw: zbyt wysoka oferta przegrywa, zbyt niska grozi stratą. Następnie planują wydajne wykonanie tylko wygranych zadań, przydzielając je pojazdom o różnych pojemnościach i kosztach oraz przestrzegając ograniczeń czasu i zasobów. W APDP firmy licytują zadania dostawcze w aukcjach odwrotnych, a następnie optymalizują trasy pojazdów, aby zrealizować tylko wygrane zadania i zmaksymalizować zysk. Celem nie jest samo wykonanie dostaw, lecz maksymalizacja zysku dzięki przewidywaniu korzystnych pakietów zadań i strategii rywali. Kolejne aukcje są współzależne, więc każdy zakład zmienia przyszłe możliwości, a agent musi rozumować o kosztach, pozycji, czasie i długofalowych skutkach. Główny problem dostaw jest NP-trudny: wraz ze wzrostem liczby zadań nie istnieje algorytm niezawodnie znajdujący najlepsze rozwiązanie w rozsądnym czasie. Brutalna siła odpada, a agenci równoważą precyzję i szybkość.

Wyścig się rozpoczyna

Autorzy porównali 40 agentów LLM z 17 agentami napisanymi przez ludzi. Każdy z 12 turniejów używał innego zestawu czterech sieci drogowych i systemu każdy z każdym, w którym każda para grała dwukrotnie, raz jako każda z dwóch firm. Dawało to 3 192 mecze na turniej i 38 304 łącznie. W każdym meczu aukcja obejmowała 50 dostaw losowanych na mapach Szwajcarii, Francji, Wielkiej Brytanii i Niderlandów. Uproszczone sieci drogowe użyte w turnieju: Wielka Brytania, Szwajcaria, Niderlandy i Francja. Niebieskie i czerwone kwadraty oznaczają odbiory i dostawy, a kolorowe trójkąty pozycje pojazdów. Agenci studenccy pochodzili z turnieju kursowego z 2020 r.: ośmiu finalistów i czterech kolejnych skutecznych przeciwko agentom bazowym. Agenci bazowi stosowali stałe heurystyki. Naive obliczał całkowity dystans i licytował na tej podstawie, używając jednego pojazdu; ExpCostFixedBid symulował 10 losowych zadań i oferował średni koszt krańcowy; Honest liczył rzeczywisty koszt wstawienia zadania do harmonogramu; ModelOpponent dodawał szacunek kosztu przeciwnika i wybierał wyższą ofertę; RiskSeeking łączył malejące z czasem założenie z bieżącym kosztem i modelem rywala. Oceniono też 40 agentów z GPT-5 Thinking, Claude Opus 4.1, Gemini 2.5 Pro i DeepSeek R1. Każdy model otrzymał pięć strategii promptowania, po dwa razy. Dwa prompty napisali różni autorzy, trzeci wymagał autorefleksji, czwarty krytyki innego LLM, a piąty GPT-4 zsyntetyzował z poprzednich. Prompt bazowy odtwarzał zadanie studentów: licytować i planować dla maksymalnego zysku bez metod o wysokiej złożoności. Agenci LLM byli testowani i poprawiani przez same modele aż do usunięcia widocznych błędów. Typowe awarie obejmowały przekroczenia czasu, brak odbioru lub dostawy oraz naruszenia pojemności pojazdów, często wskutek ignorowania instrukcji lub wadliwego przeplanowania^†:

„Częstym problemem, zwłaszcza Gemini, Claude i DeepSeek, było uporczywe niewyjaśnianie błędu.”

„Agent wielokrotnie przekraczał limit czasu mimo 5–15 cykli przekazywania modelowi błędu i otrzymywania poprawionej wersji kodu.”

„Jedynym rozwiązaniem było rozpoczęcie od zera. Uzyskanie kodu bez błędów wymagało znacznej pracy ręcznej; aby otrzymać 40 sprawnych agentów, trzeba było wygenerować ich o wiele więcej.”

Tabela podsumowuje 12 podwójnych turniejów każdy-z-każdym na czterech topologiach, łącznie niemal 40 000 meczów:

Dla kontekstu każdy agent rozgrywał 112 meczów na turniej, więc maksymalna średnia wygranych lub porażek wynosi 112. Odchylenie standardowe (SD) pokazuje zmienność między turniejami. Agenci ludzi są pogrubieni. Agenci LLM mają oznaczenie modelu (O = GPT-5 Thinking, G = Gemini 2.5 Pro, A = Claude Opus 4.1, D = DeepSeek R1), dwuliterową strategię promptu i numer pierwszej lub drugiej generacji. ŹródłoW odniesieniu do wyników autorzy stwierdzają^†:

„LLM nie tworzyły oczekiwanego, konkurencyjnego kodu nawet w prostszych odmianach APDP, mimo że kod był w większości wolny od błędów składni. Pokazuje to potrzebę benchmarków opartych na rozumowaniu, wykraczających poza autouzupełnianie.”

„Wyniki pokazują wyraźną przewagę agentów ludzi: pięć pierwszych miejsc stale zajmują studenci, a większość agentów LLM — 33 z 40 — przegrywa z bardzo prostymi agentami bazowymi.”

„Nie debugowaliśmy kodu studentów, choć dokładnie testowaliśmy i poprawialiśmy kod LLM. Każda awaria studenta dawała automatyczną wygraną LLM. Wiele awarii łatwo byłoby naprawić, więc studenci mogliby uplasować się jeszcze wyżej.”

W dodatkowym eksperymencie GPT-5 Thinking miał ulepszyć najlepszego agenta Student 1; zmodyfikowany agent spadł jednak na dziesiąte miejsce, najgorsze wśród ludzi. Zmiany pogorszyły wynik o niemal 20%. Autorzy podsumowują:

„Wyniki ujawniają ważne ograniczenia generowania kodu przez LLM, zwłaszcza słabe rozumowanie i planowanie. Nowoczesne LLM tworzą działający kod bez błędów składni, ale nie jest to właściwy miernik postępu ku zaawansowanej ogólnej AI.”

Wnioski

Pod koniec publikacji autorzy zauważają, że vibe coding daje możliwości ludziom o różnym zapleczu technicznym i może wyrównywać szanse. Jednocześnie jego granice są jeszcze nieznane i prawdopodobnie niższe, niż często się zakłada. Apelują o zmianę celu: „od kodu, który się kompiluje, do kodu, który konkuruje”. Czytelnik może zapytać, czy porównanie jest sprawiedliwe, ponieważ zadanie agentowe było znacznie bardziej złożone niż proste skrypty PowerShell i drobne funkcje, do których vibe coding dobrze się nadaje. * Uwaga: publikacja stale używa nazwy „DeepThink R1”, która najwyraźniej nie istnieje i prawdopodobnie jest błędnym zapisem „DeepSeek R1”. Jeśli to mój błąd, proszę o kontakt przez profil, a poprawię tekst.^† Wyróżnienia pochodzą od autorów, nie ode mnie.Pierwotnie opublikowano w środę 26 listopada 2025 r. Poprawiono formatowanie o 17:35 czasu wschodniego.