Aviator Verify, la revisione codice che affida la verifica agli agenti ma il giudizio resta umano
Testo scritto con l’intelligenza artificiale a partire da una fonte citata, senza revisione umana prima della pubblicazione.
Verify codifica regole ripetitive come invarianti, cattura intento e decisioni dalla sessione di coding e consegna la decisione finale a una persona.
Molte squadre puntano un modello sul diff, poi un umano scorre il riassunto e clicca Approva. Aviator cambia l’assetto: gli agenti verificano, le persone decidono1.
Il modello legge ogni riga e non si stanca, ma non conosce gli standard del tuo codice. Non vede le decisioni passate. Non può dirti di non costruire una cosa. Non risponde di ciò che approva. Il diff non gli dà intenzione né responsabilità. “Il giudizio richiede un intento, e la responsabilità richiede una persona”1.
Verify costruisce un flusso in sette parti. Due strati lo sostengono. I criteri di accettazione dicono cosa deve fare la modifica. Le invarianti fissano le regole della tua organizzazione tecnica, sempre valide. Senza invarianti, i team affidano gli standard alla memoria. Senza criteri, il codice segue le regole ma sbaglia obiettivo o sovraingegnerizza. L’agente verifica su entrambi, poi un umano decide1.
Le invarianti sono regole scritte una volta e verificate su ogni cambiamento. Esempi: usa il tipo Money per le valute. Niente scritture dirette sulla tabella users. Ogni percorso di errore emette un contatore. Verify pesca queste regole dalla storia delle pull request: legge i commenti su GitHub, trova i pattern e propone bozze. Le propone anche da CONTRIBUTING.md, da file di istruzione per agenti come CLAUDE.md, o quando qualcuno tagga @aviator invariant in un commento su una PR o in Slack. Puoi generare le invarianti del team con l’account gratuito di Aviator Verify e tenerle anche se smetti di usare Verify1.
Perché le invarianti aiutino, servono tre vincoli. Ownership: ogni bozza va al team proprietario con il motivo, e diventa attiva solo dopo l’approvazione umana. Wording: descrivi l’esito, non l’implementazione, così la regola sopravvive a rinomini e spostamenti. Scope: esegui la regola solo dove può rompersi. Un’invariante frontend non controlla una migration del database1.
L’intento e i criteri di accettazione non si scrivono in un documento separato. Verify li cattura dalla sessione di coding. Un’abilità dell’agente e un hook eseguono verify submit prima dell’apertura della pull request. L’agente estrae intento e criteri da ciò che ha visto. L’ingegnere rivede e corregge prima dell’invio1.
Le decisioni centrali arrivano insieme all’intento. Sono i bivi dove la modifica poteva andare altrove: dove vive lo stato, cosa accade se fallisce una dipendenza, quando riusare un helper o scriverne uno nuovo. Verify registra le scelte e indica chi le ha prese, umano o agente. Il revisore vede la sequenza di decisioni e può discuterle. “Un PR scritto da un’AI è pieno di scelte come queste, e quasi nessuna appare nel diff”1.
Il piano di test nasce alla submit. I criteri e le invarianti pertinenti diventano scenari. Ogni verdetto porta evidenze, raccolte in un ambiente in esecuzione. La generazione e la verifica restano separate: l’istruzione a un agente non prova che l’agente l’abbia seguita. La verifica deve essere deterministica o affidata almeno a un agente diverso che produce un responso per ogni regola1.
La revisione la fa una persona. Valuta intento, decisioni ed evidenze, non codice. Dopo il merge, le invarianti si aggiornano: deroghe e commenti ricorrenti diventano regole migliorate1.
Le invarianti diventano un AI slop registry, l’elenco dei pattern che il team corregge di continuo1.
Fonti
Come è nato questo articolo Scritto da un sistema di intelligenza artificiale, con controlli automatici
Millebit non ha giornalisti che scrivono gli articoli: li scrive un motore editoriale basato su modelli di intelligenza artificiale, a partire dalle fonti elencate qui sopra. Prima di uscire, ogni testo passa questi controlli:
- Rilettura. Un passaggio toglie i tic della prosa generata da un modello, come i contrasti costruiti e le frasi che annunciano invece di informare, senza toccare fatti e fonti.
- Fedeltà alle fonti. Un passaggio dedicato toglie ogni affermazione che le fonti non sostengono. Valutazione su questo pezzo: 9,5/10.
- Anti-cliché. Un filtro scarta frasi fatte, enfasi e tic della prosa artificiale: superato.
- Giudizio editoriale. Un modello valuta il pezzo su sette criteri (apertura, chiarezza, economia, concretezza, voce, struttura, fedeltà) e sotto 7,8/10 non si pubblica. Questo articolo ha preso 8,1/10.
I controlli riducono gli errori ma non li eliminano: un modello può fraintendere una fonte. Per le decisioni importanti, risali alla fonte originale. Se trovi un errore, segnalacelo.
Per vedere Millebit nelle notizie principali di Google, aggiungilo alle tue fonti preferite. Oppure segui l’edizione di oggi, il feed RSS o La Sintesi.