AI & MCP
Valutare un modello per il codice: fixture, gate e costo per attività riuscita
Un modello per il codice si sceglie con una fixture tua, un gate che passa o fallisce e il costo per attività riuscita. I benchmark pubblici non bastano.
In sintesi
- La metrica utile è il costo per attività riuscita, non il punteggio medio su un benchmark pubblico.
- La fixture deve venire dal tuo repository e avere un gate eseguibile: build, tipi, test.
- Conta anche il tasso al primo tentativo, perché ogni retry moltiplica i token di input.
Un modello per il codice si valuta con una fixture presa dal tuo repository, un gate che passa o fallisce e il costo per attività riuscita. Un punteggio medio su un benchmark pubblico risponde a un'altra domanda.
La metrica che sopravvive al cambio di modello
La metrica utile è una frazione con due numeri veri: costo totale diviso attività riuscite. Il costo totale si legge dalla risposta dell'API, campo usage; le attività riuscite le decide il tuo gate, non il modello che dice di aver finito. Se cambi fornitore, la frazione resta confrontabile anche quando i token per attività cambiano.
Costruire la fixture in un pomeriggio
- 20 attività prese da bug veri e già chiusi: hai il diff atteso e nessuno deve inventarlo.
- Un gate per attività:
npm run build,tsc --noEmito un test che falliva prima e passa dopo. - Un limite di tempo e un limite di file toccati, altrimenti un agente riscrive il repository per far passare un test.
- Il prompt nudo: nessun aiuto nel testo, perché un buon prompt nasconde un modello debole.
Il gate eseguibile
npm run build && npx tsc --noEmit -p client/tsconfig.jsonNel repository EneUI npm run build esegue la build del client, il controllo di sintassi e la minificazione CSS. Un gate così non chiede al modello di autovalutarsi: o il processo esce con 0, o l'attività è fallita. Il comando va lanciato su una copia pulita, perché una build che trova artefatti vecchi può passare per motivi sbagliati.
Le tre colonne del foglio di calcolo
| Colonna | Come si ottiene | Perché conta |
|---|---|---|
| Attività riuscite | gate con exit code 0 | esclude le risposte plausibili ma rotte |
| Tasso al primo tentativo | retry dichiarati nel log | ogni retry rimanda il contesto e raddoppia i token |
| Costo per attività riuscita | somma di usage diviso riuscite | confronta modelli con prezzi e verborragia diversi |
| File toccati | diff prima e dopo | un fix che cambia 40 file è una regressione futura |
Prezzo e token: due numeri separati
Un modello economico per token può costare più caro per attività se scrive tre volte tanto o se sbaglia al primo colpo. Un modello caro può convenire quando chiude al primo tentativo su un repository grande. La differenza tra i due listini letti il 1 novembre 2026 è di due ordini di grandezza sull'input, quindi il tasso di successo deve essere misurato, non stimato.
La limitazione
La nostra fixture misura 60 file e 13.924 righe: è un progetto piccolo, e un modello che eccelle qui può perdersi in un monorepo da 400 pacchetti. I benchmark pubblici hanno il problema opposto, perché i loro task sono spesso già visti in addestramento. Nessuno dei due numeri predice il tuo caso: la fixture va rifatta quando il repository cambia forma.
Dove continuare
Il costo dei token in un contesto lungo è in contesto lungo: costi reali, e l'ordine dei passi in orchestrare agenti multi-step. Per i rischi di un agente che scrive sul disco leggi sicurezza di un agente di coding, e per la scelta tra interfacce già pronte la rassegna generatori di UI con AI. La fixture può partire dal catalogo: 111.985 componenti, 1.556 blocchi e un record con licenza MIT dichiarata come agent dock di dqnamo.
Domande frequenti
Quante attività servono per una fixture credibile?
Venti bastano per vedere differenze grandi, cioè un modello che chiude al primo colpo e uno che non chiude. Con meno di dieci il rumore copre il segnale, con più di cinquanta il costo di preparazione supera il beneficio.
Posso usare un benchmark pubblico come primo filtro?
Sì, per escludere i modelli che non sanno scrivere codice. Non serve a scegliere tra i primi cinque, perché i task pubblici sono noti e il formato del prompt è diverso dal tuo. La fixture decide, il benchmark orienta.
Come conto i token senza dipendere dal fornitore?
Leggi il campo usage di ogni risposta e sommalo: è l'unico numero che paghi davvero. La stima a quattro caratteri per token serve al massimo per un preventivo, non per un confronto.
Il tasso al primo tentativo vale più del costo?
Dipende dal tempo umano. Un retry automatico costa token, un retry che rileggi tu costa anche attenzione. Se il tuo collo di bottiglia è la revisione, misura le revisioni per attività e non i token.
Che cosa rende una fixture inutile?
Un gate che il modello può modificare. Se l'agente può cambiare il test o il tsconfig, il risultato è una dichiarazione, non una misura. Il gate deve stare fuori dalla cartella su cui l'agente scrive.