Come uso Codex per revisionare 15 progetti senza rinunciare al controllo manuale

Qualche anno fa, l’idea di revisionare seriamente 15 progetti software nello stesso periodo mi sarebbe sembrata poco realistica. Non intendo aprire 15 repository e guardarli velocemente. Intendo controllare progetti reali, più volte, per bug, assunzioni sbagliate, problemi SEO, errori di traduzione, incoerenze di localizzazione, test mancanti, regressioni e codice vecchio che non corrisponde più al resto del sistema.

Il limite non è mai stato la velocità di scrittura. È l’attenzione. Ogni progetto ha una storia, convenzioni, edge case e codice che sembra sbagliato ma esiste intenzionalmente. Una review seria richiede lettura, ricerca, confronto, controlli e solo dopo una decisione su cosa meriti davvero di essere cambiato.

Codex ha cambiato per me il costo di questo lavoro ripetitivo. Può fare una prima passata nel repository, seguire riferimenti, esaminare file collegati, evidenziare pattern sospetti, proporre test e aiutarmi a investigare aree che altrimenti aprirei manualmente una per una. La decisione finale non diventa automatica. Diventa molto più veloce la parte costosa che precede quella decisione.

La regola più importante che ho imparato è semplice: non uso Codex per togliermi dal loop di review. Lo uso per allargare quel loop.

Il vero collo di bottiglia è la ripetizione, non scrivere codice

Con un solo progetto è possibile ricordare una quantità sorprendente di contesto. Con molti progetti non scala. Le stesse categorie di lavoro tornano continuamente:

• cercare bug simili in componenti diversi;
• controllare se un refactor ha lasciato call site vecchi;
• rivedere i test dopo cambiamenti di comportamento;
• trovare incoerenze in metadata, logica delle lingue, headings o link interni;
• confrontare chiavi di localizzazione e contenuto tradotto;
• cercare error handling mancante ed edge case;
• verificare se una modifica “piccola” ha toccato più file del previsto;
• leggere diff semplici singolarmente ma costosi nel complesso.

Niente di tutto questo è spettacolare. Tutto conta. Quando la stessa review va ripetuta su molte codebase, il costo cresce enormemente.

È qui che un AI coding agent mi è più utile: assorbe la parte ripetitiva dello spazio di ricerca e mi lascia più attenzione per il giudizio.

Parto dall’ispezione, non dal permesso di riscrivere tutto

Uno dei modi più semplici per ottenere risultati scarsi è dare un compito enorme come “rivedi tutto il progetto e sistema tutto”. Sembra efficiente, ma unisce discovery, priorità, architettura, implementazione e validazione in un’unica attività incontrollata.

Ottengo risultati migliori separando le fasi.

inspect → explain findings → prioritize → change → validate → review diff

Prima voglio che l’agente capisca l’area e spieghi cosa ha trovato. Voglio percorsi file concreti, il codice coinvolto, la ragione per cui qualcosa è sospetto e l’impatto possibile. Solo dopo voglio le modifiche.

Questo è importante perché l’AI può sbagliare con grande sicurezza. Codice che sembra ridondante può esistere per un vecchio browser, un edge case di pagamento, un percorso di migrazione o una regola di business non evidente da un solo file. L’ispezione permette di fermare una cattiva assunzione prima che diventi un enorme diff.

Tratto i finding come piste, non come verdetti

Una buona review di Codex non finisce con “ho trovato 17 problemi”. Il numero da solo vale poco. Mi interessa l’evidenza.

Per un finding davvero azionabile voglio sapere:

• dove si trova il problema;
• perché è un problema;
• quale comportamento può rompersi;
• quanta confidenza merita la conclusione;
• quale controllo può confermarla o smentirla;
• qual è il fix minimo e sicuro.

Questo conta soprattutto per security, SEO e business logic. Un agente può indicare qualcosa che merita attenzione, ma una spiegazione che suona come security non dimostra una vulnerabilità. Un warning SEO non è automaticamente un problema di ranking. Una condizione strana non è automaticamente dead code.

L’AI riduce il costo di trovare candidati. La verifica decide ancora cosa è reale.

Il validation loop rende il workflow affidabile

La generazione di codice è la parte più visibile dell’AI-assisted development, ma la validazione è ciò che lo rende utile in produzione.

Dopo una modifica voglio che la codebase risponda. A seconda del progetto può significare:

• TypeScript o altro compiler/type checker;
• lint;
• unit e integration test;
• build check;
• ricerche mirate di vecchi nomi o call site;
• review del diff finale;
• verifica manuale del comportamento utente.

I comandi esatti contano meno del loop. L’agente fa un’ipotesi, il repository restituisce evidenza e la decisione successiva usa quell’evidenza.

Per questo i progetti fortemente tipizzati mi piacciono particolarmente con l’AI. Ho scritto separatamente perché TypeScript funziona così bene con Codex nel software reale: i tipi trasformano molte assunzioni sbagliate in feedback immediato leggibile dalla macchina.

Alcuni tipi di review sono particolarmente adatti all’AI

Bug e regressioni

Un agente può seguire un valore attraverso più file, controllare i caller, confrontare implementazioni simili e trovare branch incoerenti. È utile per restringere l’origine di un sintomo. Verifico comunque il comportamento prima di accettare la conclusione.

Test

L’AI è utile per trovare comportamenti cambiati senza copertura equivalente, proporre edge case e spiegare cosa protegge davvero un test esistente. Può anche far emergere test che controllano dettagli di implementazione invece del comportamento reale.

SEO

La SEO tecnica contiene moltissimo lavoro di coerenza: metadata, alternates linguistici, indexability, link interni, template, generazione sitemap, redirect e convenzioni a livello pagina. Un agente può confrontare queste regole su una grande codebase più velocemente di quanto io possa aprire ogni route. Ma separo sempre correttezza tecnica dalla domanda più difficile: il contenuto merita davvero di rankare?

Localizzazione e traduzioni

È una delle aree più ripetitive nei prodotti multilingua. L’AI può confrontare chiavi, trovare valori mancanti, rilevare lingue sbagliate, controllare placeholder e mostrare dove un locale è diventato strutturalmente diverso. È molto più veloce che leggere grandi oggetti di traduzione a mano, anche se il copy importante richiede giudizio umano.

Coerenza dopo i refactor

I grandi refactor spesso falliscono in modi banali: rimane un import vecchio, una route usa ancora il vecchio nome di campo, un test fixture conserva la shape precedente. Ricerca a livello repository più un agente che capisce l’intento del cambiamento sono molto utili qui.

Il lavoro parallelo aiuta solo quando i task sono indipendenti

È invitante avviare molti agenti e lasciare che cambino tutto insieme. Può aumentare il throughput, ma anche moltiplicare conflitti e assunzioni incompatibili.

Penso al parallelismo come a un problema di coordinamento. Audit indipendenti sono buoni candidati: un progetto può essere controllato per localizzazione mentre un altro viene revisionato per test, o repository diversi possono essere ispezionati nello stesso momento. Due agenti che riscrivono la stessa architettura senza un piano condiviso sono un’altra cosa.

Più lavoro avviene in parallelo, più servono confini chiari: progetto, task, definition of done e risultato revisionabile separatamente.

L’obiettivo non è massimizzare il numero di agenti attivi. È massimizzare progresso utile e verificabile.

Cosa non delego alla cieca

• Decisioni architetturali: il modello può proporre opzioni, ma i trade-off a lungo termine spesso dipendono da contesto fuori dal repository.
• Conclusioni di sicurezza: i finding richiedono verifica, threat context e spesso strumenti dedicati.
• Regole di business: il codice può essere coerente e implementare comunque il comportamento prodotto sbagliato.
• Grandi refactor distruttivi: un diff enorme è più difficile da capire e più facile da approvare con poca attenzione.
• Deploy in produzione: test verdi non eliminano il rischio operativo.
• Review finale: voglio sapere cosa è cambiato prima di metterci il mio nome.

Non perché l’AI sia inutile in queste aree, ma perché una risposta plausibile e sbagliata può costare molto.

La review AI non sostituisce l’analisi statica

Non considero Codex un sostituto di compiler, linter, test, scanner o monitoring. Questi strumenti hanno un vantaggio che l’AI non ha: sono stretti, deterministici e ripetibili.

Il workflow più forte li combina. Codex ragiona sul contesto e suggerisce dove guardare. Gli strumenti statici applicano regole precise. I test verificano il comportamento. Log e monitoring mostrano la realtà. La review umana collega tutti questi segnali all’intento del prodotto.

Senza questi feedback system mi fiderei meno dell’AI, non di più.

Il guadagno maggiore è una migliore allocazione dell’attenzione

È facile dire “Codex fa risparmiare tempo”, ma per me è una descrizione troppo piccola.

La risorsa scarsa nello sviluppo non sono i tasti premuti. È l’attenzione di qualità. Prima degli AI coding agent, moltissima attenzione veniva consumata da discovery ripetitiva: cercare gli stessi pattern, leggere file simili, seguire reference, controllare che un cambiamento fosse arrivato ovunque e rifare lo stesso audit in un altro repository.

Ora posso delegare più di quella prima passata e tenere la mia attenzione per le decisioni difficili da automatizzare: il finding conta davvero? Il fix si adatta all’architettura? La UX migliora? Il rischio è accettabile? Voglio davvero shipparlo?

È per questo che mantenere e revisionare molti progetti oggi sembra diverso. Non faccio meno review. In molti casi posso farne di più perché la parte meccanica non consuma più tutto il budget.

Il workflow di cui mi fido

1. Definire un obiettivo di review stretto. Bug, test, SEO, localizzazione, refactor o altro tema preciso.
2. Far ispezionare prima di modificare. Voglio prima evidenza e punti coinvolti.
3. Prioritizzare i finding. Non ogni problema teorico merita una modifica.
4. Tenere i cambiamenti delimitati. Diff piccoli e coerenti sono più facili da validare.
5. Eseguire controlli automatici. Typecheck, lint, test, build, search o validazioni specifiche.
6. Leggere il diff manualmente. Cerco rewrite inutili, assunzioni sbagliate, edge case mancanti e cambi fuori scope.
7. Verificare il comportamento importante. Soprattutto utenti, soldi, security, SEO e infrastruttura di produzione.
8. Solo dopo passare al progetto successivo. Il parallelismo aiuta, ma l’incertezza irrisolta non deve propagarsi.

Quindici progetti non sembrano più quindici volte il lavoro di review

Codex non ha reso 15 progetti semplici e non ha eliminato la responsabilità. Ha cambiato il rapporto tra scala e sforzo ripetitivo.

Posso chiedere first pass più profondi, controlli di coerenza più ampi, più idee di test e audit più sistematici senza passare personalmente ogni minuto a cercare in ogni file. Poi posso usare l’attenzione risparmiata sulle decisioni che richiedono ancora uno sviluppatore.

È questo il tipo di AI-assisted development che trovo utile: non autopilot, non fiducia cieca e non “genera codice finché qualcosa passa”. È un loop più stretto tra ispezione su scala macchina e giudizio su scala umana.

Per me questo è il vero leverage di Codex. Non elimina la review. Rende possibile una review seria su una scala che prima era molto più difficile mantenere.