Nessuno paga i programmatori per il codice

La maggior parte delle discussioni sui lavori di programmazione parte troppo in basso nello stack. Parte da linguaggi, framework e fasce retributive. E manca il punto. Il lavoro di programmazione è prezzato in base alla prossimità a ricavi, controllo e responsabilità.

L'IA rende tutto questo più chiaro. Il risultato di produttività più noto in quest'area non è "pull request completate il 55% più velocemente". È l'esperimento controllato su GitHub Copilot di Peng et al.: gli sviluppatori che usavano Copilot hanno completato un singolo compito JavaScript delimitato il 55,8% più velocemente rispetto al gruppo di controllo, in uno studio su 95 sviluppatori professionisti. Si trattava di un compito in condizioni di laboratorio, non di telemetria di produzione, e lo studio non ha mostrato che la profondità strategica o la qualità del codice crescano allo stesso ritmo (arXiv; sintesi della ricerca di GitHub). Questo è il segnale che conta. L'implementazione di routine diventa più veloce. Il giudizio non si accumula automaticamente con essa.

Per questo non vedo i lavori di programmazione come una scala lineare da junior a senior. Vedo un mercato del lavoro in fase di rinegoziazione attorno a chi definisce i sistemi, chi assorbe il rischio e chi cattura il margine quando produrre codice costa meno.

Il vero mercato dei programmatori

La narrazione standard dice che i programmatori vendono competenze in un mercato aperto e che competenze migliori ottengono retribuzioni migliori. In pratica, le aziende pagano di più quando il software è vicino ai ricavi, vicino al controllo operativo o vicino al rischio regolamentato.

È per questo che lo stesso sviluppatore può essere infrastruttura strategica in un'azienda e capacità di consegna sostituibile in un'altra. La differenza di solito non è il codice. È la posizione del datore di lavoro nella catena del valore. Se il software definisce il prodotto, il potere di prezzo o il nucleo operativo, il lavoro di programmazione sale di status. Se il software è trattato come costo di implementazione, il management cerca standardizzazione, esternalizzazione e, ora, compressione assistita dall'IA.

Sul piano della domanda aggregata, i dati sono solidi. Il Bureau of Labor Statistics statunitense prevede che l'occupazione di sviluppatori software, analisti QA e tester crescerà del 15% tra il 2024 e il 2034, molto più della media, con circa 129.200 posizioni aperte in media ogni anno nel decennio (BLS Occupational Outlook Handbook). La retribuzione mediana annua degli sviluppatori software era di 133.080 dollari a maggio 2024 (BLS OOH). Numeri utili, ma incompleti. Dicono che il mercato è grande e ancora in crescita. Non dicono dove si trova il potere contrattuale al suo interno.

Il vero mercato dei programmatori è una negoziazione su specifica, dipendenza e rischio.

È anche per questo che il linguaggio del mercato del lavoro spesso oscura il potere. "Carenza di talenti" può significare più cose insieme: i datori di lavoro vogliono opzionalità, i lavoratori vogliono potere contrattuale, le piattaforme vogliono dipendenza e gli Stati vogliono capacità domestica senza sempre pagare per costruirla.

Per i datori di lavoro, questo cambia il disegno della forza lavoro. Per gli investitori, cambia il modo di leggere i margini del software. Per i decisori pubblici, cambia cosa conta come capacità digitale. Un Paese può avere molti programmatori e comunque non avere controllo, se gli strati decisivi sono importati, in licenza o bloccati nei contratti.

Una tassonomia migliore del lavoro di programmazione

Le categorie abituali — front-end, back-end, full-stack — descrivono dove sta il codice, non dove sta il valore. Aiutano ad allocare il lavoro. Non spiegano il potere contrattuale.

La lente più utile è la prossimità al controllo economico. Dividerei il lavoro di programmazione in tre strati.

• I System Architect definiscono i confini: strutture dati, interfacce, modelli di permessi, interazioni tra servizi, assunzioni di affidabilità e tolleranza ai guasti. Il loro lavoro determina il valore delle opzioni future.
• I Product Engineer traducono requisiti commerciali disordinati in software coerente sotto vincoli reali. Gestiscono ambiguità, compromessi e logica di dominio.
• Gli Implementation Specialist eseguono compiti delimitati dentro framework, flussi di lavoro e piattaforme consolidati. Restano necessari, ma sono lo strato più facile da misurare, standardizzare e comprimere.

