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

Philip Tihonovich

29 maggio 2025 10 minuti di lettura

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 service fees.

But the bigger hit came from customer fallout. Failed notifications led to missed payments and churn. The client told us they spent at least $10,000 on support tickets, SLA compensation, and goodwill credits over that one botched script.

The ironic thing is that a senior developer could’ve written the correct migration in maybe four hours. But the promise of AI speed ended up costing them two weeks of cleanup and reputation damage.

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

The scary part isn’t that these things go wrong. It’s how predictable it’s all becoming.

Every one of these incidents follows the same pattern. A developer asks ChatGPT for a code snippet. It returns something that works just well enough not to throw errors. They wire it into the system, maybe clean it up a little, and ship it, assuming that if it compiles and runs, it must be safe.

But here’s the catch: Large language models don’t know your system.
They don’t know how your services interact.
They don’t know your latency budget, your deployment pipeline, your observability setup, or your production traffic patterns.

They generate the most likely-looking code based on patterns in their training data. That’s all. There’s no awareness. No guarantees. No intuition for system design.

And the output often reflects that:

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

As we mentioned earlier, we use AI too. Pretty much every engineer on our team has a Copilot-like setup running locally. It’s fast, helpful, and honestly, a great way to skip the boring parts.

But here’s the difference: nothing makes it into the main branch without going through a senior engineer, and in most cases, a CI pipeline that knows what to look for.

LLMs are great at:

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

We’re not here to tell you to ban AI tools. That ship has sailed.

But giving a language model commit access? That’s just asking for trouble.

Here’s what we recommend instead:

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 can help you move faster. But it can’t think for you.

It doesn’t understand your architecture. It doesn’t know what “done” means in your context. And it definitely doesn’t care if your data pipeline silently breaks on a Friday night.

That’s why, as CTOs, we need to stay focused on system resilience, not just speed.

It’s tempting to let AI handle the boring parts. And sometimes that’s fine. But every shortcut comes with a tradeoff. When AI-generated code slips through unchecked, it often becomes AI technical debt. The kind you don’t see until your ops team is firefighting in production.

If you’ve already run into that wall, you’re not alone. We’ve helped teams recover from everything from broken migrations to API disasters. We don’t just refactor code. We help refactor the thinking behind it.

Because in the end, that’s what actually makes systems reliable.

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.