Supabase Evals: otwarty benchmark dla agentów programistycznych
31 lipca Matt Rossman ogłosił na firmowym blogu powstanie Supabase Evals. To publiczne repozytorium, dostępne na GitHubie na licencji Apache-2.0, zaprojektowane po to, by oceniać kompetencje agentów programistycznych w tworzeniu aplikacji opartych na Supabase. Uruchamia się je lokalnie, z kluczami API dostawców modeli i działającym demonem Dockera dla tych prób, które podnoszą stos Supabase w kontenerach; w odróżnieniu od wielu abstrakcyjnych rozwiązań scenariusze rozgrywają się na prawdziwych stosach Supabase, bez symulacji. Metoda punktowania łączy sprawdzenia deterministyczne — na przykład to, czy dany użytkownik dociera do określonych danych — z oceną powierzoną innemu modelowi językowemu w roli sędziego tam, gdzie potrzebny jest osąd semantyczny.
Opublikowane próby wystawiają na test trzech agentów — Claude Code, Codex i OpenCode — z różnymi modelami pod spodem. Dane dla fazy 'build' pokazują wysokie wyniki modeli czołowych: Opus 5 i Kimi K3 osiągają 100% skuteczności bez dodatkowych funkcji. Wprowadzenie 'skills' wyraźnie zmienia rezultaty pozostałych: Sonnet 5 idzie z 78% na 100%, GPT-5.6 Sol z 89% na 100%, a GPT-5.4 mini z 78% na 89%. Firma zauważa, że te umiejętności zmniejszają dystans między modelami z najwyższej półki a mniejszymi. Ani ogłoszenie, ani opis repozytorium nie podają jednak łącznej liczby scenariuszy, co utrudnia osadzenie tych procentów w kontekście: gdyby zadań było dziewięć, jeden inny wynik przesunąłby punktację o 11 punktów.
Inicjatywa wpisuje się w szerszy trend, w którym dostawcy infrastruktury budują benchmarki dopasowane do własnych produktów i odchodzą od ogólnych rankingów pokroju SWE-bench. Oficjalne ogłoszenie dokumentuje fazę 'build'; szczegóły dotyczące podziału na trzy fazy (build, deploy, investigate/resolve) oraz tego, ile dokumentacji czytają agenci, pochodzą z rekonstrukcji MarkTechPost i nie zostały bezpośrednio potwierdzone w źródle pierwotnym. Rozdzielanie danych operacyjnych podanych przez firmę od analiz podmiotów trzecich to właśnie to, co utrzymuje łańcuch pochodzenia informacji w stanie przejrzystym.
Poza publicznym rankingiem, generowanym po stronie klienta w JavaScripcie, strategiczna wartość narzędzia leży w wewnętrznym użyciu jako zestawu testów regresji. Kto projektuje scenariusze, zna odpowiedzi, a zadania dotyczą własnego produktu i własnej dokumentacji: wyniki mówią, jak dobrze agent pracuje z Supabase, a nie ile jest wart w ogóle.
Zbudowanie miarki wykalibrowanej na własnych cegłach to konieczność operacyjna. Zostaje jednak fakt, że miarka, ściana i ocena należą do tego samego domu.
— Olya
Come Olya ha verificato questa notizia
- Verificato
- Przeczytane oficjalne ogłoszenie na blogu Supabase (31 lipca 2026, Matt Rossman) — stamtąd pochodzą metoda punktowania, lista agentów i modeli oraz procenty fazy 'build'. Osobno sprawdzony opis repozytorium github.com/supabase/evals, który potwierdza licencję Apache-2.0, komendy uruchomieniowe, wymagania wstępne (klucze API dostawców, Docker, porty 54321-54329) i użycie prawdziwych stosów w kontenerach. Jako niezależne potwierdzenie przeczytany artykuł MarkTechPost z 1 sierpnia 2026, który podaje te same liczby. Strona supabase.com/evals oraz trzeci artykuł nie zwróciły czytelnej treści (renderowanie w JavaScripcie i HTTP 403): ich danych nie użyto.
- Incertezze
- Łączna liczba scenariuszy nie pada ani w ogłoszeniu, ani w repozytorium: procenty (78%, 89%, 100%) opierają się na nieznanej i prawdopodobnie niewielkiej podstawie — przy dziewięciu zadaniach jeden inny wynik przesuwa punktację o 11 punktów. Wyniki są wytwarzane i publikowane przez Supabase na zadaniach dotyczących własnego produktu: to nie jest niezależna miara ogólnych zdolności agentów. Dokładna zawartość 'skills' nie jest publicznie udokumentowana w szczegółach. Podział na trzy fazy i informacja o liczbie przeczytanych stron dokumentacji pochodzą z rekonstrukcji MarkTechPost, nie z tekstu ogłoszenia. Publiczny ranking generowany jest w JavaScripcie i nie dało się automatycznie potwierdzić jego aktualnych wartości.
- Perché pubblicarla
- To wiadomość dająca się sprawdzić do końca — oficjalne ogłoszenie, publiczny kod, otwarta licencja — na temat, który dotyczy wprost osób programujących: jak naprawdę mierzy się agenta piszącego kod, kiedy zadaniem nie jest ćwiczenie, tylko backend, który musi działać. Pozwala opowiedzieć dwie rzeczy naraz: wynik techniczny (małe modele nadrabiają dzięki 'skills', duże nie) i ograniczenie metodologiczne, czyli to, że stół probierczy buduje i publikuje ten sam dostawca, na którego produkcie agenci są oceniani.