Copilot l’ha scritto, ma chi ne è il proprietario? Il divario di governance che i team di ingegneria potrebbero trascurare

Un ingegnere apre Copilot per aiutare a redigere il codice per il sito di un cliente. In pochi secondi, riceve del codice che in precedenza avrebbe richiesto molto più tempo per essere scritto manualmente. Per molti sviluppatori web e aziende che ottimizzano i loro siti, è normale chiedersi: il codice è affidabile? È sicuro? Deve essere revisionato prima dell’implementazione? Queste domande ricadono tutte sotto l’ombrello di un’unica domanda: Chi sarà ritenuto responsabile del coding assistito dall’IA? E, soprattutto, chi possiede il guadagno di produttività?

Se l’IA consente a un team di ingegneria di completare più lavoro nello stesso tempo, tutti possono trarre maggior beneficio da quel valore economico. Questo potrebbe tradursi in uno sviluppatore che risparmia tempo, un datore di lavoro che ottiene più valore dalle ore risparmiate, o un cliente che riceve ciò per cui ha pagato con ore di margine. Indipendentemente da come i benefici del tempo risparmiato si manifestino, ciò che rimane al centro dell’attenzione è come il lavoro viene governato e prezzato.

AI and Coding is Becoming Unavoidable

Gli strumenti di programmazione basati sull’IA stanno rapidamente guadagnando terreno e facendo progressi nello sviluppo mainstream. Secondo il 2025 Stack Overflow Developer Survey, l’84% degli intervistati stava già utilizzando o prevedeva di utilizzare strumenti di IA nel loro processo di sviluppo.

Sebbene l’implementazione dell’IA nei flussi di lavoro degli sviluppatori web stia diventando più comune, persiste ancora esitazione sulla sua affidabilità. La stessa indagine ha rilevato che il 46% non aveva piena fiducia nell’accuratezza dei risultati dell’IA, e circa il 66% ha segnalato le soluzioni di IA “quasi corrette, ma non del tutto” come fonte di frustrazione.

Il dibattito sull’IA nella programmazione che sta prendendo forma riguarda più la sua affidabilità che il fatto che quel codice crei più valore e chi sia responsabile di garantirlo.

AI Is Breaking the Relationship Between Hours and Output

La remunerazione per lo sviluppo software si è sempre basata sull’assunzione che l’output ingegneristico fosse strettamente correlato allo sforzo ingegneristico. Tuttavia, l’IA generativa ora complica questa equazione.

Un esperimento controllato che ha coinvolto 95 sviluppatori ha scoperto che i partecipanti con accesso a GitHub Copilot hanno completato un compito specifico di server HTTP JavaScript 55,8% più veloce di chi non ha accesso.

Ciò evidenzia che l’IA può accelerare lo sviluppo, potenzialmente senza sacrificare la qualità. Tuttavia, questi dati sono validi solo perché l’esperimento ha seguito un compito di programmazione molto specifico. Sebbene il compito sia stato completato più velocemente, ciò non significa che Copilot renda un’intera organizzazione ingegneristica più produttiva del 55,8%.

Un altro studio di ricerca esemplifica questa idea. Una sperimentazione che ha coinvolto 96 ingegneri software a tempo pieno di Google ha rilevato che gli sviluppatori che usavano l’IA hanno completato un compito di livello aziendale in circa 96 minuti, rispetto a 114 minuti per chi non la utilizzava. La stima aggiustata dei ricercatori suggeriva una riduzione di circa il 21% della durata del completamento. Tuttavia, lo studio non ha esaminato la qualità del codice generato dall’IA, né ha affrontato questioni di equità relative alla dipendenza dalla tecnologia.

Ci sono anche evidenze che l’IA rallenta i tempi di programmazione. Uno studio randomizzato condotto da METR ha coinvolto 16 sviluppatori open-source esperti che hanno lavorato su 246 problemi reali in repository a loro familiari. Utilizzando gli strumenti disponibili all’inizio del 2025, tra cui Claude Sonnet 3.5 e 3.7, nonché Cursor Pro, hanno impiegato circa il 19% di tempo in più per completare i loro compiti, nonostante molti credessero che questi strumenti avrebbero fatto risparmiare tempo.

Insieme, questi studi sovvertono le aspettative che l’IA consenta agli sviluppatori di lavorare più velocemente. Al contrario, rende il tempo e il valore degli sviluppatori meno prevedibili per le aziende che offrono servizi web e per i clienti che li ricevono.

The Pricing Problem Nobody Talks About

Tempo e Materiali (T&M) è un modello comune nello sviluppo web per l’acquisto di software, poiché affronta un problema ricorrente del settore: un progetto in evoluzione.

Con questo modello, invece di richiedere che ogni funzionalità o compito sia definito prima dell’inizio dello sviluppo, i clienti possono pagare per il tempo di ingegneria man mano che il progetto avanza e si modifica.

Tuttavia, l’IA sta creando intoppi in questo modello collaudato. Con la remunerazione direttamente legata alle ore di ingegneria, un tempo di sviluppo più efficiente può tradursi in meno ore fatturabili per i clienti. Se l’IA supporta gli stessi risultati in meno tempo, la tecnologia può creare valore per i clienti, ma la riduzione delle ore fatturabili comporta meno entrate per i fornitori.

La soluzione non è incoraggiare gli sviluppatori a lavorare più lentamente. Il modello T&M ora affronta un problema strutturale legato al modo in cui prezzi e incentivi sono progettati. Utilizzare tariffe orarie per determinare il valore può essere limitante. Un acquirente potrebbe conoscere esattamente il costo di ogni ora di ingegneria, ma rimanere incerto sull’investimento totale necessario per raggiungere il risultato desiderato.

