L'AI scrive gran parte del codice di chi la produce: cosa significa per chi assume sviluppatori

C'è un dato che dovrebbe far fermare a pensare chiunque guidi un team di sviluppo: secondo i numeri interni pubblicati da Anthropic nel saggio When AI builds itself, a maggio 2026 oltre l'80% del codice mergiato dentro l'azienda è scritto da Claude, contro le singole cifre percentuali di prima del lancio di Claude Code a febbraio 2025. Nello stesso periodo, le misurazioni indipendenti di METR mostrano che la durata dei task che un modello completa in autonomia raddoppia circa ogni quattro mesi, passando dai circa quattro minuti di Claude Opus 3 (marzo 2024) alle dodici ore di Opus 4.6 due anni dopo. E un'azienda italiana citata pubblicamente da Anthropic, Bending Spoons, dichiara che la maggioranza dei suoi code change è ormai co-autorata con Claude Code. Lavoro con modelli di questo tipo ogni giorno, in una pipeline che orchestra l'automazione su oltre cinquanta codebase, quindi parto da una posizione di parte: ma proprio per questo voglio leggere il fenomeno da ingegnere, non da profeta. Perché qui non c'è niente di apocalittico e niente di magico: ci sono implicazioni precise per chi assume sviluppatori, fa review e decide come è fatto un team.

La prima cosa da fare è disinnescare l'isteria, in entrambe le direzioni. Questi numeri non dicono "i programmatori sono finiti", e non dicono nemmeno "è tutto marketing". Dicono una cosa più sottile e più utile: il punto dove si concentra il valore del lavoro umano si sta spostando, e un'organizzazione che non sposta con lui i suoi processi di assunzione e di controllo qualità rischia di pagare l'accelerazione senza incassarne i benefici.

La domanda giusta non è "l'AI sostituirà gli sviluppatori?". È: se l'AI assorbe i compiti su cui oggi si formano i junior, da dove arriverà il senior judgment di domani, e chi resta in grado di capire il codice quando si rompe?

Che cosa significa davvero che l'80% del codice di un'azienda AI è scritto dall'AI?

Significa molto meno di quanto il titolo lasci intendere, e va detto con onestà perché è esattamente il tipo di claim che un decisore deve saper pesare. Quel numero è un dato interno autodichiarato da una parte interessata, non una misura verificabile da terzi, e Anthropic stessa lo accompagna con un caveat netto: le righe di codice (otto volte tante per ingegnere al giorno nel secondo trimestre 2026 rispetto al 2024) sovrastimano "quasi certamente" il vero guadagno di produttività. Generare molto codice non equivale a produrre molto valore: parte di quel codice è boilerplate, scaffolding, test, migrazioni meccaniche, cioè proprio il lavoro a basso information gain in cui un modello eccelle. Un sondaggio interno di Anthropic su 130 dipendenti research, a marzo 2026, stimava un uplift mediano di quattro volte, ma l'azienda dichiara che il guadagno reale è "somewhat lower".

La distinzione che conta, e che separa l'analisi seria dal clickbait, è tra tre strati di evidenza con citabilità decrescente: i benchmark pubblici di terzi (METR, SWE-bench, CORE-Bench) sono il dato più solido; i numeri interni di Anthropic vengono dopo, con attribuzione e caveat; le proiezioni del tipo "task da settimane-persona nel 2027" sono estrapolazioni che la fonte stessa qualifica come condizionali, non fatti. Tenere separati questi tre strati è la differenza tra informare un consiglio di amministrazione e spaventarlo. Il recursive self-improvement pieno, lo scenario in cui un sistema progetta in autonomia il proprio successore, resta per ammissione esplicita di Anthropic uno scenario su cui l'azienda è "least certain": materiale da inciso, mai da tesi portante di una decisione di assunzione.

