Il coding AI è veloce. La tua pipeline DevOps no.

Questa settimana sono successe due cose che, considerate insieme, ti dicono tutto quello che c'è da sapere su dove sta andando lo sviluppo software nel 2026.

Prima cosa: il report State of DevOps Modernization 2026 è uscito l'11 marzo, basato su un sondaggio condotto su 700 ingegneri tra Stati Uniti, Regno Unito, Germania, Francia e India. Il dato principale: i team che usano strumenti di coding AI più volte al giorno rilasciano in produzione più velocemente, ma il 69% di quegli stessi utenti intensivi dichiara di riscontrare problemi di deployment «sempre», «quasi sempre» o «frequentemente» quando è coinvolto codice generato dall'AI. Nel frattempo, il 51% segnala più problemi di qualità del codice e il 53% più incidenti di sicurezza da quando ha adottato questi strumenti.

Due giorni prima, Anthropic aveva lanciato Code Review per Claude Code, un sistema multi-agente che esamina automaticamente le pull request alla ricerca di errori logici. I loro numeri interni spiegano perché lo hanno costruito: l'output di codice per ingegnere in Anthropic è cresciuto del 200% nell'ultimo anno, e l'azienda è passata dal 16% al 54% di PR con commenti di revisione sostanziali dopo aver adottato internamente il proprio sistema di revisione.

Vedi lo schema? L'AI sta rendendo la produzione di codice economica e veloce. Tutto ciò che viene dopo il codice — i test, la scansione della sicurezza, il deployment, la revisione — è ora il collo di bottiglia. Il report Harness chiama questo fenomeno «AI Velocity Paradox». Noi lo chiamiamo semplicemente martedì.

Lo stiamo osservando accadere in tempo reale

Dal nostro lavoro con PHP e Docker per clienti enterprise, soprattutto in settori regolamentati come la finanza svizzera, stiamo vedendo una versione di questo problema da mesi. I team adottano assistenti di coding AI, l'output aumenta, e poi la pipeline CI/CD progettata per i volumi di commit del 2022 comincia a soffocare. Le build si accodano. I test richiedono più tempo perché semplicemente c'è più codice da testare. Le scansioni di sicurezza che un tempo erano un fastidio minore diventano un muro di 45 minuti tra uno sviluppatore e il suo deploy.

I dati di Harness lo confermano: il 73% dei responsabili tecnici afferma che «quasi nessun» team dispone di template standardizzati o golden path per le proprie pipeline. Solo il 21% riesce ad avviare una pipeline di build-and-deploy funzionante in meno di due ore. Gli sviluppatori spendono circa il 36% del loro tempo in attività manuali come rincorrere approvazioni e ripetere job falliti.

Quest'ultimo numero dovrebbe preoccuparti. Un terzo della tua capacità di ingegneria, bruciata nel lavoro meccanico. Non a costruire funzionalità. Non a correggere bug. Solo a fare babysitting a una pipeline non progettata per questo throughput.

Il collo di bottiglia nella revisione del codice è reale, ed è un problema di sicurezza

Ecco dove le cose si fanno scomode dal punto di vista della sicurezza. Durante i nostri penetration test troviamo regolarmente bug che avrebbero dovuto essere intercettati in fase di revisione. Edge case di autenticazione, logiche di autorizzazione quasi corrette ma non del tutto, validazione dell'input che copre il 90% dei casi e manca quel 10% che a un attaccante interessa davvero.

Ora moltiplica tutto questo per il volume di codice generato dall'AI che inonda le pull request. Il post sul blog di Anthropic è onesto su questo punto: prima del loro strumento di Code Review, la maggior parte delle PR veniva scorsa velocemente, non letta. Gli ingegneri sono sovraccarichi. Vedono una PR da 400 righe, la scorrono cercando problemi evidenti, la approvano e vanno avanti. Non è una mancanza di carattere. È un problema di capacità.

