Il problema
Siamo un team piccolo. Cinque persone che costruiscono una piattaforma di IA. In qualsiasi momento abbiamo 14 repository attivi. Questo significa molti PR e non abbastanza persone per revisionarli bene.
Le revisioni stavano richiedendo troppo tempo. Le cose importanti venivano sfiorate. Stavamo consegnando codice più velocemente di quanto riuscissimo a verificarlo.
Così abbiamo costruito il nostro bot di code review. È iniziato come progetto parallelo per risolvere un problema interno. Ora è un prodotto. Surmado Code Review. 15 $ al mese per 100 PR.
Ecco come lo abbiamo costruito davvero. Cosa è stato vibe-coded, cosa no, e il framework che consigliamo a chiunque stia prototipando una pipeline di IA.
Fase 1: Inizio con vibe coding
La prima versione era un agente di riepilogo. Nient’altro. Apri un PR e ottieni un riepilogo in linguaggio naturale delle modifiche. Tutto vibe-coded. Veloce, diretto, con Claude a fare il grosso del lavoro.
Poi abbiamo iniziato a chiederci: può anche trovare bug?
È lì che è diventato interessante.
Fase 2: Il forward-backward pass
Questa è la parte che crediamo valga davvero la pena condividere. È un framework che puoi usare su qualsiasi pipeline di IA, non solo per la code review.
Abbiamo preso un concetto dal training del machine learning: il forward-backward pass. Ma invece di addestrare i pesi di un modello, abbiamo trattato l’intera pipeline come se fosse un LLM.
Funziona così.
Forward pass. Definisci un insieme di input controllati. Nel nostro caso, PR con bug inseriti intenzionalmente. Li fai passare nella pipeline e registri cosa viene rilevato e cosa sfugge.
Backward pass. Analizzi ciò che è sfuggito. Modifichi prompt, struttura e logica di revisione. Poi esegui di nuovo. Questa volta lo rileva? Sono aumentati i falsi positivi?
Ripeti. Ogni ciclo è veloce ed economico. Non stai riaddestrando un modello. Stai iterando su codice, prompt e architettura con feedback immediato su se ha funzionato.
L’intuizione chiave: trasformi Claude Code in un utente sintetico. Gli dai un input atteso e un output atteso. Lo lasci generare altri casi di test e valutare i risultati rispetto alla tua pipeline. Questo è il tuo test harness.
I test harness sono facili da fare in vibe coding. Se hai un’API attiva, puoi costruirne uno in un pomeriggio. Qualcosa di deployato, in container, o anche in locale basta. Definisci i tipi di bug che vuoi che la pipeline rilevi, generi i casi, li esegui e iteri.
Questo era il nostro v1 e v2. Avevamo 10 teorie diverse su come strutturare la logica di revisione. Invece di dibatterle, le passavamo tutte nel harness e lasciavamo decidere ai risultati.
Fase 3: Dove il vibe coding incontra il limite
Attraverso tutta quella sperimentazione, abbiamo trovato il vero sblocco: il grounding tramite standard.
L’agente di revisione è migliorato drasticamente quando ha avuto un documento di standard ben scritto a cui fare riferimento. Le convenzioni di codice reali del team, le nostre decisioni architetturali.
Se fai vibe coding, probabilmente hai già un CLAUDE.md o un .cursorrules. Quello è un contratto di scrittura. Dice all’agente cosa produrre. Ma la maggior parte dei team non ha un contratto di revisione. Non esiste un file equivalente che dica a nessuno, umano o macchina, cosa è accettabile per il merge. È da questa asimmetria che nasce il drift.
Abbiamo scritto uno STANDARDS.md per ogni repository. Una volta che quel file è esistito, l’agente di revisione aveva qualcosa di concreto contro cui confrontarsi. Non best practice generiche. Le nostre opinioni concrete su come costruiamo.
Ma c’è un punto importante. Il documento di standard in sé non poteva essere vibe-coded. Come era formattato, come si integrava nella pipeline, la lingua e la struttura specifiche. Tutto questo richiedeva giudizio umano accurato. Lo abbiamo scritto, testato come lo interpretava l’agente, e rivisto. Quel loop è stato guidato dagli umani.
La productizzazione è stata interamente fatta a mano. Ogni singolo pezzo.
Autenticazione e pagamenti. Cablati deliberatamente. Ci importa proteggere il denaro del cliente.
Stati di errore e rimborsi. Progettati a mano. Quando qualcosa va storto, dobbiamo sapere con esattezza cosa succede e perché.
Privacy. Non negoziabile. Il codice del cliente passa attraverso la nostra pipeline. Questo richiede un’architettura deliberata, non codice generato.
Integrazione con Scout. Scout è il nostro analista di ricerca con IA. Il collegamento tra Surmado Code Review e Scout è stato curato, testato, intenzionale.
Abbiamo anche dedicato tempo significativo al peso dei modelli nella pipeline. Essere deliberati su quale modello gestisce cosa, bilanciare costo e qualità. Questo tipo di decisioni non si presta al vibe coding. Richiede di capire i propri margini, le aspettative dei clienti e i failure mode di ciascun livello di modello.
Nulla di tutto questo è stato delegato alla macchina.
Fase 4: Revisione umana e rifinitura
Dopo che il prototipo vibe-coded e il loop di test agentico ci avevano dato una base solida, il resto è stato molto lavoro umano di revisione. Leggere output. Confrontarli con quello che un ingegnere senior segnalerebbe davvero. Affinare il documento degli standard. Uccidere i falsi positivi.
Lo abbiamo dogfooded su tutti i 14 repository interni. Quando abbiamo lanciato la v7, aveva già gestito migliaia di PR reali su codice che ci interessava.
Risultato: miglioramento di 3× nel tempo fino al merge su quei repo. I PR hanno smesso di accumularsi. Gli ingegneri senior hanno smesso di rincorrere le stesse cinque cose in ogni revisione. I junior hanno smesso di indovinare le convenzioni. I PR generati dagli agenti hanno smesso di divergere verso forme che nessuno nel team avrebbe scritto.
Il mio team di sviluppo mi ha costretto a lanciarlo. Erano stanchi di dire ad amici fondatori che no, non potevano averlo, che era interno. Così lo abbiamo trasformato in prodotto.
Il framework (prendilo)
Se stai costruendo una qualsiasi pipeline di IA, code review o altro, ecco il pattern.
1. Fai il prototipo con vibe coding. Fai funzionare il flusso base. Non pensare troppo all’architettura. Lascia che l’IA monti l’impalcatura.
2. Costruisci un test harness agentico. Definisci input e output attesi. Lascia che Claude Code agisca da utente sintetico. Questo è il forward-backward pass. È veloce da montare se hai un’API da chiamare, e ti permette di testare 10 idee nel tempo in cui ne valuteresti una manualmente.
3. Lascia che siano i dati a scegliere i vincitori. Non dibattere su quale approccio è migliore. Fa passare tutti nel harness. Il segnale è immediato.
4. Trova il meccanismo di grounding. Per noi era un documento di standard. Per te potrebbe essere una style guide, una rubrica, un insieme di regole o un dataset di riferimento. La cosa che rende la tua pipeline coerente e con opinione. Quello è il tuo vero elemento differenziante, e quasi certamente richiede lavoro manuale umano.
5. Costruisci a mano ciò che protegge i clienti. Auth, pagamenti, privacy, stati di errore. Questo non è territorio di vibe coding. Queste sono le cose che guadagnano fiducia. Falle deliberatamente.
La conclusione onesta
Il vibe coding è un framework fenomenale per prototipare e sperimentare. Il loop di test agentico, il pattern forward-backward, ci ha permesso di muoverci molto più velocemente nello sviluppo iniziale di quanto avremmo mai potuto. Siamo passati da “e se costruissimo un bot di code review” a un prototipo funzionante che catturava bug reali in pochi giorni.
Ma le cose che rendono un prodotto affidabile hanno richiesto persone che prendessero decisioni deliberate con contesto completo. Il grounding sugli standard. La scelta dei modelli. I flussi di pagamento. L’architettura di privacy.
Fai vibe coding sui livelli di prototipo e sperimentazione. Costruisci a mano ciò che protegge i clienti. Quella è la linea. Pensiamo sia quella giusta.
Provalo sui tuoi repository
Surmado Code Review. 15 $/mese per 100 PR. Costruito da un team di cinque persone. Dogfooded su 14 repository.
Vedi come funziona Surmado Code Review o avvia una revisione sul tuo prossimo PR.
Letture correlate: