Gli agenti AI possono scrivere codice Laravel in produzione? Policy di code review per team assistiti da AI

Chiedersi se l’AI possa scrivere codice pronto per la produzione è la domanda sbagliata, anche se è quella che i board continuano a porre. L’AI sta già scrivendo codice nel Suo progetto Laravel, perché gli sviluppatori la usano; vietarla significa solo che il processo avviene senza disciplina di revisione.

La domanda utile è più circoscritta: quali errori commette su questo framework specifico e cosa deve quindi controllare chi revisiona? Laravel è un buon caso di studio: ha convenzioni forti, documentazione eccellente e una presenza massiccia nei dati di training — il risultato è un output sicuro, idiomatico, a volte rischioso.

Dove aiuta in modo affidabile

Essere specifici è fondamentale, perché una policy generica in qualsiasi direzione è sbagliata.

• Boilerplate con convenzioni forti — resource controller, form request, factory, seeder, API resource. Le convenzioni di Laravel sono così ben rappresentate che qui l’output è di solito corretto e stilisticamente coerente.
• Test scaffolding. Generare i casi che avrebbe scritto ma che forse avrebbe trascurato, soprattutto quelli ai margini della validazione.
• Refactoring meccanici applicati su molti file — rinominare, estrarre, aggiornare chiamate deprecate. Operazioni ripetitive, a basso rischio, facili da verificare.
• Spiegare codice non familiare. Utile su una codebase ereditata, senza alcun rischio per la messa in produzione.
• Migrazioni e definizioni di schema a partire da un modello descritto — verificabili leggendo, e con errori evidenti quando presenti.

Dove fallisce, prevedibilmente

Questi sono i pattern che riscontriamo più spesso, e sono quelli su cui una policy di revisione deve concentrarsi.

1. Pattern di query che funzionano ma non scalano

Le query N+1 sono l’errore tipico. Il codice generato che cicla una collezione e accede a una relazione all’interno del ciclo è corretto, leggibile, supera i test su un dataset di dieci record creato con una factory, ma crolla sui dati reali. Il modello non può sapere che la Sua tabella orders contiene nove milioni di righe.

2. Autorizzazione data per scontata invece che applicata

I controller generati spesso omettono il controllo della policy, o lo posizionano in modo che sia facile da aggirare. È la categoria di rischio più alta, perché il codice funziona perfettamente per chi lo testa come amministratore.

3. Vecchi idiomi dai dati di training obsoleti

I dati di training privilegiano ciò che è stato scritto di più, che non coincide con ciò che è attuale. Su un framework con dieci anni di articoli alle spalle, significa output basato su convenzioni di versioni precedenti — helper deprecati, sintassi di validazione superata, pattern sostituiti da funzionalità ufficiali. Sembra plausibile perché era corretto, una volta.

4. Mass assignment e fiducia negli input

Il codice generato passa troppo spesso l’input della richiesta direttamente alla creazione del modello. La protezione di Laravel limita i danni, ma solo se il modello è configurato correttamente, e i modelli generati spesso non lo sono.

5. Contesti multi-tenant e con scope

Se l’applicazione isola i dati per tenant, organizzazione o brand, il codice generato non lo saprà, a meno che il codice circostante non renda strutturalmente impossibile dimenticarsene. È un motivo forte per applicare lo scoping a livello di database o modello base, piuttosto che per convenzione — come approfondiamo in architettura multi-tenant Laravel.

6. Invenzione sicura di sé

Nomi di metodi su classi proprie che non esistono, API di package mai rilasciate, chiavi di configurazione plausibili ma inesistenti. Facili da individuare — falliscono subito — ma fanno perdere tempo in revisione e riducono l’attenzione per errori meno evidenti.

La policy di revisione

Deve essere abbastanza breve da essere seguita davvero.

