Un ingegnere Google si è iscritto a Surmado Code Review la settimana scorsa. Il prodotto gira su Scout, il nostro AI research analyst. Ha scritto un file STANDARDS.md per il suo progetto, ha aperto la sua prima pull request e ha fatto girare Scout.
Scout ha segnalato un difetto architetturale critico che avrebbe rotto la produzione.
Non ha fatto il merge. Ci ha scritto via email per descrivere il suo workflow:
“Prendo il feedback da Surmado, lo copio in Gemini. Gemini si autoflagella, e poi mi dà un nuovo prompt da usare con Gemini Code Assist nel mio IDE. Gemini Code Assist fa le modifiche. Aggiorno il branch e Surmado fa la nuova revisione automatica. E poi quando ho esaurito il loop, solo allora taggo i miei collaboratori per la revisione.”
Rileggi quella frase. C’è un loop dentro che vale la pena nominare.
Il loop
- Gemini Code Assist scrive il codice nel suo IDE.
- Surmado lo revisiona rispetto al suo
STANDARDS.md. - Lui incolla la revisione di Surmado nella chat di Gemini.
- Gemini legge il verdetto di Surmado e riscrive il prompt per sé stesso.
- Code Assist rigenera il codice con il nuovo prompt.
- Lui pusha il nuovo branch. Surmado fa la nuova revisione automatica.
- Quando esaurisce il loop, tagga i suoi collaboratori umani.
L’ultimo passo è quello su cui torniamo sempre. Il loop non sostituisce la revisione umana. Fa sì che la revisione umana entri in gioco solo quando serve davvero. Quando un umano guarda la PR, le cose ovvie sono già sistemate. I difetti architetturali, le violazioni degli standard, le cose che un lettore attento coglierebbe in un martedì pomeriggio stanco. Spariti. Al revisore umano restano le parti che hanno davvero bisogno di un umano: trade-off di design, intento, giudizio.
Quella è la versione di IA nel loop di sviluppo che funziona davvero. Non “l’IA sostituisce gli umani.” L’IA gestisce la parte che converge. Gli umani gestiscono la parte che decide.
Cosa ha detto Gemini
L’ingegnere ha incollato la revisione di Surmado in Gemini due volte durante la sessione. Entrambe le volte, Gemini si è trovato d’accordo con Surmado all’istante.
La prima risposta:
“Surmado ha appena beccato un difetto architetturale critico che avrebbe rotto il tuo sito di produzione, e l’ha segnalato citando direttamente il file
STANDARDS.mdche abbiamo scritto 20 minuti fa. Non dovresti assolutamente fare il merge di questa PR adesso. Ecco esattamente cos’è successo e perché Surmado ha ragione su tutta la linea.”
La seconda:
“Surmado ha trovato una falla nella nostra esecuzione e, francamente, ho fatto un pessimo lavoro con il prompt che ti ho dato per Code Assist.”
Quella seconda citazione è quella su cui torniamo sempre. Gemini non ha dato la colpa al modello. Gemini ha dato la colpa al prompt. Le istruzioni che Gemini ha dato a Code Assist non includevano le convenzioni del team, perché Gemini non sapeva quali fossero le convenzioni del team.
Surmado lo sapeva, perché l’ingegnere le aveva scritte venti minuti prima. STANDARDS.md è il ponte tra ciò a cui il team tiene e ciò su cui il modello può agire.
Perché questo è il prodotto
La maggior parte degli strumenti di code review IA controlla le best practice generiche. Indenta il codice. Non fare shadow delle variabili. Evita i magic number.
Quello è il minimo sindacale. Lo fa qualunque linter. Il motivo per cui i team continuano a fare il merge di codice cattivo è che i bug che fanno male in produzione non sono generici. Sono specifici di come costruisce il team. Sono le cose nel tuo wiki, nei tuoi documenti di design, le convenzioni che vivono nelle teste di tre senior engineer.
STANDARDS.md è dove metti tutto questo. Scout lo legge. Ogni PR viene revisionata rispetto a quel file. Ogni rerun legge il nuovo diff e la revisione precedente, così Scout può capire se i problemi precedenti sono stati risolti.
Il loop dell’ingegnere funziona perché ogni pezzo fa quello in cui è bravo. Gemini scrive il codice. Surmado lo controlla rispetto alle regole del team. Gemini si autocorregge quando riceve feedback dall’esterno. Gli umani revisionano quello che resta. L’integrità viene dal loop, non da un singolo modello.
Com’è davvero la sensazione
Ecco come ha descritto i suoi tentativi precedenti con i progetti web:
“Mi entusiasmavo per le righe di codice generate e poi aspettavo, su di giri di aspettativa, di vedere la mia creazione prendere vita, solo per restare davvero deluso quando inevitabilmente si rompeva.”
Chiunque abbia provato a vibe-codare un progetto vero conosce questa parabola. L’entusiasmo. L’aspettativa eccitata. Il crash.
Poi questo:
“Stasera no però. Ho committato due PR che facevano esattamente quello che mi ero prefissato di fare.”
Quella è la differenza. Non “l’IA ha scritto il codice.” Non “l’IA ha revisionato il codice.” Un loop che converge verso software funzionante, con un checkpoint umano alla fine quando serve.
L’inquadratura che ci piace
La maggior parte degli strumenti IA si posiziona contro gli umani. “Più veloce di un revisore umano.” “Becca cose che gli umani perdono.”
Surmado si posiziona in mezzo alle IA. Non più veloce di Gemini. Non più intelligente di Claude. Il modello che ha scritto il codice non sa a cosa tiene il team. Il modello che l’ha revisionato sì, perché qualcuno l’ha scritto.
Ecco com’è fatto un prodotto di orchestrazione. L’LLM non è il prodotto. Il modo in cui l’LLM è cablato alle regole reali del tuo team è il prodotto.
L’ingegnere l’ha riassunto nel suo ultimo messaggio: “Molto colpito. È anche integrato così perfettamente nel flusso.”
È quello che stiamo costruendo.
Due click. Poi funziona e basta. 15$ al mese per 100 PR. Non guardiamo mai il tuo codice. Nemmeno i frontier lab che usiamo lo fanno.