Man mano che l’IA cambia la produttività ingegneristica, la domanda potrebbe spostarsi da:

“Quanto costa un’ora di sviluppatore?” → “Cosa succede al valore quando sono necessarie meno ore di sviluppatore?”

I risultati di METR complicano questa domanda. Se gli sviluppatori credono di poter risparmiare tempo quando, in realtà, impiegano più tempo, né l’adozione dell’IA né la produttività percepita sono sufficienti a dimostrare valore finanziario. Ecco perché le organizzazioni hanno bisogno di una governance in grado di misurare ciò che è realmente accaduto.

The Governance Gap Has Four Owners

Discutere della governance intorno allo sviluppo assistito dall’IA deve andare oltre le politiche che regolano quali strumenti gli sviluppatori possono utilizzare.

Esistono almeno quattro tipi di proprietà che le organizzazioni ingegneristiche dovrebbero definire.

1. Who owns the code?

L’IA può generare un’implementazione, ma non può diventare una scusa per uno sviluppo senza responsabilità. Qualcuno deve comunque essere responsabile della revisione, del testing e dell’approvazione del codice fino a quando non raggiunge lo stage di produzione.

2. Who owns the risk?

Il codice più veloce è utile solo se non causa problemi altrove. Uno studio empirico sul codice generato dall’IA ha identificato vulnerabilità di sicurezza nel 29,5% dei frammenti Python esaminati e nel 24,2% dei frammenti JavaScript. La ricerca ha anche identificato debolezze che coprono 43 categorie del Common Weakness Enumeration.

Tuttavia, lo studio ha scoperto che reinserire gli avvisi di analisi statica in Copilot Chat potrebbe correggere fino al 55,5% delle vulnerabilità di sicurezza identificate. La ricerca dimostra come l’IA possa creare e risolvere problemi di programmazione, ma le organizzazioni hanno bisogno di processi per determinare come convalidare i suoi risultati.

SP 800-218A del NIST riflette questo principio estendendo il suo Secure Software Development Framework con le migliori pratiche che affrontano l’IA generativa e i modelli di base a doppio uso.

3. Who owns the productivity gain?

Gli accordi commerciali fin dall’inizio sono essenziali per determinare chi dovrebbe ricevere i guadagni di efficienza. L’IA può aiutare i clienti a spendere meno, consentire ai team di consegnare più software, o non fornire alcun beneficio finanziario alla fine del progetto.

Ciò che rimane invariato è la necessità di processi trasparenti e della consegna di lavoro di qualità, concordato.

4. Who owns prioritization?

L’IA può rendere la generazione di funzionalità più economica e veloce, ma non può decidere se tali funzionalità siano necessarie.

In effetti, aumentare la capacità di sviluppo può rendere la priorità più importante. Quando i team possono costruire e sperimentare più velocemente, qualcuno deve ancora determinare quali risultati giustificano il budget disponibile e quali idee debbano essere abbandonate.

AI Governance Is Becoming a Finance Issue

Queste domande rendono la governance dell’IA sempre più rilevante. Immagina due partner di sviluppo che addebitano tariffe orarie simili.

Uno ha integrato l’IA in un solido processo ingegneristico e ottiene il risultato richiesto notevolmente più velocemente, mentre l’altro impiega più tempo. Confrontare solo le loro tariffe orarie non informa molto l’acquirente sui processi che eseguiranno.

Gli acquirenti dovranno valutare:

• Investimento totale previsto
• Responsabilità per gli overrun
• Controlli di qualità sul lavoro generato dall’IA
• Come vengono condivisi i guadagni di efficienza

Il modello T&M può rimanere utile per entrambe le parti se accettano consapevolmente l’incertezza nei servizi. Anche gli accordi a prezzo fisso possono funzionare quando i requisiti e le consegne sono stabili.

Tuttavia, l’IA rende anche interessanti strutture alternative da esaminare. Un approccio consiste nel stabilire un limite finanziario massimo mantenendo flessibile l’ambito. Poi, le funzionalità possono essere priorizzate in base al valore di business all’interno di quel modello.

Se l’ingegneria diventa più efficiente, i guadagni possono tradursi in capacità aggiuntive del prodotto anziché in tempo fatturabile aggiuntivo. Gli incentivi commerciali dovrebbero incoraggiare lo stesso risultato degli incentivi ingegneristici, creando software più utile nel modo più efficiente possibile.

The Same AI Conversation

I leader ingegneristici devono capire come gli incentivi commerciali influenzino la consegna. I team finanziari e di approvvigionamento hanno bisogno di una visibilità sufficiente sull’ingegneria assistita dall’IA per valutare se l’efficienza dichiarata sta fornendo valore misurabile.

Ciò significa che una governance dell’IA matura non può fermarsi alle liste di modelli approvati, ai controlli di sicurezza, alle politiche sui dati o ai requisiti di revisione del codice. Deve affrontare la responsabilità, il rischio finanziario, la priorità e la proprietà dei guadagni di produttività.

Ma c’è una seconda questione di proprietà che potrebbe avere un impatto molto maggiore sui budget tecnologici: chi possiede il valore creato o perso quando l’IA cambia la velocità con cui il software viene costruito?

Le organizzazioni che determinano se un’ingegneria più veloce produce effettivamente prodotti migliori, controllano gli investimenti e raggiungono risultati di business misurabili saranno quelle in grado di stare un passo avanti rispetto ai concorrenti.

Se il tuo team di sviluppo adottasse l’IA domani, il tuo attuale modello di governance e commerciale ti direbbe anche se ha reso la consegna più preziosa?