Supabase Evals — Benchmark su Agenti con Backend Reale

Intermedio

Le classifiche dei coding-agent misurano quasi sempre diff di pull request contro una suite di test — SWE-Bench e cugini. È utile, ma non è quello che un utente Supabase fa davvero: costruire uno schema, sistemare una RLS rotta, debuggare una Edge Function che fallisce, cablare l'auth. Il 1 agosto 2026, Supabase ha rilasciato open-source un benchmark che valuta i coding agent su quei task reali, facendoli girare contro stack Supabase reali in container con server MCP e CLI reali. È Apache-2.0, gira in locale su un laptop, e i primi punteggi dicono già qualcosa di sorprendente su come i vari agent usano la documentazione. Questa pagina è la guida pratica sul campo.

What you'll learn

• Capire cosa rende Supabase Evals diverso dai benchmark stile SWE-Bench
• Leggere onestamente i risultati cross-agent — dove Opus 5, Sonnet 5, Kimi K3 e la linea GPT-5 divergono davvero
• Vedere l'effetto del caricamento delle skill sullo stesso modello (prima vs dopo)
• Far girare il benchmark tu stesso contro il tuo agente e modello in meno di un'ora

Ultima verifica: 2026-08-03.

La tabella dei punteggi, il conteggio degli eval e gli effetti delle skill in questa pagina riflettono la leaderboard e il README al momento del rilascio del 1 agosto 2026. I punteggi live su supabase.com/evals si aggiornano man mano che arrivano nuovi modelli ed esperimenti; la forma del benchmark (stack reali, scoring deterministico + LLM-judge, un solo retry) è duratura, le percentuali specifiche no.

Conferma confrontando con la fonte ufficiale.

Cos'è davvero Supabase Evals

Supabase Evals è un benchmark, un harness di valutazione e una leaderboard pubblica riuniti in un unico repo Apache-2.0 su github.com/supabase/evals. Esiste perché i test in stile SWE-Bench rispondono alla domanda sbagliata per il lavoro backend — misurano "questo agente sa chiudere un'issue GitHub contro una test suite Python" — mentre il vero lavoro Supabase è più vicino a ops su un sistema in esecuzione: la tua policy RLS ha iniziato a rifiutare richieste valide, la tua Edge Function fa 500 in prod, la migration non è passata.

Tre cose lo separano da ciò che c'era prima:

• Stack reali, non mock. Ogni scenario avvia una sandbox Docker fresca che monta il socket Docker dell'host, così supabase start fa partire lo stack locale come container fratelli. L'agente parla con una superficie compatibile Management-API (@supabase/lite) e con server MCP e la CLI Supabase reali. Nulla è stubbato.
• Prima check deterministici, LLM-as-judge solo dove serve. Uno scorer può interrogare il database risultante, colpire la Edge Function deployata o eseguire vitest a livello di repo sui file prodotti. Il judge LLM è un backup per risposte in formato libero ("la spiegazione dell'agente combaciava con la vera causa?"), non la valutazione primaria.
• Un retry, poi è finale. Nessun best-of-N cherry-picked. Solo questo rende i numeri meno lusinghieri rispetto ai benchmark PR agent più comuni.

La griglia degli scenari

Il rilascio di agosto 2026 spedisce 38 scenari eval sotto evals/<id>/. Sono organizzati su tre assi così i risultati si possono affettare in modo significativo:

• Nove prodotti — database, auth, storage, edge functions, realtime, cron, queues, vectors, data-api
• Nove topic — RLS, security, migrations, SQL, SDK, observability, self-hosting, tests, declarative-schema
• Quattro fasi — build (creare qualcosa di nuovo), deploy (spedirlo), investigate (capire cosa non va), resolve (aggiustarlo)

Ogni eval è una directory con un PROMPT.md (il task che l'agente vede, più metadata nel frontmatter), uno scorer EVAL.ts, e opzionalmente remote/ (stato del progetto hosted seedato — SQL, log, function già deployate) e local/ (file di partenza copiati nel workspace sandbox dell'agente). Gli scenari vengono da ticket di supporto reali e issue GitHub, non da prompt sintetici.

Due runtime, scelti per ogni eval

Ogni eval gira in una di due modalità, decisa automaticamente dalla sua forma:

• Tools mode. Nessuna sandbox. L'agente riceve una superficie MCP/tool (Management API, SQL, storage, ecc.) e la sua risposta viene valutata ispezionando lo stato risultante del progetto. Usata per eval che vivono interamente dentro la piattaforma (nessuna directory local/, nessun interface: cli).
• Local-stack mode. Una sandbox Docker fresca con la CLI Supabase reale installata. L'agente riceve un tool bash più i file tool, e può eseguire supabase init/start/db/test contro uno stack locale reale che nasce come container fratello. Dopo che l'agente si ferma, l'harness fa docker cp del workspace fuori ed esegue vite/vitest dall'host per valutarlo. Usata quando esiste un workspace local/ o è dichiarato interface: cli.

Il colpo di genio: la toolchain dell'host valuta ciò che la sandbox ha prodotto. Gli scorer non devono vivere dentro l'immagine sandbox.

