Code review assistita 👁️
La code review è un esercizio di giudizio, non di velocità. Un agente può leggere un diff e segnalare problemi in pochi secondi — ma non può capire il contesto in cui quel codice vive. Può dirti “questa funzione è troppo lunga” ma non può dirti “questa funzione è lunga perché il business richiedeva quella logica specifica tre release fa”. L’agente è un secondo set di occhi, non un secondo cervello.
L’agente vede il codice. Non vede il contesto. La review vera richiede entrambi.
Quando usare l’agente per questo caso 🎯
- Review di PR prima della merge — controllo automatico di sicurezza, performance, leggibilità.
- Review di codice generato da altri agenti — autovalutazione con limiti.
- Checklist di review riutilizzabile — prompt standard da applicare a ogni PR.
- Identificazione di pattern anti — codice duplicato, funzioni troppo lunghe, dipendenze circolari.
Quando NON usare l’agente ⛔
- La review richiede conoscenza del dominio — se il codice implementa una logica business complessa, l’agente non può valutare la correttezza funzionale.
- La PR è enorme — più di 500 righe. Frammenta prima, poi delega la review per parti.
- Devi decidere se approvare o meno — il giudizio finale è sempre umano. L’agente segnala, non decide.
Prompt di apertura 📝
“Rivedi questa PR/diff. Checklist: [sicurezza, performance, leggibilità, coerenza con AGENTS.md, edge case]. Segnala con severità [blocca/consiglia]. Non modificare file.”
Esempio concreto:
“Rivedi il diff nel branch
feature/payment. Checklist: sicurezza (injection, credenziali hardcoded), performance (N+1 query, memory leak), leggibilità (nomi, funzioni lunghe), coerenza con AGENTS.md (convenzioni, pattern). Segnala con severità: blocca / consiglia. Non modificare file.”
Setup del contesto 🔧
- Fornisci il diff — l’agente deve vedere il codice modificato, non l’intero file.
- Definisci la checklist — sicurezza? Performance? Leggibilità? Coerenza? Tutto insieme è troppo: priorizza.
- Specificare la severità — blocca (deve essere fixato prima della merge) vs consiglia (miglioramento opzionale).
Ciclo di lavoro 💡
- Prepara il diff — solo le modifiche rilevanti, non l’intero history del branch.
- Invia con checklist — l’agente analizza il diff contro i criteri definiti.
- Rivedi i findings — ogni finding deve essere verificato: è un problema reale o un falso positivo?
- Applica le correzioni necessarie — solo quelle che concordi, non tutto ciò che l’agente segnala.
- Riesegui la review dopo le correzioni — per verificare che i fix non abbiano introdotto nuovi problemi.
I findings vanno trattati come suggerimenti, non come verdict. L’agente può segnalare pattern sospetti, ma la decisione è sempre tua.
Per la review di codice generato da agenti, usa lo stesso approccio: l’agente che ha generato il codice non è il migliore per valutarlo. Delega la review a un contesto diverso.
Pathology del codice generato da AI 🦠
Il codice generato da modelli presenta failure pattern diversi da quelli del codice umano. Il codice umano ha errori di sintassi evidenti, formattazione inconsistente, logica incompleta quando è frettoloso. Il codice AI mantiene sintassi uniforme, naming professionale e strutture plausibili — anche quando la logica è fondamentalmente sbagliata.
API inventate
Il failure mode primario. L’agente invoca metodi che non esistono su oggetti validi, referenzia argomenti deprecati, importa pacchetti rinominati o mai esistiti. In ambienti multi-tenant, questo pattern abilita vulnerabilità supply chain come la slopsquatting: attaccanti registrano nomi di pacchetti hallucinati su registri pubblici (PyPI, npm) per iniettare payload malevoli.
Il tell è che il codice generato è più naturale dell’API reale — perché è stato generato per essere plausibile, non per essere ricordato dalla documentazione.
Test tautologici
Quando l’agente genera test per il proprio codice, crea suite che passano costantemente e inflazionano le metriche di copertura, ma non validano il reale comportamento operativo. Spesso affermano che il valore di ritorno di una funzione è uguale a una chiamata identica all’implementazione — testano la configurazione del mock, non la logica business.
Cargo-cult abstractions
Addestrato su vasti repository enterprise, l’agente propone astrazioni architetturali complesse anche per feature base. Un parser di file diventa una factory interface con strategy pattern e dependency injection multi-livello. Complessità strutturale inutile che complica il debugging e amplifica la superficie di manutenzione.
Security review quantificata 📊
Dati Veracode 2026 (100+ modelli testati, 4 snapshot longitudinali):
- Pass rate medio sicurezza: 56% — virtualmente invariato dal primo report.
- ~44% dei task di generazione introduce una vulnerabilità OWASP Top 10.
| Linguaggio | Security pass rate | Vulnerabilità principali |
|---|---|---|
| Java | 29% | SQL injection (CWE-89), output encoding (CWE-80), logging (CWE-117) |
| C# (.NET) | 55% | Crittografia (CWE-327), Entity Framework raw queries, path traversal |
| JavaScript/TypeScript | 57% | XSS (CWE-80), prototype pollution, redirect non validati |
| Python | 62% | Command injection (subprocess), deserializzazione (pickle), access control |
I modelli specializzati in coding (51%) non performano meglio dei general-purpose (52%). La dimensione del modello (>100B parametri: 53%) non migliora significativamente il pass rate.
Lo studio 1Password: su 6.000+ security patch generati da AI, solo il 26% ha corretto la vulnerabilità senza effetti collaterali. Anche chiedere all’agente di fixare una vuln nota non è affidabile senza re-verifica.
Il blind spot degli SAST tradizionali
La ricerca formale con solver Z3 su artefatti generati da AI rivela che gli strumenti SAST tradizionali missano fino al 97.8% delle vulnerabilità verificate. I scanner rule-based si basano su pattern matching e mancano vulnerabilità semantiche più profonde.
Auto-review: limiti strutturali 🚫
Quando lo stesso modello genera e revisiona il codice, entrambi gli agenti attingono dallo stesso corpus di addestramento, dallo stesso vocabolario di pattern e dalle stesse assunzioni su cosa sia il codice “corretto” — un loop chiuso senza punto di uscita che tocca la specifica originale.
Dati empirici:
- Studio legacy modernization (1.980 chiamate, 11 LLM): nei casi in cui il modello ha silenziosamente cambiato il comportamento, il 31.7% è stato silenziosamente approvato dallo stesso modello che lo ha prodotto.
- GPT-3.5 self-review su vulnerabilità: 43.6% accuracy — vicino al caso casuale.
- GPT-4 self-review: 74.6% — meglio ma non sufficiente.
- Esperimento peer review adversariale: quando due reviewer convergono sullo stesso falso critique, il worker agent mostra sycophancy e modifica codice corretto introducendo errori che non esistevano.
La regola pratica: l’AI review è un primo passo rapido per problemi meccanici/pattern-based, ma non è una verifica indipendente. Non sostituisce un umano o un check genuinamente separato (static analysis deterministica, test di specifica che l’agente non può toccare).
Severity classification e SARIF 📋
Classificare i finding per severità è essenziale per evitare alert fatigue. Schema a 4 livelli:
| Severità | Definizione | Azione pipeline |
|---|---|---|
| Critical | Vulnerabilità sfruttabili (SQLi, Auth Bypass), esposizione dati immediata | Hard Block — previene merge |
| High | N+1 query nei path critici, authorization mancante, eccezioni non gestite | Conditional Block — richiede sign-off |
| Medium | Input validation mancante, crescita incontrollata collezioni, error handling non standard | Advisory — inline comment, merge con approvazione |
| Low / Advisory | Style mismatch, variabili ridondanti, opportunità di semplificazione | Informational — collapsed summary |
I finding devono essere esportati in formato SARIF v2.1.0 per integrarsi con GitHub Code Scanning, GitLab Security Dashboard o Azure DevOps. Questo standard permette mapping diretto delle severità ai gate della pipeline.
Anti-pattern nella code review 🚫
| Anti-pattern | Descrizione | Dati |
|---|---|---|
| Review fatigue | Troppi finding generano rumore; gli ingegneri smettono di trattare “critical” come urgente | Cubic.dev: fino al 40% degli alert viene ignorato una volta che l’alert fatigue si instaura |
| Trust paradox | Più il codice generato è sintatticamente pulito, più il reviewer umano passa a ispezione superficiale | 96% scettici sulla sicurezza, meno del 48% verifica la logica prima del merge |
| Self-correction unbounded | Senza limiti di iterazione, l’agente modifica codice casualmente ed esaurisce budget token | Max 3-5 tentativi; escalation a umano quando il limite è raggiunto |
| Auto-merge non validato | Merge automatico di dependency bumps solo perché i test passano | I test unitari missano edge case di integrazione, regressioni performance, memory leak |
Il report GitClear 2026 (623M modifiche): le chiamate cross-file (proxy di reale riutilizzo) sono down del 35%; il refactoring line move è down del 70%; la manutenzione legacy a lungo termine è down del 74% rispetto al 2022. Il workflow AI default premia codice atomico — un happy path, un test passante, un ticket chiuso — mentre tassa il lavoro invisibile di riutilizzo, consolidamento e error-surfacing.
Criteri di accettazione ✅
- Ogni finding è verificabile e localizzato (file:riga).
- Nessun falso positivo sistematico (se l’agente segnala sempre le stesse cose a vuoto, aggiusta la checklist).
- Nessuna modifica al codice durante la review (solo lettura).
- Le correzioni applicate sono state rivalutate.
Approfondimenti 📚
- Comprendere una codebase esistente — per fare una buona review, prima capisci il contesto.
- Scrivere prompt che funzionano — come strutturare checklist di review efficaci.
- Blog: Assisted critical thinking — il pensiero critico come strumento di review.