Resta però un fatto strutturale che non dipende da quale numero scegli di credere, ed è quello che cambia l'organizzazione del lavoro: l'accelerazione non elimina il collo di bottiglia, lo sposta. È la legge di Amdahl applicata a un'azienda. Quando scrivere codice costa quasi zero, il vincolo si trasferisce a valle, su ciò che non è stato accelerato: la code review, la decisione di cosa costruire, la verifica che il risultato faccia davvero quello che serve. Anthropic lo ammette parlando della propria pipeline interna, dove il ritmo è oggi dettato dalla revisione umana. Per un'azienda che adotta agenti senza ridisegnare il processo a valle, il risultato è prevedibile: un imbuto di codice generato che si accumula davanti a una capacità di review invariata.

Se stai valutando come integrare strumenti AI nel ciclo di sviluppo del tuo team senza creare debito tecnico nascosto, nel mio hub dedicato all'AI per le aziende raccolgo gli articoli tecnici con la metodologia che applico, dalla governance dei costi alla validazione dell'output.

Dove l'AI assorbe il lavoro e dove resta il giudizio umano

Per ragionare da architetto e non per slogan, conviene separare con precisione i compiti che un modello assorbe bene da quelli che restano saldamente umani. Non è una linea netta e si muove nel tempo, ma la direzione è chiara e immediatamente utile a chi deve decidere chi assumere e per fare cosa.

Il vantaggio comparato umano, oggi, è quello che Anthropic chiama research taste: scegliere quali problemi contano, di quali risultati fidarsi, quando un approccio è un vicolo cieco. È un giudizio che si costruisce con gli anni, ed è esattamente qui che si annida il rischio più grosso e meno discusso.

Se l'AI fa il lavoro dei junior, da dove arriva il senior di domani?

Questa è la domanda che un imprenditore o un responsabile delle assunzioni dovrebbe portarsi a casa, perché tocca la sostenibilità del team su un orizzonte di cinque o dieci anni, non la produttività del prossimo trimestre. Il senior judgment non nasce dal nulla: si forma facendo, per anni, proprio quei compiti formativi (scrivere il boilerplate, sistemare il bug banale, leggere molto codice altrui) che oggi l'AI assorbe per prima. La stessa agenda di ricerca dell'Anthropic Institute solleva il problema in modo esplicito: se l'AI assorbe i compiti junior che formavano gli esperti, da dove arriva il senior judgment futuro? È una domanda aperta, non una previsione, e va trattata come tale, ma per chi assume oggi ha una traduzione concreta e immediata.

Tagliare le posizioni junior perché "tanto le fa l'AI" significa ottimizzare il conto economico di quest'anno bruciando la pipeline dei senior che ti serviranno fra cinque. È un debito tecnico organizzativo, e come ogni debito tecnico non si vede finché non scade.

Il contesto italiano rende il punto ancora più tangibile. Secondo la ricerca dell'Osservatorio Artificial Intelligence del Politecnico di Milano presentata il 5 febbraio 2026, il 41% dei lavoratori italiani che usano strumenti AI svolge attività che altrimenti non sarebbe in grado di fare, e gli annunci di lavoro che richiedono competenze AI sono cresciuti del 93% nel 2025. La lettura corretta non è "servono meno persone", è "servono persone diverse, capaci di dirigere e verificare il lavoro dell'AI invece di limitarsi a produrlo". Chi assume dovrebbe smettere di cercare il coder veloce e cominciare a cercare chi sa leggere criticamente il codice generato, riconoscere quando è plausibile ma sbagliato, e prendersi la responsabilità di un rilascio. È un profilo più raro e più costoso, non meno.

In pratica, questo ribalta il modo in cui si compone un organigramma tecnico. Per anni la struttura tipica è stata una piramide larga alla base, con molti junior che producevano e pochi senior che dirigevano; la dinamica che questi numeri descrivono comprime quella base, perché la produzione pura diventa la parte più automatizzabile del lavoro. Ma comprimere la base senza ripensare la formazione significa segare il ramo su cui poggia il vertice: i senior di domani sono i junior di oggi, e se i junior non toccano più i compiti formativi non maturano il giudizio che li renderà senior. La risposta organizzativa che propongo ai team che seguo non è "assumere meno", è cambiare cosa fa un junior: meno produzione di boilerplate, che ormai costa quasi nulla, e molto più affiancamento sulla review, sull'architettura e sulla lettura critica del codice generato, in modo che il percorso di crescita passi dal verificare e capire, non solo dallo scrivere. È un investimento controintuitivo, perché chiede di pagare una seniority che si forma più lentamente e con strumenti diversi, ma è l'unico che protegge la capacità del team di sopravvivere alla prossima accelerazione invece di restarne ostaggio.

