Perché l’AI preconfezionata frustra le squadre — e cosa fare al riguardo

Con la maggior parte delle tecnologie, più a lungo le si utilizza, più ci si affida tranquillamente ad esse. Con gli strumenti di intelligenza artificiale, il contrario è stato vero: nel suo sondaggio annuale di oltre 49.000 sviluppatori, Stack Overflow ha registrato un utilizzo in aumento al 84% mentre la fiducia nell’accuratezza di questi strumenti è scesa dal 40% al 29% nel giro di un solo anno.

Questo effetto mi è familiare. La nostra prima esperienza con gli strumenti di intelligenza artificiale nello sviluppo aveva poco in comune con l’effetto wow della velocizzazione del lavoro e della riduzione della fatica che la stampa tecnica continuava a scrivere. I nostri sviluppatori sono stati delusi: l’AI produceva codice mediocre che richiedeva molto tempo per la revisione e, alla fine, doveva essere riscritto. La squadra si aspettava che l’AI risparmiasse tempo e invece ottenne lavoro extra. Quindi, non molto tempo dopo quei primi tentativi di integrare gli strumenti di intelligenza artificiale nel flusso di lavoro quotidiano, la squadra tornò a lavorare come sempre aveva fatto.

Oggi quegli stessi strumenti velocizzano sia la scrittura del codice che la sua revisione per i nostri sviluppatori — non perché abbiamo trovato un modello migliore, ma perché abbiamo cambiato il modo in cui lavoriamo con esso. Ecco cosa ci ha aiutato a raggiungere questo obiettivo.

Perché il codice scritto dall’AI frustra gli sviluppatori

L’AI si basa su una enorme massa di codice pubblico da tutto internet, e quel codice è raramente esemplare: la sua qualità è media, e il modello riproduce quella media.

Ma “media” non è il limite di ciò che è possibile — è semplicemente ciò che il modello produce fino a quando non conosce il tuo progetto: le sue convenzioni, la sua struttura del codice, le sue decisioni architettoniche. In un sondaggio di oltre 600 sviluppatori, Qodo ha scoperto che tra coloro che non sono soddisfatti della qualità del codice AI, il 44% lo attribuisce precisamente alla mancanza di contesto. È questo che mantiene la produzione a un livello mediocre.

La buona notizia è che il contesto che l’AI riceve è quasi l’unica variabile che una squadra controlla completamente. Quanto bene lo strumento comprende il progetto dipende non dal modello, ma da ciò che gli si fornisce.

La seconda ragione è mentale — la natura stessa del lavoro cambia. Quando l’AI scrive la maggior parte del codice, l’atto principale dello sviluppatore non è più la scrittura, ma il controllo di ciò che è stato generato: leggere la soluzione di qualcun altro, valutare le alternative, decidere cosa è pronto per la spedizione. Questa è una competenza diversa dalla scrittura del codice da solo, e per chiunque abbia amato la parte di scrittura, non viene facilmente.

Nel suo rapporto Octoverse 2025, GitHub descrive proprio questo cambiamento: gli sviluppatori che sono andati più lontano con l’AI non si definiscono più “autori di codice” e diventano qualcosa di più simile ai suoi “direttori creativi”, dove la competenza chiave è guidare e verificare. Ma la strada per quel ruolo passa attraverso errori e frustrazione, fino a quando una persona non vede il ritorno nel proprio lavoro.

Cosa trasforma l’AI da fonte di frustrazione in uno strumento di lavoro

Quando la nostra squadra ha iniziato a utilizzare l’AI, alcuni sviluppatori hanno lavorato con Claude Code, altri hanno provato OpenAI Codex, GitHub Copilot o Gemini CLI, e ogni strumento ha dato un risultato diverso. Quindi, quando abbiamo cercato di portare ordine nel modo in cui la squadra lavorava con l’AI, la prima cosa che abbiamo fatto è stata quella di scegliere uno strumento unico.

