5 aprile 2026 · 9 min lettura
Intelligenza ArtificialeOracle licenzia 18% del personale per finanziare $50 miliardi in AI. In Italia il tribunale di Roma legittima il licenziamento in contesto AI. Cosa significa per chi gestisce infrastruttura in autonomia.
Intelligenza Artificialeduck.ai promette chat AI senza tracciamento: nessun log, nessun IP, accordi con Anthropic e OpenAI. Ma DuckDuckGo ha già tradito questa fiducia una volta.
Iscriviti alla newsletter per ricevere i migliori articoli direttamente nella tua inbox.
I nuovi modelli Google Gemma 4 girano in homelab con Ollama. Il vero cambio di paradigma è nella licenza Apache 2.0, non nei benchmark.
Dev esperti con i migliori tool di AI disponibili a inizio 2025 — Cursor Pro con Claude Sonnet, copiloti di ultima generazione — hanno completato task reali su repository open source con 1 milione+ di righe di codice. Risultato: 19% più lenti. Non più veloci. Più lenti.
Questo è il dato centrale dello studio METR pubblicato a luglio 2025. Un randomized controlled trial con 16 sviluppatori esperti, 246 task reali, cinque anni di esperienza media a testa. Non un sondaggio di opinione. Non benchmark sintetici. Codice reale, repository reali, misurazione rigorosa.
Queste note sono importanti perché il dibattito su "l'AI sostituirà i programmatori" è pieno di dichiarazioni di CEO, slide di investor deck e demo accuratamente selezionate. I dati reali raccontano una storia più articolata — e più utile da capire se lavori con il codice ogni giorno, anche solo sul tuo homelab.
Dario Amodei, CEO di Anthropic, ha dichiarato a marzo 2025: "L'AI scriverà il 90% del codice entro 3-6 mesi." Stesso Amodei, in un'altra occasione: "Siamo a 6-12 mesi da modelli che fanno tutto ciò che fa un software engineer end-to-end." Sam Altman di OpenAI stima che in molte aziende l'AI gestisce già oltre il 50% del codice. Satya Nadella ha confermato che Microsoft, i tool di AI scrivono fino al 30% di tutto il nuovo codice dell'azienda.
I numeri di adozione sembrano dare ragione a questa narrativa. GitHub Copilot ha raggiunto 20 milioni di utenti cumulativi a metà 2025, con 4.7 milioni di abbonati pagati a gennaio 2026 e il 90% delle Fortune 100 come clienti. L'84% degli sviluppatori usa o pianifica di usare tool di AI (Stack Overflow Survey 2025). Nel 2023 l'AI scriveva il 46% del codice medio degli sviluppatori che usano Copilot — fino al 61% in progetti Java. Google dichiara che oltre il 30% del suo nuovo codice è generato dall'AI (dato Q1 2025). La base empirica sembra difficile da scalfire.
Il termine "vibe coding", coniato da Andrej Karpathy nel febbraio 2025, descrive l'approccio di chi usa LLM per generare intere applicazioni senza scrivere codice — e senza capirlo. Su certi repository greenfield, con stack standard, funziona sorprendentemente bene. Abbastanza bene da alimentare la narrativa.
Lo studio METR è metodologicamente solido perché usa un RCT — randomized controlled trial — lo stesso standard usato in medicina per testare l'efficacia di un farmaco. Sedici sviluppatori esperti, 246 task presi da issue reali di repository con 22.000+ star, media di 1 milione di righe di codice. Tool: Cursor Pro con Claude 3.5 e 3.7 Sonnet. I migliori tool disponibili al momento della ricerca.
Risultato: +19% di tempo con l'AI. Più lento.
La parte più interessante è il perception gap. Prima di ogni task, i dev prevedevano di essere il 24% più veloci grazie all'AI. Dopo averlo completato, credevano di essere stati il 20% più veloci. Erano invece il 19% più lenti. La discrepanza tra percezione e realtà è di circa 40 punti percentuali — e questo spiega perché la narrativa dominante è così difficile da scalfire.
Dove va il tempo? Solo il 44% delle generazioni venivano accettate. Il resto: review, test, modifica, rifiuto. Il ciclo edit-review-reject su codice generato dall'AI consuma più tempo di quanto risparmia la generazione iniziale.
Aggiornamento importante: a febbraio 2026, METR ha pubblicato un follow-up con tool più recenti (Claude Code, Codex). I dev originali ora mostrano un 18% di speedup (cioè più veloci, direzione opposta) (IC: -38% a +9%), i nuovi reclutati -4% (IC: -15% a +9%). Ma METR stessa definisce questi dati "evidenza molto debole" per bias di selezione: il 30-50% dei dev evitava di sottomettere task dove l'AI li avrebbe aiutati, e reclutare chi accetta di lavorare senza l'AI a 0/ora è sempre più difficile. Il segnale è che i tool migliorano. La certezza no.
SWE-bench Verified è il benchmark standard per misurare la capacità dei coding agent di AI su task reali da GitHub. I numeri di marzo 2026 sono genuinamente impressionanti: Claude Opus 4.5 risolve l'80.9% dei task, GPT-5.2 l'80.0%, Claude Sonnet 4.6 il 79.6%. Un anno fa Devin al lancio aveva raggiunto il 13.86% — già allora presentato come rivoluzionario.
Il limite non dichiarato: SWE-bench testa su repository Python — Django, Astropy, Matplotlib, SymPy. Non su codebase legacy multi-linguaggio, non su sistemi distribuiti, non su business logic accumulata in anni di iterazioni. È un benchmark eccellente per quello che misura. Non misura tutto.
La parte della narrativa che ha più base empirica riguarda i junior. Negli USA, i software developer 22-25 anni hanno perso il ~16% dell'occupazione dal 2022, controllando per altri fattori macroeconomici (Stanford Digital Economy Lab, ago. 2025). In Europa, -73% di hiring entry-level tech in Europa nel 2025 (Ravio). Il 66% delle enterprise globali pianifica di tagliare l'hiring entry-level (IDC/Deel survey 2025). Il BLS, che proietta una crescita complessiva del +15% per i software developer tra 2024 e 2034, riconosce esplicitamente che "l'incertezza sull'impatto potenziale dell'AI rimane molto alta".
Questa è la parte che manca quasi sempre nel dibattito pubblico. I CEO parlano di percentuali di codice scritto dall'AI. I benchmark misurano task isolati su repository Python ben strutturati. La realtà operativa su sistemi distribuiti complessi è diversa.
(Digressione tecnica — chi non gestisce infrastrutture complesse può saltare al paragrafo successivo.)
Prendi un homelab con 14 container Proxmox su 3 subnet separate — una configurazione non atipica per chi fa self-hosting serio. Hai servizi che comunicano attraverso VPN (NetBird o Tailscale), dipendenze di avvio non documentate perché ovvie a chi ha costruito il sistema, regole firewall che riflettono decisioni prese in momenti diversi per motivi che non sono scritti da nessuna parte.
Claude Code o Cursor su questo sistema: ottimi per generare un Ansible playbook per un task ripetitivo, per creare un Dockerfile per un nuovo servizio, per debuggare un errore specifico con stack trace esplicito. Fallimento garantito — o quasi — per refactoring che tocca più container con interdipendenze implicite, per capire perché la topologia di rete è quella che è, per security hardening su componenti legacy dove il perché non è documentato.
Il problema tecnico sottostante è il context window effettivo. Cursor dichiara 200.000 token di contesto, ma frammenta e ri-rankizza prima di inviare al modello — il contesto effettivo è inferiore. Su repository grandi, i modelli utilizzano effettivamente il 10-20% del contesto disponibile: il fenomeno lost in the middle è documentato e non risolto. Su un monorepo, i tool standard non vedono il codice nei file non aperti. Su sistemi distribuiti, il contesto architetturale — che sta nella testa dell'admin — è semplicemente assente.
Tornando al punto principale: la dicotomia non è AI-sostituisce-i-dev vs AI-non-cambia-nulla. È molto più specifica.
| Cosa fa bene (AI agent) | Dove fallisce (AI agent) |
|---|---|
| Boilerplate, CRUD, scaffold strutturati | Cross-file refactoring su codebase legacy |
| Unit test per funzioni isolate | Business logic implicita non documentata |
| Documentazione da codice esistente | Dipendenze implicite tra servizi distribuiti |
| Ansible playbook per task ripetitivi | Security hardening con 'why' non scritto |
| Debug con stack trace esplicito | Topologia di rete in testa all'admin |
| Nuovi servizi su stack standard (Dockerfile, compose) | Refactoring che tocca 5+ container con interdipendenze |
| Generazione test greenfield su framework popolari | Context architetturale su sistemi >100K righe |
La risposta onesta è: dipende da cosa fai e da quanto profondamente lo capisci.
I junior che usano l'AI per produrre codice che non capiscono sono in una posizione fragile — non perché l'AI li sostituisca, ma perché non stanno sviluppando le competenze per fare il lavoro successivo. Il 57% dei manager si fida più dell'output dell'AI che del lavoro di un neolaureato (Stack Overflow/Handshake 2025). Chi deploya codice dell'AI senza capirlo non sta diventando più produttivo: sta accumulando debito tecnico che qualcun altro dovrà ripagare.
Su task greenfield con stack standard, gli sviluppatori con Copilot producono il 55% più veloce rispetto a chi non lo usa (studio GitHub/Microsoft 2023 su task isolati in condizioni controllate). Ma gli stessi senior su codebase complesse con storia e dipendenze reali sono il 19% più lenti — il dato METR. L'AI amplifica i senior che sanno usarla per quello che funziona e la mettono da parte quando non funziona. Non li sostituisce.
Il mercato del lavoro riflette questa biforcazione. L'occupazione dei software developer 22-25 anni è calata del ~16% dal picco di fine 2022, controllando per fattori macro (Stanford Digital Economy Lab). Il 37% dei datori di lavoro preferisce assumere l'AI piuttosto che neolaureati. I tirocini tech sono scesi del 30% dal 2023 (Handshake). Ma la domanda complessiva di software developer, secondo BLS, cresce del +15% tra 2024 e 2034. Le posizioni che rimangono e si aprono richiedono capacità che l'AI non ha — ancora.
Se gestisci infrastruttura propria — anche solo una manciata di container su un mini PC, come quelli che stanno iniziando a popolare gli homelab nel 2026 (e di cui abbiamo scritto qui) — l'approccio più produttivo non è usare l'AI per tutto né ignorarla perché non capisce il proprio setup.
La strategia che funziona: usare l'AI per i task dove il contesto è autocontenuto e lo stack è standard. Playbook Ansible per configurazioni ripetibili, Dockerfile per nuovi servizi, unit test, documentazione. Non usarla per decisioni architetturali, per refactoring che tocca più servizi, per capire perché qualcosa è fatto in un certo modo — quello lo sai tu, non il modello.
Anche i modelli locali seguono la stessa logica. Il fatto che ora si possano fare girare modelli come Gemma 4 su hardware homelab non cambia il confine tra task dove il contesto è esplicito e task dove il contesto è nella tua testa. Quel confine rimane.
L'AI non sta sostituendo gli sviluppatori. Sta comprimendo l'ingresso, amplificando chi sa usarla bene su task adatti, e rallentando chi la usa su task sbagliati. I dev senior su codebase reali da 1M+ righe sono il 19% più lenti con AI. I junior che deployano codice AI che non capiscono stanno costruendo un problema, non una carriera. Il BLS proietta +15% di posti di lavoro per software developer al 2034. I dati non sono contraddittori: parlano di una trasformazione nella distribuzione del lavoro, non della sua eliminazione. La differenza non la fa l'AI — la fa capire dove funziona e dove no.
Fonti: METR study originale (luglio 2025) · METR follow-up (febbraio 2026) · SWE-bench Verified Leaderboard (marzo 2026) · Stack Overflow Developer Survey 2025 · GitHub Copilot stats 2026 · Stanford Digital Economy Lab · Veracode GenAI Code Security 2025 · AI vs Gen Z — Stack Overflow Blog · BLS Software Developers Outlook