1. L’autore deve dichiararsi. La pull request indica se il codice è stato generato in modo sostanziale da AI. Non per colpevolizzare — per orientare la revisione.
2. L’autore ha letto ogni riga. Questa è la policy in una frase. Inviare codice non letto è il vero problema; il generatore è secondario.
3. Quattro controlli obbligatori sul codice generato: comportamento delle query su dati reali, autorizzazione, validazione dell’input e mass-assignment, contesto di tenant o scope.
4. L’analisi statica non è opzionale. PHPStan o Psalm al livello effettivo della codebase, in CI, bloccante. Il codice generato dalla macchina richiede standard imposti dalla macchina.
5. I test devono essere scritti o verificati da una persona. Un agente che scrive sia codice che test può produrre una coppia che concorda tra loro ma non con il requisito.
6. Nessun codice generato può avvicinarsi al perimetro di sicurezza senza revisione di una seconda persona. Autenticazione, autorizzazione, gestione dei pagamenti, qualsiasi cosa che tocchi dati personali.
7. Migrazioni e operazioni distruttive richiedono un autore umano. Una migration generata che elimina una colonna è convincente quanto una che la aggiunge.

Rendere il codice più semplice da gestire correttamente

L’intervento più efficace non è aumentare la revisione. È rendere difficile scrivere codice sbagliato, cosa che aiuta allo stesso modo anche chi scrive manualmente.

• Imporre l’autorizzazione in modo strutturale, così che una action di controller senza controllo di policy fallisca invece di consentire silenziosamente.
• Imporre lo scoping dei tenant nel modello base o nel database, così una query senza scope genera errore.
• Mantenere tipi stretti e un livello alto di analisi statica. Entrambi riducono drasticamente lo spazio per codice plausibile ma errato.
• Documentare le convenzioni reali nel repository. Gli agenti leggono il repository; una codebase che documenta i propri pattern produce output migliore, sia per le AI che per i nuovi assunti.
• Mantenere la codebase idiomatica. La coerenza ora è un requisito anche per la leggibilità da parte delle macchine — un pattern insolito genera output insolito.

Questo è il vero argomento nuovo. Codice convenzionale e buona documentazione erano un vantaggio per l’onboarding. Ora sono un input diretto per la qualità di una quota rilevante del codice prodotto, quindi una questione economica, non solo stilistica.

Verificare se porta davvero benefici

I vendor vendono un moltiplicatore di produttività. Misuri il Suo, perché la risposta reale varia molto in base al tipo di attività.

• Tempo di ciclo dal primo commit al merge, non righe prodotte. Qui il conteggio delle righe è un anti-metrica.
• Carico di revisione — tempo speso in revisione e numero di iterazioni prima dell’approvazione. Se il tempo di revisione cresce più di quanto scende quello di scrittura, il costo si è solo spostato.
• Tasso di difetti per modifica accettata, tracciato separatamente per codice AI-assistito e scritto da persone.
• Tasso di rework — quante volte il codice mergeato viene riscritto in modo sostanziale entro un mese.
• Dove si concentrano i benefici. La nostra esperienza è che sono reali e ampi su boilerplate e test, modesti sulla logica di dominio, e talvolta negativi su tutto ciò che richiede conoscenza del Suo sistema specifico.

Tracci questi dati per un trimestre prima di usarli per pianificare la capacità. Un team che assume un moltiplicatore di produttività e dimensiona l’organico di conseguenza sta scommettendo su un numero che nessuno ha misurato.

Questo è il lavoro di governance che il nostro team Laravel applica sulle codebase dei clienti, e si affianca al tema più ampio di dove l’AI abbia davvero senso nella delivery — oggetto della nostra pratica di integrazione AI e del team di AI engineering. Lo stesso pattern di errore emerge ancora più chiaramente sul codice legacy: veda perché gli agenti AI scrivono fluentemente in PHP 7.

Adottare la policy, poi misurare

La aiuteremo a definire la policy di revisione e le regole strutturali, oltre a impostare le metriche che indicano se stanno producendo risultati. Contatti il nostro team; rispondiamo entro un giorno lavorativo.