Il tuo messaggio è stato inviato.
Elaboreremo la vostra richiesta e vi ricontatteremo al più presto.
Il modulo è stato inviato con successo.
Ulteriori informazioni sono contenute nella vostra casella di posta elettronica.
Selezionare la lingua
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.
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.
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".
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.
Dopo una dozzina di questi casi, cominciano a emergere degli schemi:
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.
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 contatti_utente
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.
NULLA
o chiavi mancanti all'interno della struttura JSON.SUL CONFLITTO NON FARE NULLA
, per cui ogni inserimento fallito viene ignorato silenziosamente.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 richieste
, logica di riprova con tenacia
e l'aggiornamento del token.
Sembrava solido sulla carta. Così l'hanno spedito.
Ecco cosa è successo in realtà:
X-RateLimit-Remaining
o Riprova dopo
intestazioni. Continuava a inviare richieste alla cieca.httpx.AsyncClient
, ha implementato un throttle basato su semaphore, ha aggiunto un backoff esponenziale con jitter e ha gestito in modo adeguato Riprova dopo
e intestazioni di limite di velocità.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.
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.
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:
Se usato bene, è un risparmio di tempo. Se usato alla cieca, è una bomba a orologeria.
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.
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.
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.
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'invisibilesoprattutto quando l'autore originale non è umano.
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.
Il tuo messaggio è stato inviato.
Elaboreremo la vostra richiesta e vi ricontatteremo al più presto.
Iscrivendosi si accetta il nostro Informativa sulla privacy, compreso l'uso dei cookie e il trasferimento dei vostri dati personali.