Supabase-evals: 38 oppgaver måler kodeagenter mot ekte RLS-lekkasjer

Supabase la Apache 2.0-lisensen på eval-repoet sitt 30. juli og har siden kjørt oppdaterte resultater inn i det offentlige nettgrensesnittet, senest 1. august. Repoet samler 38 scenarioer fordelt på fire stadier: bygge noe fra bunnen, deploye det, undersøke hva som er galt i et prosjekt som allerede kjører, og rette feilen.

Fordelingen sier mest om hva Supabase faktisk vil måle. 17 av oppgavene handler om å bygge, mens 18 handler om å diagnostisere eller reparere noe som allerede er ødelagt. Fem av dem er navngitt etter row level security: lekkasje mellom brukere, lekkasje mellom tenants, tenant-isolasjon i tester, egne todos på klientsiden og organisasjonsroller. Ti berører Edge Functions, blant annet en 546-ressursgrense og en 5xx-korrelasjon i loggene.

Bakgrunn

Det som skiller oppsettet fra en vanlig kodebenchmark er at agenten får to miljøer samtidig. Katalogen «remote» beskriver hvordan kundens hostede prosjekt allerede ser ut, med database, observabilitetslogger og ferdig deployede Edge Functions seedet inn i en lettvektsetterligning Supabase kaller platform-lite. Katalogen «local» er utviklerens arbeidskatalog. Oppgaver som krever kommandolinja kjører i stedet i en Docker-sandkasse med ekte Supabase CLI, der stacken spinnes opp som søsken-containere gjennom vertens Docker-socket.

«This repo answers how well can agents use Supabase across various tasks.» — supabase/evals, README

Poengsettingen er strengere enn den ser ut. Scorerne kjører på verten mot et arbeidsområde som kopieres ut av sandkassen etter at agenten er ferdig, og de sjekker bare deltaet agenten selv produserte. Er tilstanden allerede satt opp av testoppsettet, teller den ikke som agentens fortjeneste.

Repoet er også et av de første offentlige eksemplene på at skills måles som en egen variabel. Ferdighetene hentes fra supabase/agent-skills som git-submodul og lastes progressivt: bare navn og beskrivelse ligger i systemprompten, resten hentes når agenten ber om det. I sandkassen skjer det gjennom filverktøy, i ren verktøymodus gjennom et load_skill-kall. Eksperimentsuitene heter «benchmark» og «no-skills», så forskjellen skills utgjør er selve målingen.

Hva bør du gjøre?

1. Les scorerne i EVAL.ts før du leser tallene. Et eval som sjekker sluttilstanden i databasen er en helt annen test enn et som leser agentens rapport, og repoet blander begge.
2. Kopier to-miljø-strukturen hvis du bygger egne evals. Skillet mellom hostet tilstand og lokal arbeidskatalog er grunnen til at «undersøk hvorfor spørringen returnerer tomt» blir en ekte oppgave og ikke en promptøvelse.
3. Frigjør portene 54321 til 54329 og stopp lokale Supabase-stacker før du kjører selv. Sandkassen bruker vertsnettverk, så en kjørende stack kolliderer direkte.

Verdien for deg som ikke bruker Supabase ligger i formen, ikke i tallene. Dette er en leverandør som publiserer testene sine på feilene folk faktisk melder inn, inkludert de pinlige: feil grants, manglende update-policy på storage, migreringshistorikk som ikke stemmer. Repoet har 52 stjerner og 19 åpne issues, altså tidlig nok til at taksonomien fortsatt er i bevegelse.