Questa gerarchia è economica, non morale.

Lo strato superiore cattura più della retribuzione. Gli architetti influenzano la scelta dei fornitori, il disegno del cloud, la postura di sicurezza e il costo futuro delle integrazioni. I product engineer determinano se l'intuizione dell'azienda si consolida in software durevole o degrada in consegne fragili. Gli implementation specialist sono sotto la pressione maggiore, perché il loro output è il più facile da definire e confrontare.

Se un ruolo viene misurato principalmente sul volume di ticket, prima o poi il management proverà a comprimerne il prezzo.

Due ruoli adiacenti contano più di quanto molte aziende ammettano.

Primo, il data strategist: la persona che capisce quali dati possono essere raccolti, come possono muoversi, chi può accedervi e dove la governance diventa vantaggio competitivo.

Secondo, il regulatory engineer: la persona che traduce obblighi legali, di audit, di sicurezza e di conformità in controlli di sistema. Nei settori regolamentati, questo ruolo non supporta l'ingegneria dall'esterno. Decide cosa può essere venduto, comprato o messo in produzione.

Il diagramma qui sopra indica questi ruoli, ma vanno intesi come sovrapposizioni alla struttura a tre strati, non come una tassonomia separata. Strategia dei dati e ingegneria regolatoria possono stare dentro il lavoro di architettura e di prodotto. È lì che molte aziende oggi creano o perdono controllo.

Domanda, retribuzioni e dove viene catturato il valore

I programmatori non guadagnano perché un linguaggio è di moda. Guadagnano perché il loro datore di lavoro opera in un settore in cui il software incide su margini, costi di cambio fornitore o esposizione regolatoria.

È per questo che le medie del mercato del lavoro ingannano i consigli di amministrazione. Appiattiscono la differenza tra software come asset centrale e software come necessità amministrativa. Se si vogliono capire i lavori di programmazione, bisogna partire dalla dipendenza del datore di lavoro dai sistemi proprietari.

Uno sviluppatore che lavora su logiche di pricing, sistemi transazionali, underwriting, motori decisionali interni o flussi SaaS ad alta dipendenza è più vicino alla cattura del valore di uno sviluppatore che mantiene funzionalità web generiche in un contesto a basso margine. Stessa occupazione in senso ampio. Posizione economica diversa.

Separerei la domanda in due motivazioni del datore di lavoro:

• Difesa dei ricavi: le aziende pagano quando il software protegge potere di prezzo, retention, velocità o esclusività operativa.
• Contenimento dei costi: le aziende assumono con cautela quando il software è trattato come costo infrastrutturale e il procurement può spingere le tariffe verso il basso.

Un test semplice funziona bene. Se questo software si guasta, l'azienda perde ricavi, perde controllo o perde soltanto comodità? Quella risposta dice più dello stack.

Non intendo simulare precisione su retribuzioni per ruolo e settore dove i dati comparabili sono deboli. Conta di più il pattern.

System Architect

Product Engineer

Implementation Specialist

L'errore è leggere tutto questo come una pura storia di talento. È una storia di allocazione del capitale. Margini più forti permettono alle aziende di comprare lavoro migliore, ma il punto più profondo è che possono giustificarlo perché il software sta dentro il nucleo competitivo.

Per questo sono scettico sulle affermazioni generiche di carenza o eccesso universale di programmatori. Ci sono carenze in alcune fasce di lavoro strategico e abbondanza in quelle più commoditizzate. Gli investitori che guardano a questa divisione attraverso il ciclo dell'IA dovrebbero leggere La corsa all'oro dell'IA con la lente di chi cattura il margine quando la produzione costa meno ma il controllo diventa scarso.

I segnali di hiring che contano

La maggior parte dei funnel di selezione per programmatori è costruita per la leggibilità. I recruiter cercano framework. I manager chiedono anni di esperienza con una libreria. I candidati imparano a rispecchiare le parole chiave. Efficiente, ma debole.

La conoscenza dei framework è deperibile, insegnabile e facile da imitare. Il segnale più forte è il giudizio.

Questo conta ancora di più nello sviluppo assistito dall'IA, perché la competenza di superficie costa meno da simulare. Se lo screening continua a premiare la finitura rispetto al ragionamento, le aziende sopravvaluteranno la fluidità e sottovaluteranno la competenza sistemica.

I team raramente falliscono perché nessuno ricordava una API. Falliscono perché nessuno capiva il sistema che stava modificando.

Ricostruirei l'hiring attorno a tre segnali.

Pensiero sistemico

Il candidato sa spiegare come una decisione influisce su affidabilità, latenza, confini di sicurezza, qualità dei dati e manutenibilità futura in altre parti del sistema?

Le risposte forti includono compromessi. Le risposte deboli restano locali.

Scomposizione dei problemi

Il candidato sa trasformare un obiettivo di business vago in componenti, dipendenze, sequenze e vincoli espliciti?

Troppi colloqui testano la soluzione di puzzle delimitati anziché la conversione dell'ambiguità organizzativa in lavoro eseguibile.

Navigazione dell'astrazione

Il candidato sa usare servizi gestiti, API, piattaforme interne e codice generato senza perdere di vista ciò che conta sotto la superficie?

Sta diventando un marcatore centrale di seniority. Preferirei assumere qualcuno che sa quando fidarsi di un'astrazione e quando ispezionare sotto, piuttosto che qualcuno che recita la sintassi sotto pressione.

Ottenere evidenze migliori nei colloqui è semplice:

• Giudizio architetturale: chiedere di una volta in cui il candidato ha rifiutato un'implementazione più rapida perché creava costi a valle o rischi di governance.
• Gestione dei vincoli: proporre uno scenario con richieste in conflitto tra prodotto, sicurezza e operations.
• Alfabetizzazione al guasto: chiedere cosa monitorerebbe dopo il deployment, cosa si aspetta si rompa per primo e come lo rileverebbe.

Esercizi di coding brevi abbinati a una design review rivelano di solito più di take-home maratona o teatro dei puzzle.

Come l'IA cambia il ruolo del programmatore

L'IA non comprime la programmazione in un unico lavoro più efficiente. Allarga il divario tra esecuzione di routine e controllo ad alto giudizio.

Le evidenze qui richiedono attenzione.

L'esperimento su Copilot di Peng et al. ha mostrato un completamento più rapido su un singolo compito JavaScript delimitato (arXiv). McKinsey ha riportato guadagni sostanziali su alcuni compiti software in contesti enterprise, tra cui scrittura di nuovo codice, documentazione e refactoring, ma ha anche rilevato che i guadagni calano bruscamente su lavoro a complessità più alta e codebase non familiari (McKinsey). E le evidenze non vanno tutte in una direzione: un trial randomizzato del 2025 condotto da METR ha rilevato che sviluppatori open source esperti, al lavoro sulle proprie codebase mature, erano in realtà più lenti con gli strumenti IA di inizio 2025, pur essendo convinti di essere stati più veloci (METR). I report Octoverse di GitHub sono utili come telemetria su adozione e attività di piattaforma — per esempio, la rapida diffusione di Copilot tra i nuovi sviluppatori e la crescita dei repository legati all'IA — ma non sono la stessa cosa di una misura causale controllata della qualità dell'output o della performance strategica (GitHub Octoverse).

Il pattern comune è abbastanza chiaro. I sistemi generativi sono più forti sul lavoro di implementazione delimitato, dove i pattern sono comuni, le interfacce leggibili e il successo verificabile rapidamente. Sono più deboli dove il vero compito è scegliere compromessi in condizioni di incertezza, conciliare vincoli in conflitto e vedere effetti di secondo ordine attraverso sistemi e istituzioni.

Per i datori di lavoro, questo conta più dei titoli sulla velocità. Un output più rapido crea valore durevole solo se qualcuno controlla ancora architettura, standard di testing, assunzioni di sicurezza e gestione dei guasti. Se quello strato di controllo è sottile, l'IA aumenta la velocità con cui le organizzazioni accumulano debito tecnico e rischio di conformità.

Per questo non leggo l'IA come un semplice sostituto dei programmatori. La leggo come una ridistribuzione del valore dentro la funzione.

L'esecuzione di routine diventa più facile da comprare, misurare e mettere sotto pressione sul prezzo. Il coordinamento ad alto giudizio diventa più prezioso, perché governa le condizioni alle quali l'output assistito dalle macchine entra in produzione.

Il B+ Trap nel lavoro di programmazione

Il mio framework del B+ Trap si applica qui direttamente. L'IA abbassa il costo di produrre lavoro plausibile. Non abbassa il costo di sbagliare in produzione.

