PR #342 aperta da @dev-junior. Review completata. Sicurezza: libreria auth-utils con CVE-2024-8821 (criticità alta), patch in 3.2.4. Qualità: variabile user_id usa snake_case, convenzione team richiede camelCase. Test coverage: nuova funzione validateSession senza test unitari, pattern di test allegato.
AGENTE · CODE REVIEW PRE-MERGE
Le pull request passano da una review automatica prima del merge.
Code Review Pre-Merge si attiva su ogni nuova pull request del repository del cliente. Esegue review automatica rispetto a standard di sicurezza, qualità del codice, test coverage configurati dal team. Lascia commenti strutturati direttamente sulla PR; lo sviluppatore senior decide il merge.
Code Review Pre-Merge al lavoro.
Applico tutte e tre. Push del nuovo commit.
Nuova review PR #342: CVE risolta, naming corretto, test aggiunti. Tutti i segnali verdi. Pronta per review del senior.
Perché esiste.
La code review è uno dei processi cardinali del lavoro di sviluppo software. La maggior parte delle aziende mid-large ha standard di sicurezza e qualità documentati, ma l'applicazione di questi standard sulla singola PR è di solito manuale: lo sviluppatore senior legge la PR, applica gli standard a memoria, lascia commenti. Il processo è lento, soggetto a saltare passaggi quando il volume di PR è alto, dipende dalla disponibilità del senior.
Come lavora su ogni PR.
Code Review Pre-Merge si attiva al trigger di nuova PR (via webhook GitHub). Legge il diff della PR, applica gli standard dichiarativi del cliente: sicurezza (pattern di sicurezza per linguaggio, riconoscimento di vulnerabilità tipiche, segnalazione di librerie con CVE note), qualità del codice (convenzioni di stile, naming, struttura), test coverage (presenza di test per le funzioni nuove, copertura sufficiente del cambiamento). Lascia commenti strutturati sulla PR con il dettaglio specifico, una proposta di correzione quando possibile.
La decisione resta al team.
Lo sviluppatore senior rivede la PR insieme ai commenti dell'agente, decide il merge. L'agente non fa merge autonomamente.
Tre figure tecniche che cambiano il modo di gestire la code review.
Responsabile engineering
Recupera il tempo del team senior sulla revisione delle PR standard. La capacità del team si concentra sulle revisioni con giudizio architetturale.
10 controlli attivi
policy.evaluate 14:02:11 ALLOW
pii-detector 14:01:58 BLOCK
tool.invoke 14:01:42 WARN
memory.write 14:01:09 BLOCK
Sviluppatore senior
Riceve PR pre-revisionate sui pattern standard. Si concentra sulla revisione di alto livello (architettura, scelte di design, coerenza con il codebase esistente).
Proposta n. 2024-081 In revisione
Disclosure mancante
art. 21 TUF · strumento finanziario regolato
Alt. 1 …nel rispetto dell'art. 21 TUF e delle disposizioni Consob vigenti.
Alt. 2 …con disclosure completa allegata al documento di offerta.
Traccia audit registrata · 14:31
Sviluppatore junior
Riceve feedback in tempo reale sulle proprie PR. La curva di apprendimento sugli standard del team accelera, perché il feedback arriva sul codice concreto e non in un workshop a distanza di settimane.
$ git clone github.com/polyant-ai/polyant
$ cd polyant
$ docker compose up -d
polyant agent runtime · active
AGPLv3 · codice nel perimetro del cliente
Una PR martedì mattina, dal trigger alla decisione del senior.
Webhook GitHub: una PR è stata aperta.
Per un team di sviluppo di un'azienda B2B SaaS con 15 sviluppatori, l'agente è integrato con il repository GitHub via webhook. Una PR viene aperta da uno sviluppatore junior martedì mattina. L'agente legge il diff. Identifica tre osservazioni: la nuova funzione di autenticazione usa una libreria con CVE noto (criticità alta) e suggerisce di aggiornare alla versione patch; il naming di una variabile non rispetta la convenzione del team e propone la riformulazione; la nuova funzione non ha test unitari e suggerisce di aggiungerli con un esempio di pattern.
Tre commenti, tre fix, una nuova review verde.
L'agente pubblica i commenti sulla PR direttamente sul thread GitHub. Lo sviluppatore junior aggiorna la libreria, corregge il naming, scrive i test unitari. Push del nuovo commit. L'agente riesegue la review: tre osservazioni risolte, nuovi pattern verdi.
Il senior si concentra su architettura e design.
Lo sviluppatore senior rivede la PR nel pomeriggio. La review di alto livello (architettura, scelte di design) si concentra sui punti che richiedono giudizio. Approva il merge.
Regole dichiarative del team engineering.
Le regole sono dichiarative. Il team engineering definisce in formato leggibile gli standard di sicurezza per linguaggio, le convenzioni di stile, le regole di test coverage, i pattern di review. Le regole vivono nel repository del cliente, versionate, validate all'avvio dell'agente.
- Linguaggio
- TypeScript (Node.js)
- Modello LLM
- a scelta del cliente: Anthropic, OpenAI, Mistral, modelli open source ospitati internamente, AWS Bedrock per modello privato
- Controlli built-in usati
- pii-detector, credential-detector, prompt-injection, tool-rate-limit
- Canali nativi
- Slack, Telegram, HTTP OpenAI-compatible (webhook GitHub)
- Integrazione GitHub
- nativa via tool ghPR e ghIssue del runtime
- Integrazione GitLab, Bitbucket, sistemi proprietari
- adapter dedicato realizzato in fase di delivery
- Memoria
- persistente per istanza, pgvector + PostgreSQL FTS sui pattern del repository del cliente
- Registro
- immutabile, interrogabile con client SQL standard
Domande frequenti sull'agente.
No. L'agente lascia commenti strutturati sulla PR e attende il merge dello sviluppatore senior o del responsabile engineering. Il merge resta sempre del team umano secondo le procedure del progetto.
Lo sviluppatore può marcare un commento dell'agente come falso positivo con una nota. L'agente impara dai pattern del repository per ridurre falsi positivi futuri sullo stesso pattern. Le regole dichiarative possono essere calibrate dal team senza intervento del fornitore.
GitHub è integrato nativamente tramite i tool ghPR e ghIssue del runtime. Per GitLab, Bitbucket, sistemi proprietari, l'integrazione si realizza in fase di delivery dal team Exelab.
Il pattern tipico per Code Review Pre-Merge è 4-8 settimane. Discovery una settimana, configurazione regole di review 2-3 settimane, integrazione con il repository del cliente 1-2 settimane, hand-off al team engineering una o due settimane.
Da una conversazione di 30 minuti alla squadra in produzione.
Una conversazione di 30-45 minuti per capire come Code Review Pre-Merge si configurerebbe sul caso del cliente. Repository, linguaggi, standard di sicurezza del team.