Ora ogni commit che invio viene revisionato da un’IA prima che qualsiasi essere umano lo veda. Non perché non mi fidi del mio codice, ma perché non mi fido della mia attenzione alle 23:00 di venerdì quando cerco di spedire una correzione prima del weekend.
L’IA revisore cattura cose che mi sfuggono: una variabile dichiarata ma mai utilizzata, una chiave API accidentalmente lasciata in un commento, una funzione che gestisce il percorso felice ma va in crash con un input vuoto. Piccole cose. Quel tipo di cose che la revisione del codice esiste per catturare, ma che anche i revisori umani stanchi trascurano.
Ecco come ho collegato OpenClaw a GitHub Actions per la revisione automatizzata del codice assistita da IA.
Impostazione
Trigger: Un workflow di GitHub Action che si attiva ad ogni pull request. Quando una PR viene aperta o aggiornata, il workflow si attiva.
Cosa fa: Il workflow estrae il diff della PR, lo invia a OpenClaw per la revisione e pubblica la revisione come commento della PR. Tempo totale di esecuzione: 30-60 secondi a seconda delle dimensioni del diff.
Cosa rivede OpenClaw:
1. Bug: riferimenti nulli, errori di off-by-one, casi limite non gestiti
2. Sicurezza: segreti hardcoded, modelli di SQL injection, impostazioni non sicure
3. Stile: incoerenze con il codice, nomi di variabili poco chiari, commenti mancanti su logica complessa
4. Prestazioni: evidenti inefficienze, cicli non necessari, query non ottimizzate
Cosa non rivede: Decisioni architetturali, design delle funzionalità, correttezza della logica di business. Questi richiedono un contesto umano che l’IA non ha.
Il Workflow di GitHub Action
Il workflow è semplice:
1. Controllare il codice
2. Estrarre il diff tra il branch della PR e main
3. Inviare il diff a OpenClaw tramite la sua API (o CLI)
4. Formattare la risposta come commento della PR
5. Pubblicare il commento
L’estrazione del diff è il passo importante. Non invii l’intero codice, ma solo le modifiche. Questo mantiene il conteggio dei token ragionevole (e il costo basso) concentrando la revisione su ciò che è davvero cambiato.
Per PR grandi (500+ righe di modifiche), divido il diff per file e rivedo ogni file separatamente. Questo produce un feedback più mirato rispetto a lanciare tutto il modello in una volta.
La Qualità della Revisione
Dopo 3 mesi e circa 200 PR revisionate:
Vere positività (catturati problemi reali): Circa il 25% delle revisioni. All’incirca una su quattro PR ha qualcosa che l’IA cattura che importa. Più comune: gestione degli errori mancante, denominazione incoerente, variabili non utilizzate.
Suggerimenti utili (non bug ma miglioramenti): Circa il 40% delle revisioni. Miglioramenti di stile, suggerimenti di leggibilità, lacune nella documentazione. Non critici ma utili.
Falsi positivi (sbagliati o irrilevanti): Circa il 35% delle revisioni contiene almeno un suggerimento errato. L’IA fraintende il contesto, suggerisce modifiche che romperebbero la funzionalità o segnala modelli intenzionali come problemi.
Il tasso di falsi positivi del 35% sembra alto, ma in pratica è gestibile. I commenti sono chiaramente etichettati come generati dall’IA e gli sviluppatori imparano rapidamente quali suggerimenti prendere sul serio e quali ignorare.
Rendere Utile invece di Fastidioso
La differenza tra un revisore IA utile e uno fastidioso:
Prioritizzare i risultati. Etichetta ogni risultato come: 🔴 Bug (correggere prima di unire), 🟡 Avviso (considera di correggere), 🟢 Suggerimento (miglioramento facoltativo). Gli sviluppatori affrontano gli elementi rossi, considerano quelli gialli e scorrono quelli verdi.
Essere specifici. “Potrebbe esserci un problema con la gestione degli errori” è inutile. “La funzione `processOrder()` alla riga 47 non gestisce il caso in cui `order.items` è indefinito, il che genererà un TypeError” è fattibile.
Non ripetere l’ovvio. Gli sviluppatori sanno che dovrebbero scrivere test. Non dirlo ad ogni PR. Concentrati su risultati specifici e non ovvi.
Limitare il numero di commenti. Limita la revisione dell’IA a 5 commenti per PR. Se ci sono più problemi di così, prioritizza e mostra i primi 5. Una PR con 20 commenti dell’IA viene ignorata completamente; una PR con 3-5 commenti mirati viene letta.
Oltre la Revisione del Codice
Una volta che l’integrazione con GitHub Actions funziona, puoi estenderla:
Generazione della descrizione della PR. Quando una PR viene aperta con una descrizione vuota, l’IA legge il diff e genera un sommario: cosa è cambiato, perché probabilmente è cambiato e cosa cercare durante la revisione.
Analisi della copertura dei test. L’IA verifica se il codice modificato ha cambiamenti nei test corrispondenti. “Hai modificato `auth.js` ma non hai aggiornato `auth.test.js` — l’aggiornamento del test era intenzionale o dimenticato?”
Proposta di voce nel changelog. Basandosi sul diff, l’IA suggerisce una voce nel changelog nel formato appropriato. Lo sviluppatore approva o modifica.
Compilazione delle note di rilascio. Quando è il momento di rilasciare, l’IA compila tutte le PR unite dall’ultimo rilascio e genera le note di rilascio. Questo fa risparmiare 30-60 minuti per ogni rilascio.
Il Costo
Costo medio per revisione PR: circa $0.08.
Costo mensile per 200 PR: circa $16.
Per contestualizzare, un umano che spende 15 minuti a rivedere ciascuna di quelle PR impiegherebbe 50 ore al mese per la revisione del codice. L’IA non sostituisce la revisione umana, ma la pre-elabora, catturando i problemi meccanici così gli umani possono concentrarsi su design e logica.
Il processo di revisione del mio team ora: revisione IA prima (automatica, 30 secondi). Revisione umana seconda (concentrata su ciò che l’IA non può valutare, tipicamente 5-10 minuti invece di 15). Qualità complessiva della revisione: più alta rispetto a prima, in meno tempo.
🕒 Published: