La versione breve
- Stesso repository → Stessi test → Patch verificata.
- Conserva le fonti e verifica il risultato prima di usarlo.
Confronta GPT-6 Sol e Claude Opus 5.5 su una versione fissa del repository. Assegna a entrambi la stessa attività, gli stessi strumenti e le stesse verifiche. Conserva la patch, il registro dei comandi e le note del revisore per spiegare il risultato.
L'articolo fornisce un protocollo di test. Thrive non ha eseguito questo confronto e non pubblica punteggi inventati. Le specifiche ufficiali sono un punto di partenza; il tuo lavoro fornisce le prove per scegliere.
Prepara un confronto equo
Scegli un repository che sei autorizzato a usare e rimuovi i segreti dall'ambiente di test. Registra l'hash del commit e ripristina lo stato iniziale prima di ogni esecuzione. Per un bug, conserva un caso riproducibile che fallisce.
Fornisci le stesse istruzioni, file pertinenti e comandi consentiti. Definisci un limite di tempo o tentativi e i criteri di revisione prima del test. Se un prodotto riceve strumenti di recupero aggiuntivi, annotalo e descrivi la prova come confronto tra processi.
Usa un branch di test. Escludi credenziali di produzione e deployment. L'assistente non dovrebbe inviare messaggi, pubblicare pacchetti o modificare un database live per dimostrare una patch locale.
Prova cinque tipi di attività
Compito | Materiale iniziale | Criterio di accettazione | Campo del risultato |
|---|---|---|---|
Debugging | Un caso riproducibile che fallisce | Corregge la causa e aggiunge una verifica di regressione pertinente | Da registrare dopo l'esecuzione |
Refactoring | Codice funzionante e interfacce stabili | Preserva comportamento e contratti pubblici | Da registrare dopo l'esecuzione |
Test | Un requisito con casi limite noti | Verifica il comportamento e rivela un errore significativo | Da registrare dopo l'esecuzione |
Analisi del repository | Una domanda di architettura circoscritta | Cita file pertinenti e segue il percorso di chiamata reale | Da registrare dopo l'esecuzione |
Documentazione | Un'API o un comando attuale | Gli esempi funzionano sulla versione indicata | Da registrare dopo l'esecuzione |
«Da registrare dopo l'esecuzione» è un'etichetta della scheda, non un risultato di prestazione. Aggiungi attività pertinenti al repository, come verifiche delle autorizzazioni o revisione di una migrazione.
Definisci requisiti e verifiche del compito
Scrivi input, comportamento previsto, vincoli e comando di verifica. Una richiesta utile descrive cosa ha fatto l'utente, cosa è successo e cosa sarebbe dovuto succedere. Includi messaggio di errore o caso riproducibile, se disponibile.
For a fictional application, a task might be: “When a signed-out visitor opens the private resume workspace, send them to sign-in and preserve the requested destination. Signed-in visitors should open the workspace. Keep public resume guidance accessible.” That defines two states and a boundary a reviewer can test.
Chiedi all'assistente quali file intende modificare prima di ampliare il perimetro. Il refactoring deve avere una ragione legata al comportamento richiesto.
Usa il prompt di verifica TypeScript per una revisione e la skill di debugging per un caso basato su un problema riproducibile.
Valuta il risultato senza conoscere il modello
Fornisci al revisore patch con etichette neutre quando possibile. Chiedi di valutare correttezza, perimetro, manutenibilità e verifiche. Mantieni un pareggio se entrambe rispettano i requisiti con uno sforzo di revisione simile.
Esegui la suite di test in un ambiente pulito. Verifica se l'assistente ha indebolito un test, nascosto un errore o cambiato un'impostazione per superare una verifica. Registra errore e correzione proposta come prove separate.
Esamina dipendenze e modifiche ai permessi. Una patch che risolve il difetto ampliando l'accesso può creare un problema più grave. Il revisore deve capire perché ogni modifica sensibile è necessaria.
Calcola il costo dall'uso effettivo
Registra token di input e output, tentativi, costi degli strumenti e tempo del revisore. Usa la tariffa applicabile alla richiesta. Il confronto generale dei modelli spiega le specifiche di base e un esempio aritmetico circoscritto.
Confronta il costo per attività accettata, non solo il prezzo dei token. Un modello può usare più contesto o richiedere più tentativi. Tokenizzatori e livelli di servizio possono cambiare il costo di sessioni simili.
Documenta il risultato e i suoi limiti
Indica ID dei modelli, impostazioni, versione del repository, numero di attività, regole dei tentativi, data e metodo di revisione. Spiega errori e successi. Limita il risultato alle attività testate, senza estenderlo a tutta la programmazione.
Conserva il registro originale. Chi legge deve poter ripetere le verifiche o capire perché un caso fallisce. Ripeti i casi principali dopo modifiche al modello o agli strumenti dell'agente.
I profili O*NET di processo di valutazione dei modelli e griglia di valutazione a coppie può organizzare la revisione. Una versione senza dati identificativi può sostenere una discussione sul portfolio e sulle tue decisioni di test.
Fonti e note di verifica
La redazione Thrive ha esaminato queste fonti il 28 settembre 2026. Abbiamo progettato la scheda, senza compilarla con risultati misurati dei modelli.
Mettilo in pratica
Il prossimo passo
Hai una domanda o una correzione?
Contatta Thrive
