Prima hanno usato ChatGPT per tagliare i costi. Poi ci hanno assunto per ripulire il debito tecnico di AI.

5 agosto 2025 10 minuti di lettura

Riassumere l'articolo con AI

Sarete sorpresi di sapere quante aziende lo fanno oggi.

Come risulta da rapporti provenienti da tutto il settore, sta crescendo un settore specializzato per gli ingegneri che si concentrano sulla correzione degli errori di codice generati dalla AI.

Lo schema è diventato straordinariamente coerente. Le aziende si rivolgono a ChatGPT per generare script di migrazione, integrazioni o intere funzionalità, nella speranza di risparmiare tempo e tagliare i costi. Dopo tutto, la tecnologia appare veloce e accessibile.

Poi i sistemi si guastano.

E ci chiamano.

Di recente abbiamo ricevuto sempre più richieste di questo tipo. Non per spedire un nuovo prodotto, ma per sbrogliare la matassa che si è lasciata dietro dopo che qualcuno si è fidato di un modello di linguaggio con il suo codice di produzione.

A questo punto, inizia a sembrare un settore di nicchia a sé stante. La correzione dei bug generati dall'AI è ora un servizio a pagamento. E in alcuni casi, molto costoso.

Rapporto 2024 di GitClear conferma ciò che abbiamo visto con i clienti: Gli strumenti di codifica AI accelerano la consegna, ma alimentano anche la duplicazione, riducono il riutilizzo e gonfiano i costi di manutenzione a lungo termine.

In un caso, un cliente si è rivolto a noi dopo che una migrazione generata da AI aveva fatto perdere dati critici dei clienti. Abbiamo speso 30 ore per recuperare ciò che è andato perso, riscrivere la logica da zero e ripulire la pipeline. L'ironia della sorte è che sarebbe stato più economico farlo scrivere a uno sviluppatore senior alla vecchia maniera.

Sia chiaro, però, che non siamo "contro l'AI". Lo usiamo anche noi. Ed è utile nel giusto contesto, con le giuste protezioni. Ma ciò che mi frustra dell'eccessivo affidamento all'AI e delle sue implicazioni diffuse - e probabilmente anche a voi - è il pensiero magico. L'idea che un modello linguistico possa sostituire il vero lavoro di progettazione.

Non può. E come dice il proverbio, la prova è nel budino. Quando le aziende fanno finta di niente, finiscono per pagare qualcuno come noi per rimediare.

Come si presenta uno di questi lavori di pulizia? Ecco cosa non vi dicono gli agenti dell'AI quando si tratta di tempo perso e denaro sprecato.

Come si presenta una richiesta tipica

Di solito il messaggio arriva così:

"Ehi, puoi dare un'occhiata a un microservizio che abbiamo costruito? Abbiamo usato ChatGPT per generare la prima versione. L'abbiamo spinta in staging e ora la nostra coda RabbitMQ è completamente ingolfata".

Si comincia sempre da poco. Un compito che sembrava troppo noioso o lungo. Qualcosa come l'analisi di un CSV, la riscrittura di un cron job o il cablaggio di un semplice webhook. Quindi si affida il compito a un modello linguistico e si spera nel meglio.

Ma il fatto è che i sintomi si manifestano molto più tardi. A volte giorni dopo. E quando si manifestano, raramente è ovvio che la causa principale sia il codice generato da AI. Sembra solo che... qualcosa non funzioni.

"Non si può affidare il pensiero architettonico a un modello linguistico. L'AI può accelerare le cose, ma ci vogliono comunque degli ingegneri per costruire sistemi che non vadano in pezzi sotto pressione".

Dmitry Nazarevich

Direttore tecnico

Dopo una dozzina di questi casi, cominciano a emergere degli schemi:

Nessun test. Per niente. Nemmeno un'asserzione di saluto al mondo. Solo codice grezzo e speculativo che non è mai stato esercitato correttamente.
Nessuna consapevolezza dei confini del sistema. Abbiamo visto script ChatGPT che interrogano tre microservizi in modo sincrono, ignorano i timeout e fanno saltare l'intera catena di chiamate al primo fallimento.
Uso improprio delle transazioni. Un cliente ha utilizzato SQL generato da AI con transazioni annidate all'interno di un servizio Node.js utilizzando Knex. Funzionava, fino a quando non funzionava, e metà delle scritture fallivano silenziosamente.
Condizioni di gara sottili. Soprattutto nelle basi di codice multithread o async. Il tipo di bug che non si manifestano in fase di sviluppo ma che distruggono la produzione in scala.

E naturalmente, quando tutto crolla, l'AI non vi lascia un commento con scritto: "A proposito, sto tirando a indovinare".

Questa parte è a carico vostro.

Caso 1: Lo script di migrazione che ha fatto cadere silenziosamente i dati dei clienti

Questa proviene da un'azienda fintech in rapida crescita.

Stavano lanciando una nuova versione del loro modello di dati dei clienti, dividendo un grande campo JSONB in Postgres in più tabelle normalizzate. Roba abbastanza standard. Ma con scadenze strette e poche mani, uno degli sviluppatori ha deciso di "accelerare le cose" chiedendo a ChatGPT di generare uno script di migrazione.

All'apparenza sembrava tutto a posto. Lo script analizzava il JSON, estraeva le informazioni sul contatto e le inseriva in un nuovo file user_contacts tavolo.

Così l'hanno eseguito.

Nessuna prova a secco. Nessun backup. Si è passati direttamente allo staging che, come si è scoperto, condivideva i dati con la produzione attraverso una replica.

Qualche ora dopo, l'assistenza clienti ha iniziato a ricevere e-mail. Gli utenti non ricevevano le notifiche di pagamento. Altri avevano numeri di telefono mancanti nei loro profili. A quel punto ci hanno chiamato.

Cosa è andato storto

Il problema è riconducibile allo script. Eseguiva l'estrazione di base, ma faceva tre assunzioni fatali:

Non ha gestito NULL o chiavi mancanti all'interno della struttura JSON.
Ha inserito record parziali senza convalida.
Ha utilizzato ON CONFLICT DO NOTHING, per cui ogni inserimento fallito viene ignorato silenziosamente.

Risultato: circa 18% dei dati di contatto è stato perso o danneggiato. Nessun registro. Nessun messaggio di errore. Solo una tranquilla perdita di dati.

Cosa è stato necessario per risolvere il problema

Abbiamo assegnato a un piccolo team il compito di sbrogliare la matassa. Ecco cosa abbiamo fatto:

Diagnosi e repliche (4 ore) Abbiamo ricreato lo script in un ambiente sandbox e lo abbiamo eseguito su un'istantanea del database. In questo modo abbiamo confermato il problema e mappato esattamente ciò che mancava.
Audit forense dei dati (8 ore) Abbiamo confrontato lo stato di rottura con i backup, identificato tutti i record con dati mancanti o parziali e li abbiamo confrontati con i registri degli eventi per rintracciare gli inserimenti falliti e il motivo.
Riscrittura della logica di migrazione (12 ore) Abbiamo riscritto l'intero script in Python, aggiunto una logica di validazione completa, creato un meccanismo di rollback e integrato nella pipeline CI del cliente. Questa volta sono stati inclusi i test e il supporto per le prove a secco.
Recupero manuale dei dati (6 ore) Alcuni record non erano recuperabili dai backup. Abbiamo recuperato i campi mancanti da sistemi esterni (le API del loro CRM e del provider di e-mail) e ripristinato manualmente il resto.

Tempo totale: 30 ore di ingegneria

Due ingegneri, tre giorni. Costo per il cliente: circa $4,500 in tasse di servizio.

Ma il colpo maggiore è stato dato dalle ricadute sui clienti. Le notifiche non andate a buon fine hanno portato a mancati pagamenti e alla rinuncia all'acquisto. Il cliente ci ha detto di aver speso almeno $10,000 per i ticket di assistenza, le compensazioni SLA e i crediti di avviamento per quell'unico script mal riuscito.

La cosa ironica è che uno sviluppatore senior avrebbe potuto scrivere la migrazione corretta in quattro ore. Ma la promessa di velocità di AI ha finito per costare loro due settimane di pulizia e danni alla reputazione.

Risolviamo ciò che ChatGPT ha rotto e costruiamo ciò che non è riuscito a fare.

Caso 2: Il client API che ha ignorato i limiti di velocità e ha interrotto la produzione

