Perché gli agenti di coding AI non bastano per le app di produzione

Partiamo dall'essere onesti con la categoria. Gli agenti di coding moderni, Cursor, Claude Code, OpenAI Codex e i loro pari, sono strumenti genuinamente forti. Leggono codebase grandi, pianificano modifiche multi-file, scrivono test, correggono fallimenti e iterano finché le cose passano. I team di ingegneria che li usano bene si muovono notevolmente più in fretta, e nulla in questo articolo sostiene il contrario. Il punto riguarda lo scope, non la qualità.

L'output di un agente di coding, per quanto buono, è una modifica al codice. Il software di produzione è un sistema molto più grande di obblighi permanenti: dimostrare che la modifica funziona per utenti reali, verificare che non abbia introdotto vulnerabilità, decidere se era permessa in primo luogo, rilasciarla in sicurezza, accorgersi quando si comporta male e ricostruire cosa è successo quando lo fa. Ognuno di quegli obblighi esiste che qualcuno vi sia assegnato o no, e un agente di coding, operando alla fase di modifica del codice, non ti solleva da nessuno di essi. Aumenta la pressione su tutti, perché la fase che accelera è quella che alimenta tutte le altre.

Quindi la domanda pratica per un team che va in produzione non è "il nostro agente è abbastanza buono?". È "chi possiede tutto ciò che sta a valle del diff, ora che i diff arrivano cinque volte più in fretta?". I team con una forte organizzazione di piattaforma possono rispondere con infrastruttura che già gestiscono. I team che non ce l'hanno devono costruire quel ciclo o adottarlo, e dovrebbero deciderlo deliberatamente, non scoprire la lacuna durante un incidente.

Aiuta notare perché la lacuna è così facile da mancare. L'output dell'agente è vivido, una feature funzionante, una run di test che passa, un ticket chiuso, mentre il ciclo mancante è invisibile finché non viene messo sotto stress: nessuno vede il test browser che non esiste o il registro di controllo che non è mai stato scritto. Le decisioni d'acquisto pesano naturalmente il vivido più dell'invisibile, ed è così che le organizzazioni finiscono con una generazione eccellente e una delivery improvvisata. Scrivere i sei obblighi qui sotto dentro la valutazione è la correzione; valutarli onestamente richiede un pomeriggio e predicono il dolore di produzione molto meglio di qualsiasi benchmark di generazione.

Ecco il pattern che i responsabili di ingegneria continuano a riportare. Arrivano gli agenti; il volume di pull request salta nel giro di settimane; e ogni fase a valle, revisione, QA, sicurezza, rilascio, è improvvisamente il vincolo. L'organizzazione allora scivola in una di due modalità di fallimento. O le fasi a valle tengono la linea e il backlog si riforma davanti a loro, il che significa che il guadagno di produttività evapora in tempo di coda; oppure le fasi cedono, le approvazioni si alleggeriscono, i test vengono saltati "solo per questa volta", e l'organizzazione sta di fatto rilasciando codice non revisionato su larga scala senza averlo mai deciso.

La seconda modalità è quella pericolosa perché sembra un successo. Il lead time scende, i dashboard brillano, e il rischio accumulato è invisibile fino a un martedì specifico: una migrazione scritta da un agente, approvata in nove secondi da un revisore con quaranta tab aperte, butta giù il flusso di checkout, e il postmortem scopre che non esiste un test a livello browser per il checkout, nessuna policy che segnali le modifiche allo schema per una revisione vera, e nessun modo pulito di sapere quale dei duecento merge della settimana annullare.

Niente di tutto ciò è colpa dell'agente. Ogni salvaguardia mancante mancava anche prima che l'agente arrivasse; c'era semplicemente meno traffico sul ponte. L'asimmetria è il punto: gli strumenti che moltiplicano la produzione di codice moltiplicano le conseguenze di ciò che manca al tuo ciclo di delivery.