Questo non è solo la nostra pratica. Prendete la storia della squadra di Linear: fino all’inizio del 2026, hanno seguito un principio di “lasciare che ognuno lavori come gli piace”, e a gennaio la dirigenza ha abbandonato quell’approccio e ha spostato tutti i developer su un unico modo di lavorare — restringendo la scelta a due strumenti di AI e chiedendo loro di scrivere codice solo con quelli, anziché a mano. Secondo la società, la produttività media è aumentata già il mese successivo del 30% nelle richieste di merge e del 33% nei compiti chiusi per ingegnere.

Detto questo, uno strumento condiviso da solo non migliora il codice — deve essere configurato: impostare regole, qualcosa come un file di regole, che specifichino come scrivere il codice — quali approcci seguire, cosa evitare. Poi vengono le competenze personalizzate per i compiti tipici del tuo progetto, in modo da non dover spiegare la stessa cosa più e più volte. E infine, vale la pena puntare l’agente verso la tua base di codice esistente: analizza come il progetto è scritto e produce nuovo codice nello stesso stile, anziché in uno generico. Più contesto lo strumento riceve, meno dovrai riscrivere a mano in seguito.

Ma la parte più difficile non è tecnica. Il passaggio da autore del codice a valutatore non avviene da solo — quel passaggio ha bisogno di aiuto. La via più diretta è la formazione e la certificazione. Nel nostro caso, ad esempio, dieci sviluppatori stanno seguendo un programma di partner con il fornitore dello strumento, mentre accanto a loro lavora una persona responsabile dell’adozione, che spiega perché lo strumento ha prodotto un determinato risultato e come correggerlo.

Una volta che la squadra lavora in modo coordinato, rimane un collo di bottiglia — la revisione — e vale la pena rinforzarla con l’AI. L’agente esamina ogni richiesta di pull prima e si occupa dell’ovvio: errori di routine, stile, ripetizione, lacune di sicurezza. Il revisore umano non guarda più tutto indiscriminatamente, solo l’architettura e le decisioni critiche. L’effetto è notevole anche all’interno delle società che costruiscono questi strumenti: in Anthropic, dopo l’introduzione di tale agente, la quota di richieste di pull che hanno ricevuto una revisione sostanziale è aumentata dal 16% al 54%, e gli ingegneri hanno dissentito con meno dell’1% dei suoi commenti.

Per noi, questo ha abbreviato un ciclo di revisione che un tempo si estendeva su due o tre giorni in più round, e ha sollevato i senior engineer dalle mansioni di routine, lasciandogli solo i punti veramente difficili. Una volta che lo strumento ha finalmente iniziato a produrre risultati che non richiedevano rielaborazione, la fiducia in esso è apparsa anche.

Dove la fiducia negli strumenti di AI si ripaga

Innanzitutto — nella scrittura del codice: quando lo strumento conosce il progetto e l’agente gestisce la prima revisione, la squadra scrive di più e meglio nello stesso tempo. Nel nostro caso, gli strumenti di AI hanno velocizzato il lavoro di circa il 30-40%.

Oltre a ciò, l’AI ha reso più facile l’onboarding. Quando una nuova persona si unisce a un progetto, qualcuno con esperienza di solito deve rispondere a decine di domande su come il codice del progetto è organizzato. Ora l’agente assume quel ruolo: se il progetto è ben documentato, il nuovo arrivato indirizza fino al 95% di quelle domande a esso anziché ai colleghi.

È una storia simile con la documentazione: una bozza architettonica grezza che un tempo richiedeva ore è ora, per la maggior parte, scritta dall’agente stesso — secondo le nostre stime, circa l’80% della bozza, se gli si dà abbastanza contesto. Ciò che rimane all’umano è ciò che non è nel repository — le decisioni, i compromessi, l’esperienza.

Altrettanto importante è essere onesti sui limiti di ciò che l’AI può fare, perché sono le aspettative gonfiate che generano delusione per prima. L’AI non assume la conformità — un umano firma la data medica o finanziaria, e la società, non il modello, è responsabile per una perdita. Non velocizza le integrazioni con i partner, dove decine di ore vanno in chiamate e coordinamento.

L’AI preconfezionata è veramente irritante — ma solo quando viene utilizzata come soluzione finita. La differenza tra frustrazione e ritorno si trova in ciò che si costruisce intorno ad esso: uno standard condiviso, il contesto del tuo progetto e il nuovo ruolo dello sviluppatore.