Questa viene da una startup di tecnologia legale che sta costruendo una piattaforma di gestione dei documenti per gli studi legali. Una delle loro caratteristiche principali era l'integrazione con un servizio di notifica elettronica del governo: un'API REST di terze parti con OAuth 2.0 e una rigorosa limitazione della velocità: 50 richieste al minuto, senza eccezioni.

Invece di assegnare l'integrazione a un esperto sviluppatore di backend, qualcuno del team ha deciso di "prototiparla" utilizzando ChatGPT. Hanno inserito le specifiche OpenAPI, hanno chiesto un client Python e hanno ottenuto uno script dall'aspetto pulito con requests, logica di riprova con tenacity, e l'aggiornamento del token.

Sembrava solido sulla carta. Così l'hanno spedito.

Cosa è andato storto

All'inizio sembrava tutto a posto. Il client gestiva correttamente le singole richieste, passava l'autenticazione e ritentava anche in caso di fallimento. Ma durante l'utilizzo reale, soprattutto sotto carico, la piattaforma ha iniziato a comportarsi in modo imprevedibile.

Ecco cosa è successo in realtà:

Nessun rispetto per i limiti tariffari. Il codice generato non legge o interpreta X-RateLimit-Remaining o Retry-After intestazioni. Continuava a inviare richieste alla cieca.
I tentativi hanno peggiorato la situazione. Quando gli errori 429 hanno iniziato a tornare, il decoratore di tenacia li ha ritentati automaticamente. Nessun jitter. Nessuna coda. Solo una marea di richieste di follow-up.
Il fornitore di API ha bloccato temporaneamente il loro IP. Per 3 ore, nessuno sulla piattaforma ha potuto sincronizzare i documenti. Nessun registro, nessun avviso. Solo un fallimento silenzioso.

Non si trattava di una correzione di una sola riga. Si trattava di un'incomprensione di come si comportano i sistemi di produzione. Ed è un ottimo esempio di ciò che i LLM non sanno, non perché siano rotti, ma perché non hanno la consapevolezza del runtime.

Smettetela di correggere il codice generato da AI in prod - coinvolgeteci prima che si rompa.

Come abbiamo risolto il problema

Rintracciare e isolare il guasto (6 ore) Abbiamo aggiunto un middleware per ispezionare il traffico in uscita e abbiamo confermato il flusso di richieste durante i picchi di utilizzo. Abbiamo anche ricreato il guasto in staging per comprendere appieno lo schema di attivazione.
Ricostruire il client API (10 ore) Abbiamo riscritto il client utilizzando httpx.AsyncClient, ha implementato un throttle basato su semaphore, ha aggiunto un backoff esponenziale con jitter e ha gestito in modo adeguato Retry-After e intestazioni di limite di velocità.
Stress test e convalida (6 ore) Abbiamo simulato un utilizzo reale con migliaia di richieste simultanee utilizzando Locust, abbiamo testato il throttling della velocità in diversi scenari di burst e abbiamo confermato l'assenza di 429s in caso di carico prolungato.
Aggiungere il monitoraggio e gli avvisi (4 ore) Abbiamo impostato metriche personalizzate Prometheus per monitorare l'utilizzo dell'API al minuto e abbiamo aggiunto avvisi per notificare al team l'avvicinarsi di soglie di tasso.

Tempo totale: 26 ore

Due ingegneri, distribuiti su due giorni e mezzo. Costo per il cliente: circa $3,900.

Il problema più grande è che il loro principale cliente, uno studio legale con depositi sensibili ai tempi, ha perso due finestre di presentazione in tribunale a causa dell'interruzione. Il cliente ha dovuto limitare i danni e offrire uno sconto per mantenere l'account.

Tutto perché un modello linguistico non capiva la differenza tra "codice funzionante" e "codice pronto per la produzione". E proprio così, un altro strato di debito tecnico AI è stato silenziosamente aggiunto alla pila.

Perché continua a succedere

La parte spaventosa non è che queste cose vadano male. È quanto tutto stia diventando prevedibile.