Lo strumento di Anthropic è interessante perché si concentra sugli errori logici anziché sui dettagli stilistici. Nelle PR di grandi dimensioni (oltre 1.000 righe), l'84% delle revisioni individua problemi, con una media di 7,5 issue. Nelle PR piccole, sotto le 50 righe, la percentuale scende al 31%. Hanno anche intercettato internamente una modifica che rompeva l'autenticazione — una singola modifica dall'aspetto innocuo che avrebbe compromesso il loro stesso sistema di auth.

Continuo a pensarci. Una singola riga. In un servizio di auth. Intercettata da un revisore automatico. È esattamente il tipo di bug che troviamo durante i pen test, settimane o mesi dopo che è andato in produzione. Individuarlo nella PR ha un costo ordini di grandezza inferiore.

Cosa dovresti fare concretamente

Non ti diremo di andare a comprare la piattaforma di un vendor specifico. Ma in base a quello che vediamo nei nostri progetti web e mobile, ecco cosa funziona:

Analizza la tua pipeline post-codice questa settimana. Sul serio, mappa il flusso. Quanto tempo passa dal merge alla produzione? Dove ci sono handoff manuali? Dove le cose si accodano? La maggior parte dei team con cui parliamo non ha mai misurato questo percorso dall'inizio alla fine. Sanno che la build impiega 8 minuti, ma non hanno idea di perdere 3 ore in catene di approvazioni e provisioning degli ambienti. Questo è il tuo punto di partenza.

Automatizza le scansioni di sicurezza prima, non dopo. Quando configuriamo WAF e protezione DDoS per piattaforme di viaggio, spingiamo sempre per portare i controlli di sicurezza il più vicino possibile allo sviluppatore. Lo stesso principio si applica alla tua pipeline. Analisi statica, scansione delle dipendenze e rilevamento dei secret dovrebbero girare su ogni PR, automaticamente, prima che un revisore umano la veda. Se stai ancora eseguendo le scansioni di sicurezza solo in staging, o peggio come gate prima della produzione, stai trovando i problemi troppo tardi per risolverli a basso costo.

Non saltare la revisione umana solo perché hai aggiunto quella AI. Lo strumento di Anthropic non approva le PR. È una scelta progettuale deliberata, e quella giusta. Nei nostri progetti iOS e Android nativi, abbiamo visto che gli strumenti AI intercettano classi di bug diverse rispetto agli esseri umani. L'AI è brava a individuare incongruenze logiche in un diff esteso. Gli umani sono più bravi a chiedersi «aspetta, perché lo stiamo facendo in questo modo?». Hai bisogno di entrambi.

Standardizza i tuoi percorsi di deployment. I dati di Harness dicono che il 73% dei team non ha golden path. Se ogni servizio si deploya in modo diverso, non puoi automatizzare i controlli a valle, e ogni deployment è un rischio su misura. Dal nostro lavoro nella costruzione di app cloud-native su AWS, il singolo investimento con il rendimento più alto che abbiamo visto fare ai team è un template di deployment ben mantenuto che ogni nuovo servizio eredita per impostazione predefinita.

La verità scomoda

La storia vera di questa settimana non è che l'AI sta rendendo gli sviluppatori più veloci. Questo lo sapevamo già. La storia vera è che la maggior parte delle organizzazioni ha costruito la propria infrastruttura di delivery per un mondo più lento, e gli strumenti di coding AI stanno mettendo quei sistemi alla prova fino al punto di rottura.

Il report Harness ha rilevato che il 77% dei team è regolarmente bloccato in attesa di altri team per attività di delivery di routine. Non è un problema di strumenti. È un problema di architettura e di processo. Nessuna quantità di codice generato dall'AI lo risolverà.

Se il tuo team scrive codice 2 volte più velocemente ma lo rilascia con 2 volte più incidenti, non hai guadagnato velocità. Hai guadagnato caos con una sintassi migliore.

Metti a posto la tua pipeline. Poi lascia che l'AI vada a tutta velocità.

Se tutto questo ti sembra la settimana del tuo team, parliamone. Stiamo aiutando startup e team enterprise ad affrontare esattamente questo tipo di dolori di crescita, tra web, mobile e sicurezza.