Supabase har frigivet Evals som open source – et benchmark og evalueringsframework, der kører AI-kodningsagenter på konkrete Supabase-opgaver og scorer dem. Ikke demoøvelser, men opgaver udviklere håndterer til daglig. Der følger en offentlig leaderboard på supabase.com/evals og en dagligt overvåget regressionssuite. Kombinationen er praktisk, og timingen passer, nu hvor AI-agenter sniger sig ind i CI.
Udgivelsen er ifølge primærkilden under Apache-2.0 og kan køres lokalt via pnpm. Klart signal om licens og brugbarhed. Lokalt kræves Docker og frie porte 54321–54329 samt nøgler til de valgte modeludbydere. Det lyder ligetil. Alligevel er det ofte her, en pipeline vælter første gang.
Hvad der faktisk bliver testet
Evals kører agenter som Claude Code, Codex og OpenCode op mod rigtige Supabase-opgaver. Eksemplerne er lige ud ad landevejen: bygge et databaseskema, fejlfinde en Edge Function, rette en ødelagt RLS‑politik. Typiske fejl og ændringer fra drift og udvikling. Ifølge kilden er scenarierne udvalgt fra supporttickets, bugreports og GitHub‑issues. Man kan næsten høre den fredag eftermiddag, hvor en prod‑incident skal lukkes hurtigt.
Testen har to spor: et offentligt benchmark, der dækker bredde, og en regressionssuite, der kører dagligt mod kendte fejltyper uden at påvirke de publicerede benchmark-scores. Den opdeling gør det muligt både at sammenligne agenter og holde kvaliteten stram i dagligdagen.
Sådan er scenarierne modelleret
Supabase beskriver tre dimensioner for udvælgelsen: produkter, emner og faser. Produkter spænder fra database og auth til storage, edge‑functions, realtime, cron, queues, vectors og data‑api. Emner dækker RLS og sikkerhed, migrationer, SQL, SDK, observability, self‑hosting, tests og deklarative skemaer. Faserne er build, deploy, investigate, resolve. Tanken er at dække hver dimension mindst én gang med et minimalt, men realistisk scenarie.
Det bevidst småt. Små, målbare scenarier er lettere at reproducere – og at fejlfinde, når en agent træder ved siden af. Forankringen i virkelige hændelser skærer pyntet væk.
Arkitektur og reproducerbarhed
Hvert scenarie kører mod et realistisk miljø. Frameworket booter en hosted‑lignende stack og et lokalt CLI‑projekt i containere, så agenterne ringer til den faktiske MCP‑server og Supabase‑CLI. Det mindsker afstanden mellem test og virkelighed, og fejlene bliver mere ærlige.
Der følger en platform‑lite runtime, som eksponerer en Management API‑kompatibel flade bakket af @supabase/lite. I praksis kan mange API‑kald og workflows testes uden hele den fulde platform, men med kompatibel adfærd. For lokale kørsler kræves Docker, udbyder‑API‑nøgler og frie porte 54321–54329. Netop de miljødetaljer løfter reproducerbarhed fra håb til metode.
Mappestruktur og udvidelse
Hvert eval‑scenarie har en enkel struktur: PROMPT.md med opgaven og frontmatter, EVAL.ts som selve scoreren samt valgfri remote/ og local/ starttilstande. Angiver man interface som cli, eller leverer en local/ workspace, spinner Evals et Docker‑sandbox med Supabase‑CLI’en på plads. Det gør det nemt at pakke virksomhedsinterne fejlscenarier som små, bærbare testpakker.
At kunne lægge domænespecifik kontekst i PROMPT.md og have EVAL.ts som single source of truth for scoring gør vedligehold let – også om et halvt år, når teamet har skiftet bemanding.
Scoring og kvalitetskontrol
Scoringen kombinerer deterministiske checks og LLM‑as‑a‑judge. Hver agent får én retry før bedømmelse. De deterministiske checks kan være alt fra SQL‑resultater og policy‑match til filsystemets endelige tilstand. LLM‑dommeren håndterer semantiske vurderinger – fx om en fejlrapport forklarer årsagen, eller om en migrationsbeskrivelse matcher ændringen.
Vigtigt for læseren: kilderne beskriver ikke, hvordan LLM‑dommeren er kalibreret eller vægtet mod de deterministiske checks. Der er ingen dokumentation for brug af menneskelige annotatorer, prompt‑arkitektur eller vægtning på tværs af scenarier. Afklar det med maintainerne, før I baserer produktionsgates på scores fra LLM‑vurderinger.
Public leaderboard og regressionskørsel
Evals driver et offentligt leaderboard på supabase.com/evals, mens regressionssuiten køres dagligt separat. De publicerede scores flytter sig ikke med regressionerne, hvilket bevarer sammenligneligheden over tid. God disciplin – men uden klar vægtning mellem deterministiske checks og LLM‑judge bør tophits læses med forbehold.
Hvorfor det betyder noget for CI og udvikling
Teams kan bruge Evals som release‑gate. Et pre‑merge‑step kan vælge relevante scenarier efter ændringstype: rører man RLS, kører RLS‑scenarierne; rører man SDK, kører SDK‑ og migrationsscenarier. Falder en agent eller et script igennem, blokeres merge. Enkelt i idé – kræver omhu i scenarieudvælgelse for at undgå støj.
Dokumentation og SDK‑ændringer kan også regressionstestes. Mange fejl opstår i spændet mellem kode og docs. Her kan Evals løbende køre små, realistiske “kan brugeren gøre X?”‑checks. Effektivt, og det viser hvor hurtigt semantiske forskydninger kan snige sig ind.
Sikkerhed og RLS i virkeligheden
I regulerede miljøer som fintech eller healthcare er RLS‑politikker reelt compliance. En automatisk ændring, der åbner for bredere adgang end tiltænkt, er en hændelse. Evals kan hjælpe ved at køre deterministiske queries, der bekræfter, at kun de forventede rækker er synlige for givne roller. LLM‑dommeren kan supplere ved at vurdere, om ændringsbeskrivelsen matcher implementeringen.
Men Evals er ikke hele svaret. Statiske analyser, manuelle code reviews og miljøspecifikke integrationstests er fortsat nødvendige – især med følsomme data eller komplekse krydsafhængigheder. Et framework tester meget, men kender ikke jeres forretningslogik i hjørnerne.
Hands on implementering
Hvis I vil køre Evals lokalt eller i CI, så gør klart hvad der skal være på plads. Gør det konkret og tørt – det sparer tid senere.
- Docker daemon på build‑agenten
- pnpm installeret
- Frie porte 54321–54329
- Provider API‑nøgler som CI‑secrets med minimalt scope og plan for rotation
- Lås Docker‑version og pin modelversioner
Undgå falske positiver/negativer ved at isolere netværk hvor muligt, cache containerbaser og køre et kontrolscenarie som røgalarm ved hver kørsel. Hvis kontrolscenariet fejler, er det miljøet – ikke agenten.
Mål performance og omkostninger
Kilderne oplyser ikke tal for tid pr. scenarie, CI‑ressourcer eller pris. Det gør vurderingen åben. Foreslået pilot: vælg tre scenarier, kør dem dagligt i en uge, og mål tid pr. scenarie, CPU/memory‑forbrug og flakiness (pass‑rate over tid). Brug tallene til at sætte realistiske SLO’er og budgetvagter.
Vægt scoring for driftssikkerhed
Hold deterministiske checks øverst, især for sikkerhed og RLS. Eksempler: sammenlign SQL‑resultater mod forventede datasæt, verificér policy‑match for specifikke roller, og kontroller sluttilstand i filsystemet. Læg LLM‑vurderinger som supplement til forklaringskvalitet og dokumentationsmatch. I CI kan det operationaliseres som procentvægtning og fallback til manuelt review ved tvivl.
Begrænsninger og åbne spørgsmål
Der mangler klarhed om træning og kalibrering af LLM‑dommerne. Uden metodeindblik er robustheden svær at vurdere for nuancerede opgaver. Der er også uklarhed om den præcise vægtning bag de offentliggjorte leaderboard‑scores. Afklar begge dele med maintainerne, før I bruger scores som hårde gates.
Performance og omkostning er ikke belyst: tid pr. scenarie, resourceforbrug i CI, og om regressionssuiten skalerer til enterprise‑omfang. Håndtering af hemmelige nøgler og mønstre for sensitive data i scenarier er heller ikke beskrevet i detaljer. Indhent svar i supabase/evals‑repoet eller direkte hos Supabase, og verificér gerne live‑repoet ved publicering.
Kontekst og sammenligning
Der findes andre forsøg på at få AI‑agenter ind i strukturerede workflows. Et aktuelt eksempel er DataFlow‑Harness, som i en uafhængig gennemgang rapporterer en høj pass‑rate for data pipelines ved at styre agenten gennem en struktureret, visuel proces i stedet for fri kode. Pointen er generel: fri kode er hurtig, men sårbar; et harness gør det styrbart. Supabase Evals lægger sig i den lejr for backend og infrastruktur med en reproducerbar bund.
Det særlige her er koblingen til Supabase‑økosystemet og til reelle driftsscenarier. Evals tester ikke kun, om en agent kan skrive SQL. Den tester, om kæden fra CLI til hosted‑lignende miljø opfører sig forudsigeligt. Det er ofte her, AI‑eksperimenter ellers knækker.
Hvad man skal gøre nu
Start småt. Vælg tre scenarier med høj konsekvens og moderat kompleksitet – fx en migration, en RLS‑rettelse og en Edge Function‑debug. Få dem til at køre deterministisk i jeres CI, lås miljøet, og mål tid og flakiness over en uge. Først derefter giver det mening at udvide dækningen og koble på merge‑gates.
Fortolk leaderboard‑placeringer varsomt: brug dem som pejlemærker, ikke facit. Den vigtigste måling er pass‑rate og stabilitet i jeres egen stack med jeres datamodeller. Pak jeres hyppigste supportscenarier ind i Evals‑formatet og kør dem som daglige regressioner. Link til repoet for implementering: github.com/supabase/evals.
En lille detalje til sidst: de faste porte 54321–54329. Små, faste beslutninger gør opsætningen forudsigelig og dokumentationen enklere. Man mærker det først, når man står midt i det.