Tutti questi incidenti seguono lo stesso schema. Uno sviluppatore chiede a ChatGPT un frammento di codice. Viene restituito qualcosa che funziona abbastanza bene da non dare errori. Lo inserisce nel sistema, magari lo ripulisce un po', e lo spedisce, presumendo che se compila e funziona, deve essere sicuro.

Ma c'è un problema: I modelli linguistici di grandi dimensioni non conoscono il vostro sistema.
Non sanno come interagiscono i vostri servizi.
Non conoscono il vostro budget di latenza, la vostra pipeline di distribuzione, la vostra configurazione di osservabilità o i vostri modelli di traffico di produzione.

Generano il codice dall'aspetto più probabile in base agli schemi presenti nei dati di addestramento. Tutto qui. Non c'è consapevolezza. Nessuna garanzia. Nessuna intuizione per la progettazione del sistema.

E il risultato spesso lo riflette:

Codice che funziona una volta, ma che fallisce sotto carico
Nessuna programmazione difensiva, nessuna protezione contro i guasti
Scarsa comprensione dei vincoli del mondo reale, come i limiti di velocità, i timeout o la coerenza finale
Assolutamente zero senso dell'intento architettonico

La cosa peggiore è che il codice sembra corretto. È sintatticamente pulito. Passa i linters. Potrebbe anche essere coperto da un test di base. Ma manca l'unica cosa che conta davvero: il contesto.

Ecco perché questi bug non compaiono subito. Aspettano le implementazioni del venerdì sera, le finestre ad alto traffico, i rari casi limite. Questa è la natura del debito tecnico AI: è invisibile finché non rompe qualcosa di critico.

Quando l'AI è effettivamente utile

Come abbiamo già detto, anche noi usiamo AI. Praticamente ogni ingegnere del nostro team ha una configurazione simile a Copilot in esecuzione in locale. È veloce, utile e, onestamente, un ottimo modo per saltare le parti noiose.

Ma c'è una differenza: nulla arriva nel ramo principale senza passare attraverso un ingegnere senior e, nella maggior parte dei casi, una pipeline CI che sa cosa cercare.

I corsi di laurea magistrale sono ottimi per:

scaffolding boilerplate per nuovi servizi o endpoint API,
generare la copertura dei test per la logica esistente,
aiutando nel refactoring ripetitivo di grandi basi di codice,
traducendo semplici script di shell in modelli di infrastructure-as-code,
o anche confrontando approcci algoritmici che già conosciamo.

Cosa sono non è il design. O il contesto. O le impostazioni predefinite sicure.

Ecco perché abbiamo costruito i nostri flussi di lavoro in modo da trattare i risultati di LLM come suggerimenti, non come fonti di verità. Ecco come si presenta in pratica:

Tagghiamo tutti i commit generati da AI in modo che siano facilmente rintracciabili e rivedibili.
I nostri redattori hanno suggerimenti in linea, ma con ganci di pre-commit imposti che bloccano qualsiasi cosa senza test o documentazione.
Il nostro CI include regole di analisi statica che segnalano schemi non sicuri già visti in passato dai LLM: cose come retry non protetti, timeout non coperti, parsing JSON ingenuo o gestione non sicura di SQL.
Ogni richiesta di pull con codice generato da LLM viene sottoposta a una revisione umana obbligatoria, di solito da parte di un senior che comprende la logica del dominio e la superficie di rischio.

Se usato bene, è un risparmio di tempo. Se usato alla cieca, è una bomba a orologeria.

Cosa consigliamo ai CTO

Non siamo qui per dirvi di vietare gli strumenti AI. Quella nave è salpata.

Ma dare a un modello linguistico l'accesso al commit? Questo è solo un modo per creare problemi.

Ecco cosa consigliamo invece:

1. Trattare i LLM come strumenti, non come ingegneri

Lasciate che vi aiutino con il codice ripetitivo. Che propongano soluzioni. Ma non affidare loro decisioni critiche. Qualsiasi codice generato da AI deve essere rivisto da un ingegnere senior, senza eccezioni.

2. Rendere tracciabile il codice generato da LLM

Che si tratti di tag di commit, metadati o commenti nel codice, indicare chiaramente quali parti provengono da AI. In questo modo è più facile effettuare audit, debug e comprendere il profilo di rischio in un secondo momento.

3. Definire una politica di generazione