Risultati cross-agent (agosto 2026)

I run iniziali della leaderboard mettono gli agent first-party (Claude Code, Codex, esperimenti executor Claude API) contro OpenCode model-agnostic sulle linee Claude Opus 5, Claude Sonnet 5, Kimi K3 e GPT-5.4/5.6. I numeri sotto sono per la fase build, dove il post iniziale riporta i risultati più netti.

Agente + modello	Build (senza skill)	Build (con skill)
Claude Code + Opus 5	100%	100%
OpenCode + Kimi K3	100%	100%
Claude Code + Sonnet 5	78%	100%
Codex + GPT-5.6 (Sol)	89%	100%
Codex + GPT-5.4 mini	78%	89%

Due cose spiccano:

• Opus 5 e Kimi K3 saturano build senza aiuto. Kimi K3 via OpenCode che eguaglia Opus 5 via Claude Code è un segnale reale sul fatto che i modelli open-weight stanno raggiungendo il livello sul lavoro backend — non una rivendicazione generale di SOTA, ma una specifica e riproducibile.
• Le skill sono un grande moltiplicatore sui modelli mid/piccoli. Caricare la skill Supabase porta Sonnet 5 dal 78% al 100% su build, e porta l'hit rate della skill Postgres-best-practices da ~10% al 60% sull'intera suite. Se stai usando Sonnet 5 (o qualsiasi modello mid), non caricare la skill rilevante significa lasciare 20+ punti sul piatto.

La scoperta che nessuno si aspettava: i modelli usano le doc in modo molto diverso

Il numero più interessante del rilascio non è uno score, è un comportamento:

Codex / GPT-5.6 legge circa 8 pagine di documentazione per scenario. Claude Code ne legge circa 2 — e consulta le doc in meno del 40% degli scenari anche con le skill caricate.

I due agent guardavano gli stessi task, gli stessi tool MCP e le stesse skill. Codex tira giù documentazione per riflesso prima di agire; Claude Code prova più spesso a memoria e legge le doc solo quando sbatte contro il muro. Nessuno dei due è "giusto" — Opus 5 via Claude Code ha comunque preso 100% su build. Ma è un modo operativo molto diverso, e spiega molti report aneddotici sui due agent che sembrano diversi.

★ Insight ─────────────────────────────────────

• I report dei benchmark di solito collassano un agente in un unico numero. Supabase Evals è insolitamente prezioso perché strumenta il comportamento dell'agente — con che frequenza legge le doc, quali skill ha caricato, quanti tool ha chiamato — e spesso il comportamento è la storia, non lo score.
• Il gap qui non è un model gap, è un gap di policy dell'harness. Lo stesso modello base in un harness diverso probabilmente si comporterebbe diversamente. Vedi Coding Agent CLI a Confronto per capire perché l'harness conta almeno quanto il modello.
• Scorer deterministici più un retry (no best-of-N) è ciò che rende i numeri qui comparabili fra gli agent. La maggior parte delle leaderboard agent pubbliche permette silenziosamente retry o self-consistency, il che favorisce i modelli più lenti/deboli. ─────────────────────────────────────────────────

Tre inciampi ricorrenti in tutti gli agent

Indipendentemente dal modello, ogni agente testato è inciampato sugli stessi tre pattern:

• Scrivere migration a mano invece di usare gli schema dichiarativi. Il workflow declarative-schema è più recente; i dati di training sono pieni di migration vecchio stile create table, così gli agent ci ricadono di default anche quando il progetto è impostato per declarative.
• Verificare l'auth a mano invece di usare @supabase/server. Gli agent cablano parsing dei cookie e session check a mano invece di usare gli helper server-side più recenti che esistono esattamente per questo.
• Consultazione delle doc incoerente. Come sopra — lo stesso agente cercherà nelle doc in uno scenario e proverà a memoria nel successivo, senza una regola ovvia sul quando.

Sono il tipo di fallimenti che non emergono nel pass@1 su un benchmark sintetico, perché non c'è una risposta "sbagliata ma funzionante" da valutare — il codice compila, usa solo il pattern superato. Gli eval con container reali li catturano perché uno scorer può ispezionare il progetto prodotto e verificare "hanno usato declarative schema, sì/no."

Farlo girare in locale

Ti servono Docker, pnpm e una API key del provider che vuoi valutare. Le porte 54321–54329 devono essere libere (ferma prima qualsiasi stack locale supabase start). Il tutto gira su un laptop; un run piccolo finisce in minuti.

Guided walkthrough1 of 5

1. Le skill vivono in un submodule — un clone semplice ti lascia senza le skill agent Supabase. Usa --recurse-submodules la prima volta.

Clona il repo con i submodule

git clone --recurse-submodules https://github.com/supabase/evals.git
cd evals
pnpm install
cp .env.example .env

Esegui un singolo eval contro un singolo esperimento

pnpm eval -- \
--eval resolve-dataapi-001-empty-results \
--experiment claude-code-sonnet-5

Testa a testa: stesso modello, skill on vs off