C'è poi una contromisura tecnica che vale come principio organizzativo: la code review va promossa da rituale a gate di qualità presidiato. Anthropic riporta, sempre come dato interno, che una review automatica retrospettiva avrebbe intercettato circa un terzo dei bug dietro a incidenti passati. Il numero va preso con le pinze (fonte interna, metodologia non pubblica), ma l'indicazione operativa è solida: usare un modello come primo revisore in continuous integration ha senso, a patto che il revisore finale e responsabile resti umano. Ne ho scritto in dettaglio impostando una pipeline di code review assistita da LLM su GitHub e GitLab: il punto non è far approvare il codice all'AI, è usarla per ampliare la superficie di controllo umana, non per sostituirla.

Il rischio della cascata: codice che nessuno comprende a fondo

C'è un'ultima implicazione, la più insidiosa perché silenziosa. Quando una quota crescente del codice è generata e mergiata con una supervisione superficiale, si accumula una massa di software che funziona ma che nessuno comprende davvero a fondo. Finché tutto va bene non è un problema. Lo diventa il giorno in cui qualcosa si rompe in produzione e serve un modello mentale del sistema per fare debug: a quel punto, se quel modello mentale non vive nella testa di nessuno perché il codice è "uscito da un agente", la velocità di rimedio crolla proprio quando serve di più. È la versione moderna di un problema vecchio, quello del progetto legacy senza documentazione su cui ho fatto subentro decine di volte, ma accelerato: il legacy si forma in mesi, non in anni.

La difesa non è rallentare l'adozione, è governarla. Significa pretendere che ogni componente generato abbia un proprietario umano che lo capisce, mantenere viva la disciplina del why (perché questa scelta, non solo cosa fa il codice) nelle pull request, e accettare che il ritmo reale del team sia quello del suo collo di bottiglia non accelerato, la revisione, non quello esibito dal contatore di righe. Un test concreto, da fare oggi sul proprio team: prendere a campione un componente generato negli ultimi mesi e chiedere chi, in azienda, è in grado di spiegarne il funzionamento e modificarlo senza ripartire da zero. Se la risposta è "nessuno", quel componente non è un asset, è una passività latente, e moltiplicarlo a velocità di agente significa solo accumulare più in fretta un rischio che si manifesterà tutto insieme. La metrica di salute che conterei non è quanto codice produce il team, è quanta parte del codice in produzione qualcuno padroneggia davvero. Su come stia evolvendo davvero la capacità autonoma dei modelli, al netto dell'hype, ho analizzato i limiti e la metodologia dei benchmark in METR e il time-horizon dei modelli, progressi reali e limiti di misura; e sul cambio di ruolo dell'ingegnere, da produttore di codice a gestore dell'intento e garante della qualità, ho scritto in l'ingegnere senior come intent manager nell'era degli agenti.

Il quadro, messo insieme, non autorizza né il panico né l'euforia. L'AI sta diventando uno strumento di produzione straordinario per il codice a basso giudizio, e questo è un guadagno reale che chi non lo coglie pagherà in competitività. Ma sposta il valore umano verso l'alto, sulla scelta dei problemi, sull'architettura e sulla responsabilità del rilascio, e mette sotto stress proprio i meccanismi (la formazione dei junior, la review, la comprensione profonda del sistema) che garantiscono la salute di un team nel tempo. Chi assume sviluppatori farebbe bene a leggere questi numeri non come una scusa per tagliare, ma come un invito a ridisegnare i ruoli e a investire dove l'AI non arriva. Se stai affrontando questa transizione e vuoi capire come integrare gli agenti nel tuo ciclo di sviluppo senza accumulare debito tecnico o organizzativo, puoi usare il modulo di preventivo gratuito: sette domande, due minuti, e ti dico se il tuo caso rientra nel mio perimetro o se ti conviene un'altra figura.