Esegui cinque istanze di Claude Code sullo stesso ticket. Ottieni cinque implementazioni funzionanti. Tutte passano i test. Tutte risolvono il problema. Nessuna assomiglia al codice che il tuo team avrebbe scritto sei mesi fa.
Questa è la nuova base. Lo spazio delle implementazioni valide è esploso, e non si ridurrà da solo.
L’IA non ha reso il code review obsoleto. Lo ha reso il collo di bottiglia.
Per dieci anni, la generazione era il vincolo e la revisione era la pulizia. Il pomeriggio di un ingegnere senior era 30% scrivere codice e 70% rivedere quello degli altri. Il collo di bottiglia era la velocità del pensiero umano.
Questo rapporto si è invertito. La generazione è praticamente gratuita. Uno sviluppatore singolo con Claude Code o Cursor può produrre in una settimana più codice di quanto un team di cinque persone producesse in un anno.
Il collo di bottiglia si è spostato. Ora è: quale di queste cinque implementazioni funzionanti appartiene davvero alla nostra codebase?
Questa domanda non ha una risposta del modello. Ha una risposta del team. Il gusto accumulato del team è l’unica cosa che distingue “codice che funziona” da “codice che appartiene qui”. Come dai i nomi. Come strutturi i moduli. Cosa scegli di non importare. Quando esci anticipatamente. Come scrivi i test.
Senza questo, ogni PR è un lancio di moneta tra cinque opzioni plausibili.
Il tuo gusto è il moat. Codificalo.
È qui che la maggior parte dei team si blocca. Il gusto esiste. Vive nella testa di tre ingegneri. Esce nei commenti ai PR, nei thread di Slack, nello sguardo scettico che un senior lancia a un junior un martedì pomeriggio. È reale, ed è ciò che distingue una codebase che accumula valore da una che deriva nel caos.
Ma non è codificato in un modo leggibile dalle macchine. Quindi gli agenti non possono seguirlo. I nuovi arrivati nemmeno. Neanche i senior riescono ad applicarlo in modo coerente, perché sono stanchi, in reperibilità o in riunione quando arriva il PR.
La maggior parte dei team ha già un CLAUDE.md o un .cursorrules. Sono istruzioni su come gli agenti devono scrivere codice nel tuo repo. Nota l’asimmetria. C’è un contratto di scrittura e non c’è un contratto di revisione. CLAUDE.md dice all’agente cosa produrre. Non esiste un file equivalente che dica a qualcuno, umano o macchina, cosa è accettabile per il merge.
Quel file è STANDARDS.md. Markdown semplice, nel repository, versionato insieme al codice. Le decisioni accumulate del team, rese esplicite. Non best practice generiche. Le tue opinioni concrete su come costruisci.
Niente di tutto questo è un pensiero nuovo. Kleppmann, in Designing Data-Intensive Applications, sostiene che i sistemi accumulano valore quando i loro contratti sono espliciti e verificabili dalle macchine. Uno schema, non un’intuizione. STANDARDS.md è la stessa disciplina un livello più in alto. Il contratto non è più tra servizi. È tra il PR di un ingegnere e il gusto accumulato del team.
Quando quel file esiste, diventano possibili tre cose.
Gli agenti generano codice seguendo quegli standard. Il tuo gusto restringe lo spazio delle possibilità prima che il codice venga scritto.
Ogni PR viene revisionato automaticamente rispetto a essi, che l’autore sia umano o agente. Niente drift, niente eccezioni, niente “lo recuperiamo al prossimo sprint”.
I nuovi membri leggono un solo documento e assimilano la visione del team in un pomeriggio.
Il file di standard non è documentazione. È la funzione di collasso. Prende l’esplosione di implementazioni valide e la proietta sulla tua implementazione.
Abbiamo accelerato il team di tre volte facendo revisionare ogni PR dall’IA rispetto ai nostri standard.
Internamente ci siamo scontrati con questo muro tre mesi fa. Abbiamo costruito Surmado Code Review prima per noi. Strumento interno, v7. Gira su 14 repository a ogni commit.
I nostri standard vivono in uno STANDARDS.md per repo. Scout lo legge, legge il diff e dice al revisore umano cosa va bene, cosa va migliorato, dove guardare e quali ipotesi sta facendo il PR.
Il 3× è il tempo fino al merge sui nostri 14 repo. I nostri PR non restano fermi. Si muovono.
Questa velocità non deriva dal fatto che il bot faccia la revisione. Deriva dal fatto che il bot elimina il rumore in modo che le persone possano concentrarsi su ciò che conta. L’ingegnere senior smette di ripetere le stesse cinque osservazioni in ogni PR. Il junior smette di indovinare le convenzioni. I PR generati dagli agenti smettono di divergere verso forme che nessuno nel team avrebbe scritto.
Se non hai ancora uno STANDARDS.md, Scout lo scrive con te. Due clic per installare. Scout ti fa domande su stack, convenzioni, approccio ai test e le decisioni architetturali che hai già preso.
Dove hai opinioni, Scout le scrive. Dove non le hai ancora, Scout propone dei default che puoi accettare, modificare o sovrascrivere. Se sei un vibe coder che non ha mai dovuto articolare i propri standard, Scout struttura il ragionamento e fa emergere le domande che non ti eri posto.
Le opinioni restano tue. L’impalcatura è la stessa che usiamo internamente per i nostri STANDARDS.md. Il tipo di disciplina di standard che a un team più grande richiede settimane di discussione, tu lo hai in funzione oggi pomeriggio.
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.
Sul tuo codice
Non lo memorizziamo. Non lo usiamo per addestramento. Non leggiamo l’intero repository.
Scout gira su modelli di frontiera di Anthropic e OpenAI. Ogni revisione di PR invia solo il diff alle loro API, sotto gli accordi standard. Nessuna conservazione. Nessun addestramento. Niente del tuo codice persiste nei nostri sistemi dopo la revisione.
Leggi la privacy policy e i termini completi. Tutto è documentato.
A cosa serve davvero
Il pitch che la maggior parte degli strumenti di IA fa è: il modello sostituisce l’umano. Questo inquadramento è sbagliato sui principi, ed è particolarmente sbagliato adesso.
La generazione con IA sta rendendo i team più veloci, ma sta anche facendo derivare le codebase più rapidamente. L’acceleratore e l’entropia arrivano dallo stesso posto. I team che vanno avanti sono quelli che hanno capito come elevare il giudizio umano al passo con la velocità della macchina, non quelli che lo hanno sostituito.
Surmado Code Review non è un revisore autonomo. È un moltiplicatore del gusto del tuo team. I tuoi standard, applicati a ogni PR, ogni push, ogni esecuzione di agente. Le persone continuano a fare il lavoro umano: decidere quali sono gli standard, prendere le decisioni architetturali, fare mentoring al team, conoscere il business. Il bot fa la parte che stava esaurendo i tuoi senior, cioè individuare le deviazioni da decisioni già prese.
Il futuro dell’IA nel codice non è agenti che sostituiscono gli ingegneri. È il gusto degli ingegneri, codificato una volta, applicato ovunque, a velocità di macchina. I team che lo capiscono per primi appariranno irriconoscibili rispetto a quelli che non l’hanno fatto. Non perché i loro sviluppatori siano più intelligenti. Perché il loro gusto sta operando su ogni riga di codice, comprese quelle che non hanno scritto.
Come tutto quello che costruiamo in Surmado, questo mette al centro la persona e potenzia l’agente. Il tuo gusto, amplificato.
Provalo al tuo prossimo PR
Surmado Code Review. Due clic per installare. 15 $/mese per 100 PR. Nessun costo per utente. Zero conservazione dei tuoi diff. Pensato per sviluppatori singoli e piccoli team che si muovono veloci. Non per l’enterprise.
Installa Surmado Code Review o leggi come lo abbiamo costruito.
Letture correlate: