Programmare con l’IA: delegare senza perdere il controllo

Gli agenti di programmazione accelerano alcune attività, ma la loro supervisione richiede competenze che è necessario continuare a esercitare. Che cosa consentono davvero di affermare gli studi e gli ingegneri.

Un agente di programmazione può scrivere codice, eseguire comandi e concatenare diversi passaggi senza attendere ogni volta un’istruzione. Il lavoro dello sviluppatore cambia quindi: meno digitazione, più definizione delle istruzioni e verifica. Resta una questione meno evidente del risparmio di tempo: se si svolgono meno spesso alcune attività, come mantenere le competenze necessarie per individuare un errore o riprendere il controllo?

Questo rischio è discusso dagli ingegneri che usano questi strumenti ogni giorno, ma non va confuso con una perdita duratura di competenze dimostrata in tutti gli sviluppatori. Gli elementi disponibili descrivono soprattutto usi, percezioni ed esperienze limitate a compiti specifici. Consentono tuttavia di capire in quali casi la delega può diventare fragile e come rendere il controllo più concreto.

Delegare il codice non significa delegare la responsabilità

In un testo dedicato all’uso degli agenti di programmazione, Addy Osmani, ingegnere di Anthropic e membro del team Claude Code, distingue tre livelli di delega. Al primo, l’agente produce una proposta che la persona esamina. Al secondo, quella proposta diventa il punto di partenza del lavoro. Al terzo, viene adottata senza un vero controllo. I ricercatori di Wharton definiscono questo atteggiamento «capitolazione cognitiva».

La differenza dipende meno dallo strumento che dal ruolo mantenuto dall’utente. Uno sviluppatore può lasciare che un agente scriva una funzione, restando responsabile di capire che cosa fa, verificare che risponda all’esigenza e decidere se possa essere integrata. Al contrario, una risposta tecnicamente plausibile può essere accettata perché è presentata bene o perché il primo test viene superato.

Un test superato dimostra però soltanto ciò che verifica. Se riprende un’ipotesi errata della funzione che dovrebbe controllare, entrambi possono non rilevare il problema. Una verifica efficace consiste quindi anche nell’esaminare la portata del test: quali casi copre, quali tralascia e quali supposizioni bisogna accettare perché il risultato sia affidabile?

I vantaggi nell’uso non misurano l’apprendimento

Uno studio pubblicato da Anthropic nel 2025 offre una panoramica dei cambiamenti osservati all’interno dell’azienda. Si basa su un’indagine condotta tra 132 ingegneri e ricercatori, 53 interviste e l’analisi di 200 000 trascrizioni interne di Claude Code, raccolte a febbraio e ad agosto 2025. Nell’indagine, i dipendenti stimavano di usare Claude per il 59 % del loro lavoro e gli attribuivano un aumento medio della produttività del 50 %. Si tratta di cifre dichiarate: descrivono la loro percezione, non una misurazione indipendente del tempo effettivamente risparmiato.

L’analisi delle trascrizioni mostra invece un cambiamento nella distribuzione degli usi. Tra febbraio e agosto, la quota di trascrizioni classificate come relative all’implementazione di nuove funzionalità è passata dal 14,3 % al 36,9 %, mentre quella classificata come relativa alla progettazione o alla pianificazione del codice è passata dall’1 % al 9,9 %. Lo strumento concatenava inoltre più azioni prima di un nuovo intervento umano. Questi risultati indicano che i team affidavano a Claude Code compiti più complessi o più autonomi. Da soli, non misurano né un aumento del volume totale di lavoro né il livello di competenza di ciascuna persona.

Le interviste rivelano il possibile rovescio della medaglia. Alcuni partecipanti affermano di sentirsi più a proprio agio in ambiti che conoscevano poco, perché l’IA facilita la creazione di una prima versione o l’esplorazione di nuovo codice. Altri temono di imparare meno risolvendo i problemi da soli: leggere la documentazione, esaminare il funzionamento di uno strumento o seguire un errore può trasmettere conoscenze non indispensabili per la correzione immediata, ma che in seguito aiutano a comprendere il sistema nel suo insieme.

Anthropic precisa che i partecipanti sono dipendenti di un’azienda che sviluppa questi strumenti e vi hanno accesso in un contesto particolare. Le risposte possono inoltre essere influenzate dalla selezione delle persone intervistate e dal carattere dichiarativo di alcune misure. Questo lavoro fa luce sui compromessi osservati in quell’organizzazione; non consente di concludere che gli sviluppatori in generale perdano durevolmente le proprie competenze quando usano l’IA.

Supervisionare presuppone di sapere che cosa si sta controllando

È il paradosso pratico della supervisione: per valutare il codice di un agente, occorrono conoscenze sufficienti a individuare ciò che è pericoloso, incompleto o inadatto. Eppure, proprio i partecipanti intervistati da Anthropic esprimono preoccupazione per il mantenimento delle competenze necessarie sia per scrivere il codice sia per valutarlo criticamente. Alcuni affermano quindi di riservare del tempo alla programmazione senza IA, per continuare a esercitare queste capacità.

Questa scelta non risponde a tutte le domande. Resta in particolare da stabilire quali competenze siano indispensabili in un lavoro in cui gli strumenti cambiano i compiti affidati agli ingegneri. Alcuni dipendenti intervistati prevedono uno spostamento verso la progettazione, la revisione o il coordinamento degli agenti. Altri rimpiangono la pratica diretta del codice o si interrogano sulla formazione dei principianti. Lo studio riporta questi punti di vista, ma non stabilisce quale sarà il futuro della professione.

I risultati di un altro studio, discusso dai suoi autori su Wharton Magazine, richiamano l’attenzione sull’accettazione di una risposta generata. I partecipanti potevano consultare ChatGPT per risolvere quesiti di logica e ragionamento. Steven Shaw spiega che, negli esperimenti, le persone che avevano consultato lo strumento adottavano spesso la sua risposta, anche quando era errata. Questi esercizi fanno luce su un comportamento in una situazione sperimentale; non misurano né la qualità del lavoro di uno sviluppatore in azienda né un’erosione duratura delle sue capacità.

Un controllo proporzionato alla posta in gioco

Addy Osmani non raccomanda di verificare ogni compito con la stessa intensità. Una delega poco rischiosa e facile da correggere non richiede necessariamente lo stesso esame di una modifica che potrebbe incidere sulla sicurezza, sui dati o sulla messa in produzione. Prima di un compito importante, propone di formulare una propria ipotesi e poi cercare che cosa potrebbe rendere errata la risposta dell’agente. Consiglia inoltre di chiedergli di esplicitare le proprie scelte e i valori predefiniti utilizzati.

Per una modifica software, questi passaggi possono tradursi in domande concrete: quale comportamento deve cambiare? Quali parti del sistema saranno interessate? Quali casi copre davvero il test? L’agente ha introdotto una dipendenza o un’ipotesi che il team non ha esaminato? Una revisione utile non consiste soltanto nel rileggere il risultato, ma nel confrontarlo con criteri definiti prima di accettarlo.

La questione, quindi, non è scegliere tra scrivere ogni riga da soli e lasciare fare tutto a un agente. Si tratta di decidere quali operazioni si possono delegare, mantenere una comprensione sufficiente per supervisionare le decisioni importanti e verificare che le abitudini di lavoro continuino a sviluppare le competenze necessarie. La rapidità di esecuzione è visibile non appena viene generato il codice. La capacità di riprenderne il controllo, invece, si misura quando occorre spiegarlo, correggerlo o farlo evolvere.