Questa distinzione ridisegnerà hiring e composizione dei team. Una quota più ampia della forza lavoro saprà generare codice dall'aspetto accettabile. Una quota più piccola saprà interrogare i casi limite, identificare lo stato nascosto, ragionare sulla propagazione dei guasti e decidere se una soluzione generata è compatibile con la posizione commerciale e regolatoria dell'azienda.

Il centro si affolla.

I datori di lavoro che confondono la fluidità di superficie con la competenza sistemica sopravvaluteranno la profondità del proprio bench di ingegneria. Potrebbero pensare di aver aggiornato la capacità quando hanno solo aumentato l'output allo strato di implementazione.

L'IA cambia anche i rapporti di supervisione. Un technical lead forte, un architetto orientato al prodotto o un engineering manager può dirigere più lavoro di implementazione di prima, che quel lavoro sia svolto da personale junior, contractor o team assistiti dall'IA. Questo aumenta lo span of control dei migliori operatori e indebolisce la posizione dei lavoratori il cui contributo sta principalmente nell'esecuzione lineare.

La seniority viene quindi ridefinita. L'anzianità di servizio e la confidenza con uno stack sono segnali più deboli della capacità di fissare vincoli per sistemi che combinano codice generato, infrastruttura gestita, policy interne e dipendenze esterne.

Ho fatto un argomento affine in perché i migliori diventano imbattibili e come recuperare. Quando l'esecuzione costa meno, specifica, revisione e accettazione diventano asset più scarsi.

Contratti, regolamentazione e il prossimo strato di controllo

Il cambiamento più importante nel lavoro di programmazione potrebbe non avvenire affatto nell'editor. Avviene nei termini di procurement, nelle clausole di responsabilità, negli allegati di sicurezza, nei diritti di audit e nelle regole d'uso dei modelli.

È lì che molte organizzazioni oggi decidono quali pratiche software sono accettabili.

Quando le aziende adottano lo sviluppo assistito dall'IA, diverse domande diventano immediatamente operative. Chi porta la responsabilità se il codice generato introduce una falla di sicurezza? Come viene gestita la proprietà intellettuale quando output generato dalle macchine entra in software commerciale? Quale codice o quali dati possono essere esposti a modelli esterni durante sviluppo, testing o debugging? Quali giurisdizioni governano trattamento, logging e conservazione?

Non sono questioni di conformità periferiche. Plasmano la pratica ingegneristica quotidiana.

Un team di sviluppo può volere velocità. Il procurement può richiedere ambienti approvati, audit trail, controlli di conservazione e clausole di manleva. Il legale può limitare i modelli esterni per codice o dati sensibili. La sicurezza può imporre soglie di revisione che restringono cosa "automatizzato" può significare in produzione.

Il ruolo del programmatore si fonde quindi con la governance nei contesti regolamentati o sensibili alla sicurezza. Questo include:

• Regole di gestione dei dati: cosa può muoversi tra ambienti, e a quali condizioni
• Disegno del controllo degli accessi: garantire che i permessi riflettano impegni contrattuali e legali
• Requisiti di tracciabilità: rendere decisioni e percorsi di codice rivedibili a posteriori
• Flussi di assurance: costruire percorsi di revisione, testing ed escalation che soddisfino acquirenti, auditor e regolatori

Il programmatore che comprende questi vincoli diventa strategicamente prezioso anche se scrive meno codice grezzo di un puro implementation specialist.

I contratti oggi determinano più comportamento del software di quanto molti ingegneri vogliano ammettere.

Questo è particolarmente rilevante in Europa, dove la governance arriva spesso prima e in modo più esplicito attraverso procurement e regolamentazione. Ma la dinamica è più ampia dell'Europa. Grandi imprese e acquirenti pubblici stanno trasformando l'uso dell'IA e del software in questioni di controllabilità, provenienza e responsabilità.

Se si vuole capire l'apertura che questo crea da un'angolazione di policy europea, la cornice giusta non è ritardo contro velocità, ma spazio strategico per plasmare norme applicabili. Per questo guarderei al rinvio dell'AI Act come a una finestra di opportunità, se usata bene. L'opportunità non è retorica. Sta in chi trasforma l'ambiguità regolatoria in vantaggio operativo prima che il campo si consolidi.

Cosa dovrebbero fare i decisori

La risposta utile non è il panico da automazione né la nostalgia per il codice scritto interamente a mano. È il disegno istituzionale.

Datori di lavoro

Non organizzate la forza lavoro di ingegneria solo attorno alle etichette di stack. Costruite il disegno dei ruoli attorno alla funzione economica.