Decidete come team dove è accettabile usare gli LLM e dove no. Boilerplate? Certo. Flussi di autorizzazione? Forse. Sistemi transazionali? Assolutamente no senza revisione. Rendere esplicita la politica e parte dei vostri standard ingegneristici.

4. Aggiungere il monitoraggio a livello DevOps

Se si lascia che il codice generato da AI tocchi la produzione, si deve presumere che alla fine qualcosa si rompa. Aggiungete controlli sintetici. Monitoraggio dei limiti di velocità. Tracciamento delle dipendenze. Rendere visibile l'invisibile, soprattutto quando l'autore originale non è umano.

5. Costruire per la recuperabilità

I più grandi fallimenti causati da AI che abbiamo visto non provenivano da codice "cattivo". Sono stati causati da errori silenziosi - dati mancanti, code interrotte, tempeste di tentativi - che non sono stati rilevati per ore. Investite in osservabilità, logica di fallback e rollback. Soprattutto se si lascia che ChatGPT scriva le migrazioni.

In breve, AI può far risparmiare tempo al team, ma non può assumersi la responsabilità.

È ancora un lavoro umano.

Riflessioni conclusive: AI ≠ ingegneri del software

AI può aiutarvi a muovervi più velocemente. Ma non può pensare per voi.

Non capisce la vostra architettura. Non sa cosa significhi "fatto" nel vostro contesto. E sicuramente non gli interessa se la vostra pipeline di dati si rompe silenziosamente il venerdì sera.

Ecco perché, come CTO, dobbiamo concentrarci sulla resilienza del sistema, non solo sulla velocità.

Si è tentati di lasciare che l'AI si occupi delle parti noiose. E a volte va bene. Ma ogni scorciatoia comporta un compromesso. Quando il codice generato da AI passa senza essere controllato, spesso diventa un debito tecnico di AI. Il tipo di debito che non si vede fino a quando il team operativo non si trova a combattere in produzione.

Se vi siete già scontrati con questo muro, non siete soli. Abbiamo aiutato i team a riprendersi da tutto, dalle migrazioni interrotte ai disastri delle API. Non ci limitiamo a rifattorizzare il codice. Aiutiamo a rifattorizzare il pensiero che c'è dietro.

Perché alla fine è questo che rende i sistemi affidabili.

Philip Tikhanovich

Capo del dipartimento Python, Big Data, ML/DS/AI

Philip mette a fuoco tutto ciò che riguarda i dati e l'AI. È lui che pone le domande giuste in anticipo, definisce una visione tecnica forte e si assicura che non stiamo solo costruendo sistemi intelligenti, ma che stiamo costruendo quelli giusti, per un reale valore aziendale.

Per saperne di più

Indice dei contenuti

Contattateci

Prenota una chiamata oppure compilate il modulo sottostante e sarete ricontattati una volta elaborata la vostra richiesta.

Nome

Azienda

Telefono

Messaggio

Inviaci un messaggio vocale

Allegare i documenti

Caricare il file

È possibile allegare 1 file di dimensioni massime di 2 MB. Formati di file validi: pdf, jpg, jpeg, png.

Facendo clic su Invia, l'utente acconsente al trattamento dei propri dati personali da parte di Innowise in base alla nostra Informativa sulla privacy per fornirvi informazioni pertinenti. Inviando il vostro numero di telefono, accettate che possiamo contattarvi tramite chiamate vocali, SMS e applicazioni di messaggistica. Potrebbero essere applicate tariffe per chiamate, messaggi e dati.

Potete anche inviarci la vostra richiesta
a contact@innowise.com

Cosa succede dopo?

Una volta ricevuta ed elaborata la vostra richiesta, vi contatteremo per illustrarvi le esigenze del vostro progetto. Progetto e firmare un NDA per garantire la riservatezza.

Dopo aver esaminato i vostri desideri, le vostre esigenze e le vostre aspettative, il nostro team elaborerà una proposta di progetto con l'ambito di lavoro, le dimensioni del team, i tempi e i costi stimati con l'ambito di lavoro, le dimensioni del team, i tempi e i costi stimati.

Organizzeremo un incontro con voi per discutere l'offerta e definire i dettagli.

Infine, firmeremo un contratto e inizieremo subito a lavorare sul vostro progetto.