pnpm eval -- \
--experiment claude-code-sonnet-5 \
--experiment claude-code-sonnet-5-no-skills \
--suite benchmark

Sweep completa del benchmark su tutti gli esperimenti spediti

pnpm eval -- \
--suite benchmark \
--experiment-suite benchmark,no-skills

pnpm export-results
pnpm web

Anatomia di un esperimento (per aggiungere il tuo)

Un file esperimento sotto experiments/<name>.ts è dove cabli un agente, un runtime e un modello in un'unica configurazione comparabile. Quella separazione è deliberata: significa che "Claude Code con Sonnet 5 e senza skill" è un esperimento diverso da "Claude Code con Sonnet 5 e skill caricate", ed entrambi sono diversi da "OpenCode con Kimi K3". Puoi tenere costanti due assi su tre e variare il terzo.

Le varianti -no-skills spedite nel repo (es. claude-code-sonnet-5-no-skills.ts vs claude-code-sonnet-5.ts) sono ciò che rende misurabile la claim "le skill ci hanno portato dal 78% al 100%" invece che una vibe.

Se stai facendo girare un agente custom — un loop fatto in casa, un fork interno, un harness sperimentale — il pattern è: scrivi un file esperimento che dichiari il tuo agente, opta per localStack: localStackRuntime() se vuoi anche gli eval sandbox, e fallo girare contro la suite benchmark. I tuoi numeri finiscono nella stessa tabella di tutti gli altri.

Skill, caricate lazy

Entrambi i runtime usano progressive disclosure per le skill: solo il nome e la descrizione di ciascuna skill sta sempre nel system prompt; l'agente tira giù le istruzioni complete on demand. Ecco perché "skills on" costa solo pochi token extra per turn ma può alzare uno score di 20+ punti — l'agente paga il body di una skill solo quando decide che la skill è rilevante.

I due runtime differiscono solo su come viene recuperato il body:

• Local-stack (sandbox) mode. Le skill sono installate nella sandbox con la CLI skills di Vercel (compilata nell'immagine sandbox, presa dalla directory locale skills/ — mai dalla rete) sotto .claude/skills/. Quando un task combacia, l'agente legge .claude/skills/<name>/SKILL.md e qualsiasi file referenziato con i suoi file tool.
• Tools mode. Nessun filesystem, quindi un tool load_skill restituisce le istruzioni complete di una skill quando l'agente la chiama per nome.

Per contesto sullo standard skill cross-agent emergente che questo usa, vedi SKILL.md come Standard Aperto.

Dove si colloca nella mappa AILmanac

• Il benchmark stesso → questa pagina. Cosa Supabase Evals misura, come, e cosa ha trovato.
• Valutare gli Agent — il playbook generale per misurare qualsiasi coding agent sul tuo stack.
• Coding Agent CLI a Confronto — la metà harness della storia (Claude Code vs Codex vs OpenCode come programmi, indipendentemente da qualsiasi benchmark).
• Claude vs GPT vs Gemini per Coding — la metà modello.

★ Insight ─────────────────────────────────────

• I benchmark come questo sono utili soprattutto direzionalmente, non in assoluto. "Sonnet 5 ha guadagnato 22 punti con la skill Supabase caricata" si trasferisce al tuo progetto; "Sonnet 5 fa 100% su build" non necessariamente.
• La domanda giusta dopo aver letto una leaderboard non è "quale agente ha vinto", ma "cosa testa questo benchmark che assomiglia al mio lavoro" — e poi contano solo i sub-score su quelle fette. ─────────────────────────────────────────────────

Autotest rapido

Check yourself

0/5

1. 1Cosa rende Supabase Evals strutturalmente diverso dai benchmark stile SWE-Bench?
2. 2Il rilascio di agosto 2026 riporta che Codex/GPT-5.6 e Claude Code differiscono nettamente in un *comportamento* sugli stessi scenari. Quale?
3. 3Caricare la skill Supabase alza lo score `build` di Sonnet 5 dal 78% al 100%. Cosa suggerisce più fortemente?
4. 4Vuoi confrontare 'skills on' vs 'skills off' in modo equo per lo stesso modello. Qual è la primitiva giusta in Supabase Evals?
5. 5Quale inciampo *non* è uno dei tre fallimenti consistenti riportati in tutti gli agent testati?

Flashcard

Premi Invio o Spazio per girare la carta. Usa le frecce sinistra e destra per spostarti tra le carte.Termine mostrato.

1 / 7

Fonti e approfondimenti

• github.com/supabase/evals — il repo (Apache-2.0), incluso il README completo da cui questa pagina attinge.
• Introducing Supabase Evals — il launch post con la leaderboard cross-agent iniziale.
• supabase.com/evals — la leaderboard pubblica live.
• github.com/supabase/agent-skills — il submodule skill che il benchmark pinna.
• github.com/supabase/supabase-lite — @supabase/lite, la superficie compatibile Management-API contro cui l'harness gira.
• MarkTechPost — Supabase Releases Evals — riassunto di terze parti del launch.
• Correlati su AILmanac: Valutare gli Agent · Coding Agent CLI a Confronto · SKILL.md come Standard Aperto.