Separate l'autorità architetturale dalla delivery di routine. Se nessuno possiede i confini di sistema, l'output assistito dall'IA aumenterà l'efficienza locale moltiplicando l'incoerenza a livello di sistema.

Ridisegnate hiring e promozioni attorno al giudizio. Premiate chi riduce la complessità futura, non solo il throughput presente.

Portate legale, procurement e sicurezza prima nelle decisioni software. Se queste funzioni arrivano solo alla firma del contratto o alla review di deployment, i team costruiranno processi che poi dovranno smontare.

Una checklist pratica:

• Mappare la prossimità al valore: identificare quali ruoli di programmazione sono più vicini a ricavi, controllo e rischio regolamentato.
• Proteggere l'apprendistato: non lasciare che lo sviluppo junior collassi in abitudini prompt-e-accetta senza apprendimento sistemico.
• Strumentare la revisione: tracciare dove il codice generato o fortemente astratto entra nei percorsi critici e chi lo ha approvato.
• Prezzare la resilienza: la capacità di implementazione a buon mercato si trasforma spesso in remediation costosa.

Investitori

Smettete di trattare l'organico di ingegneria come una semplice voce di costo. Nei business ad alta intensità software, il lavoro di programmazione può essere un fossato competitivo o un input commodity mascherato.

Cinque domande di due diligence contano. Chi possiede le astrazioni centrali? Quanta logica di prodotto è proprietaria? Dove sta il rischio contrattuale? L'azienda può ancora rilasciare sotto regole di procurement più strette? Quali parti dell'organizzazione di ingegneria diventano sostituibili man mano che l'uso dell'IA si diffonde?

Le risposte di solito dicono più della demo.

Due pattern contano:

• Pattern buono: l'azienda usa l'IA per comprimere l'implementazione di routine concentrando il giudizio esperto su architettura, sicurezza e logica di dominio.
• Pattern cattivo: l'azienda celebra un output più alto ma non sa dimostrare un controllo più stretto su qualità, responsabilità o manutenibilità.

Nel secondo caso, l'efficienza apparente è spesso costo differito.

Decisori pubblici

Se gli Stati tengono alla capacità digitale, dovrebbero smettere di misurarla solo attraverso le pipeline di laureati o il conteggio delle startup. La capacità sovrana dipende anche da chi sa specificare, verificare, acquistare e governare sistemi software in condizioni giuridiche domestiche.

La policy dovrebbe quindi concentrarsi su tre strati.

Primo, il procurement. Gli acquirenti pubblici possono plasmare il mercato richiedendo tracciabilità, disciplina di sicurezza e responsabilità sostanziale, anziché vago teatro di conformità all'IA.

Secondo, la formazione del lavoro. I sistemi formativi dovrebbero produrre non solo programmatori, ma persone capaci di combinare il software con il disegno di sistemi, la conoscenza di dominio e l'alfabetizzazione regolatoria.

Terzo, la ritenzione istituzionale. Se lo Stato sa acquistare software ma non sa valutarlo, negoziarne i termini o ispezionarne le dipendenze, non controlla l'infrastruttura digitale.

La capacità software pubblica non si misura solo da quante persone sanno programmare. Si misura dalla capacità delle istituzioni di governare il codice da cui dipendono.

Il punto strategico è semplice. I lavori di programmazione oggi sono definiti meno dalla sintassi e più da chi fissa i vincoli, chi possiede l'astrazione e chi assorbe il danno quando l'implementazione accelerata va storta.

Se vuoi altre analisi come questa, iscriviti alla Newsletter di ELECTE. Scrivo ogni settimana di economia politica e governance dell'IA, con un focus su chi la controlla, chi ne profitta, chi la regola e cosa fa a mercati, contratti e lavoro.

Fonti

• U.S. Bureau of Labor Statistics: Software Developers, Quality Assurance Analysts, and Testers
• Peng et al., "The Impact of AI on Developer Productivity: Evidence from GitHub Copilot" (arXiv)
• GitHub research summary of the Copilot productivity study
• McKinsey: Unleashing developer productivity with generative AI
• GitHub Octoverse: A new developer joins GitHub every second as AI leads TypeScript to #1

Fabio Lauria

CEO & Founder, ELECTE

Ogni settimana approfondiamo il tema dell'intelligenza artificiale senza lasciarci influenzare dal clamore mediatico, basandoci su dati, analisi e un punto di vista indipendente.