Se vuoi un preavviso invece di un postmortem, osserva quattro numeri mentre cresce l'adozione degli agenti: il tempo mediano di revisione per modifica unita (il collasso verso lo zero è un sintomo, non una vittoria), la copertura di test dei flussi che portano i ricavi, il tempo medio per attribuire un problema di produzione alla modifica che l'ha causato, e la quota di deploy con un percorso di rollback testato. Uno qualsiasi di essi che si muove nella direzione sbagliata mentre il volume di merge sale è l'asimmetria che arriva puntuale, e tutti e quattro costano meno da sistemare al mese due che al mese dodici.

Percorso uno: assembla il ciclo da solo. CI con gate veri, infrastruttura di test browser, scansione di sicurezza collegata a qualcosa che verifica i risultati, policy di revisione che il tuo team applica davvero, automazione del deploy con rollback, osservabilità, e la colla per far fluire le modifiche generate dagli agenti attraverso tutto questo. È un percorso legittimo, è ciò che fanno i team di piattaforma forti, e il suo costo è che è un investimento ingegneristico permanente, non un acquisto. Se hai l'organizzazione di piattaforma per costruirlo e mantenerlo, gli agenti di coding dentro quel ciclo sono una combinazione superba.

Percorso due: adotta una piattaforma dove il ciclo è il prodotto, e la generazione avviene al suo interno. È lo scambio che la maggior parte dei team senza organizzazione di piattaforma dovrebbe valutare onestamente: meno controllo su misura rispetto a costruirselo, in cambio di test, governance, sicurezza, deploy e monitoraggio che esistono dal primo giorno e scalano con il volume delle modifiche per progettazione. I due percorsi non sono nemmeno nemici. Molte organizzazioni tengono ingegneri con agenti di coding sui sistemi core e una piattaforma governata per la lunga coda di applicazioni di business che altrimenti non riceverebbero mai l'attenzione del team di piattaforma.

Un'euristica equa per scegliere tra i percorsi: conta i tuoi ingegneri di piattaforma e le tue applicazioni. Un team di piattaforma forte che supporta una manciata di sistemi core può assolutamente costruire il ciclo, e probabilmente dovrebbe. Lo stesso team a cui viene chiesto di estendere quel ciclo su dozzine di app dipartimentali, portali costruiti da agenzie ed eredità di acquisizioni annegherà. Quella lunga coda è dove la decisione di comprare di solito si ripaga. E i percorsi si compongono: nulla nell'adottare una piattaforma per il portafoglio richiede di abbandonare la pipeline di cui il tuo prodotto core già si fida.

Ciao è il percorso due, costruito deliberatamente. Ogni workspace riceve un'organizzazione software AI. CTO, Doctor, analista QA, ingegnere Security, Coder e operatore SysOps. Così i ruoli che possiedono il ciclo esistono dal primo prompt. QA esegue replay browser deterministici, test auto-riparanti, smoke gate prima della pubblicazione e controlli di produzione dopo la pubblicazione. Security esegue scansione statica, controlli delle dipendenze e sonde di controllo degli accessi, e conferma le vulnerabilità sull'app live prima di segnalarle. Guardrails applica policy in linguaggio semplice, registra la revisione umana e lascia un registro di controllo dietro ogni merge. Doctor, un AI SRE in sola lettura, sonda l'app live, il DNS e la CDN, diagnostica la causa radice e abbozza la correzione, e Conductor dà un'unica schermata sull'intera flotta.

E poiché la fase di modifica del codice non dovrebbe essere un giardino recintato: le applicazioni sono vero React, TypeScript e Supabase con 100% di proprietà, esportabili sul tuo repository in qualsiasi momento, e le immagini sandbox personalizzate avvolgono lo stesso ciclo di vita intorno a backend Rails, Java, Go, Python, Node e multi-processo. Distribuisci sul cloud Ciao, sul tuo account AWS, Azure o GCP, in VPC privata o on-prem con termini separati. I programmi di sviluppo seri partono da 10.000 USD all'anno, e la demo più utile, se questo articolo ti ha parlato, è guardare una modifica percorrere l'intero ciclo dal prompt alla produzione monitorata.