Gli sviluppatori usano l’IA, ma solo il 6,6% le affida decisioni importanti

Il 6 ottobre 2026 Stack Overflow ha pubblicato la sua indagine annuale: secondo il comunicato sui risultati, hanno partecipato oltre 30.000 professionisti della tecnologia di 169 paesi, il 66% degli intervistati usa assistenti o agenti per programmare, ma solo il 6,6% dichiara di fidarsi dell’IA anche per decisioni di lavoro importanti. L’uso è quindi assai più esteso della disponibilità dichiarata a lasciare che l’output pesi sulle scelte più delicate.

La lettura indipendente di displacement.ai precisa che alla domanda facoltativa sulla fiducia hanno risposto 14.304 persone: il 48,0% ha scelto l’opzione della fiducia quando il risultato è facilmente verificabile, mentre due gruppi del 16,3% ciascuno si fidano per molti compiti esclusi quelli decisivi oppure solo per attività a basso rischio. Sono risposte alternative alla stessa domanda; misurano atteggiamenti dichiarati, non quante verifiche siano state davvero eseguite né la correttezza del codice prodotto.

La soglia tra usare un assistente e fidarsi del risultato

Il questionario mette nello stesso quadro strumenti che propongono codice, chat generiche e flussi automatizzati con agenti. Sono impieghi diversi: una proposta di completamento può essere confrontata con una funzione esistente, mentre un agente può concatenare passaggi che richiedono controlli in punti differenti. Per questo una risposta positiva sull’uso dell’IA non dice da sola quanto margine decisionale venga lasciato allo strumento.

Anche fra chi esprime fiducia, le condizioni cambiano. Una risposta ammette molti compiti ma esclude le decisioni importanti; un’altra limita la fiducia alle attività a basso rischio. La scelta più frequente lega invece il giudizio alla facilità di verifica. Non stabilisce che i risultati facilmente controllabili siano sempre accurati: indica il tipo di garanzia che quei partecipanti ritengono necessario prima di affidarsi all’output.

La distanza conta nel lavoro quotidiano perché un suggerimento può essere utile senza diventare automaticamente una decisione progettuale. Se un assistente propone una correzione locale, chi sviluppa può confrontarla con il requisito e osservare l’effetto dei test. Se suggerisce di cambiare un’interfaccia condivisa o una scelta architetturale, entrano in gioco dipendenze, compatibilità e motivazioni precedenti: il costo di capire se la proposta è adatta cresce con il contesto richiesto.

Fonti e contesto rendono la verifica possibile

Nel portale della Developer Survey, il 52,1% giudica molto importante l’attribuzione delle fonti per fidarsi di una risposta tecnica generata dall’IA e il 26,5% la giudica importante; in una domanda distinta, l’85,2% indica gli obiettivi o requisiti del progetto come contesto per gli assistenti, il 73,3% indica codice, repository o documentazione tecnica e il 44,0% richiama decisioni precedenti e relative motivazioni. I dati sulle fonti e quelli sul contesto provengono da domande distinte: non descrivono un unico comportamento.

Una fonte citata permette di seguire il percorso tra affermazione e informazione di partenza. Per una risposta su un’API, per esempio, il riferimento utile è quello che consente di riconoscere la versione e il comportamento documentato; per una modifica al progetto conta anche il codice effettivamente presente nel repository. La citazione rende l’affermazione controllabile, ma resta da accertare che il passaggio richiamato sostenga davvero la conclusione.

Il contesto spiega anche perché una risposta tecnicamente plausibile possa essere inadatta a un progetto. Un assistente che conosce la sintassi ma ignora un vincolo di compatibilità, una decisione presa dal team o un requisito non scritto può proporre codice funzionante nel caso più semplice e sbagliato per l’applicazione reale. La verifica riguarda quindi sia il comportamento della soluzione sia la sua corrispondenza alle esigenze che l’hanno motivata.

Che cosa separa una proposta da una modifica approvata

La fiducia condizionata può tradursi in un controllo ripetibile dell’output prima che entri nel lavoro condiviso. Sono criteri professionali ricavati dalle condizioni espresse nel sondaggio, non una procedura la cui efficacia sia stata misurata dall’indagine:

• Requisito: il cambiamento risolve il problema richiesto e rispetta i vincoli del progetto, compresi quelli che la richiesta all’assistente non riportava?
• Origine: le affermazioni tecniche si possono ricondurre a documentazione o codice identificabili e pertinenti alla versione in uso?
• Comportamento: i controlli coprono il risultato atteso, un caso limite e una possibile regressione nel sistema esistente?
• Responsabilità: chi approva la modifica sa spiegare perché è corretta e quali conseguenze della scelta rimangono a suo carico?

Un test superato è un indizio utile, ma può riflettere lo stesso presupposto errato che ha guidato la soluzione. Quando requisiti, fonti e comportamento sono osservabili, un revisore può contestare quel presupposto prima che la modifica sia accettata. L’IA può produrre la prima risposta, mentre la decisione che la rende parte del software resta tracciabile e attribuibile a una persona.

Leggi anche:

• Un RAG sui documenti non basta: senza citazioni gli errori restano invisibili
• Il G7 crea un gruppo sulla sicurezza IA: gli standard restano da scrivere
• Prompt injection negli agenti IA: il filtro da solo non basta