L'IA sta uccidendo l'open source?

13 agosto 2026 · 8 min di lettura

A gennaio 2026 Adam Wathan ha rivelato in un commento su GitHub che Tailwind Labs aveva tagliato il 75% del team di ingegneria, tre ingegneri su quattro, dopo un calo dei ricavi dell'80%. La colpa, secondo lui, è dell'impatto "brutale" che l'IA ha avuto sul business. Intanto l'utilizzo era ai massimi storici: circa 75 milioni di download mensili su npm e una presenza nel 51% dei progetti web secondo la survey State of CSS del 2025.

L'IA non ha toccato il codice dell'open source: ha rotto i due assunti su cui si reggeva l'intero modello. I maintainer riuscivano a finanziare il lavoro perché gli sviluppatori passavano dai loro siti. Le aziende installavano i pacchetti senza farsi troppe domande perché il codice pubblicato si dava per sicuro. Il caso Tailwind mostra che il primo assunto ha ceduto; gli attacchi alla supply chain di npm mostrano che è caduto anche il secondo. Cosa li sostituirà, non lo so.

L'assunto sui finanziamenti è appena saltato

Per capire cosa è successo bastano i numeri di Tailwind. Il traffico verso la documentazione è calato di circa il 40% in due anni, mentre i download toccavano il massimo di sempre. Gli sviluppatori usano Tailwind quanto prima; hanno solo smesso di passare dal sito.

Un assistente IA ti dà le utility class direttamente nell'editor, senza passare dalla documentazione. Ed era proprio su quel passaggio che si reggeva il business: il framework è gratuito, Tailwind Labs guadagna vendendo template di componenti e UI kit, e la documentazione era il posto dove gli sviluppatori scoprivano che esistono. Se nessuno passa più di lì, quei ricavi si prosciugano anche se i download continuano a salire.

Da allora sono arrivate le sponsorizzazioni di Google AI Studio e Vercel, ed è quel denaro a tenere al lavoro il team rimasto. Ma una sponsorizzazione dura finché lo sponsor ritiene che valga la pena pagarla, e quella decisione torna sul tavolo ogni anno.

Lo sviluppo assistito dall'IA ha eliminato il momento in cui uno sviluppatore apre il tuo sito. Un modo nuovo per finanziare questo lavoro non l'ha ancora costruito nessuno, né per Tailwind né per gli altri.

Ed è saltato anche l'assunto sulla fiducia

L'altro assunto è la fiducia nella supply chain, che ha passato due anni ancora più duri del fronte dei finanziamenti. A settembre 2025 un worm autoreplicante chiamato Shai-Hulud ha iniziato a raccogliere segreti CI/CD dai pacchetti npm compromessi. Il primo giorno se ne contavano circa 40, tra cui diversi pubblicati da CrowdStrike; una settimana dopo, quando CISA ha emesso un alert, erano già oltre 500. Due mesi più tardi Shai-Hulud V2 ha compromesso più di 700 pacchetti npm e messo in piedi oltre 27.000 repository GitHub malevoli.

Nell'arco di 48 ore, tra l'11 e il 12 maggio 2026, una variante soprannominata Mini Shai-Hulud ha compromesso 172 pacchetti tra npm e PyPI, 403 versioni malevole in totale. Tra gli scope colpiti c'erano @tanstack, @mistralai e @opensearch-project: è la prima volta che una singola campagna attraversa entrambi i registry. Sono worm che rubano credenziali, e sfruttano il fatto che per un package manager "già pubblicato" equivale a "sicuro da installare".

Nel frattempo l'IA è diventata molto brava a trovare vulnerabilità che nessuno ha piazzato apposta. Ad agosto 2025 Big Sleep di Google aveva già trovato in autonomia circa 20 vulnerabilità in software open source molto diffuso, soprattutto FFmpeg e ImageMagick. A giugno 2025 un agente autonomo costruito da XBOW è arrivato in cima alle classifiche di HackerOne, davanti a migliaia di ricercatori umani, con oltre 1.000 segnalazioni di vulnerabilità. A gennaio 2026 OpenSSL ha corretto 12 vulnerabilità zero-day in un'unica release di patch, tutte e 12 trovate da un solo sistema IA chiamato AISLE. E curl, di questo passo, chiuderà il 2026 con una cinquantina di CVE pubblicate.

Trovare vulnerabilità su questa scala non è più un'ipotesi. È già successo, più volte, in librerie da cui dipende metà di internet.

Oggi l'IA trova vulnerabilità molto più in fretta di quanto l'IA stessa, o gli esseri umani, riescano a correggerle bene. I numeri di OpenSSL e curl dicono proprio questo: la scoperta corre molto più avanti delle pipeline che dovrebbero sistemare quello che trova.

Quel divario l'ho visto trasformarsi in costi con i miei occhi, su team soggetti a FedRAMP o SOC 2. Quella che era manutenzione di routine, una PR di Dependabot qui, un bump di versione là, oggi è una voce di costo fissa. Ogni sprint c'è qualcuno il cui lavoro è capire quali dei pacchetti segnalati in settimana sono un problema vero. Una buona parte del tempo del mio team se ne va proprio lì, tra il momento in cui una vulnerabilità viene trovata e quello in cui viene corretta davvero.

Ora il problema sono le correzioni

Questa parte la conosco in prima persona, ed è il motivo per cui non credo che il problema sia solo trovare più vulnerabilità. Nel team che guido abbiamo visto passare un mare di pull request generate dall'IA che avrebbero dovuto chiudere una CVE segnalata e non lo facevano.

Lo schema è sempre lo stesso. La PR aggiorna il numero di versione in package.json, ma sotto il code path vulnerabile resta raggiungibile. Oppure risolve il problema segnalato e rompe il prodotto, perché il modello ha ragionato sulla CVE senza guardare come quella dipendenza veniva usata davvero nel nostro codice.

È lo stesso punto cieco di cui ho già scritto a proposito delle riscritture complete: un agente produce qualcosa di pulito e plausibile, ma non si porta dietro il ragionamento che rendeva corretto l'originale. La revisione ne ferma la maggior parte prima che arrivino in produzione. Fermarle però costa, e ognuna che passa crea un secondo incidente che si somma al primo.

Si è arrivati al punto che i code owner hanno sollevato la questione in riunione, chiedendo di smettere del tutto di aprire PR di questo tipo. Rivederle con più attenzione non era la risposta: l'assistente che scriveva le correzioni non capiva il codice abbastanza a fondo da farle bene. È un passo oltre gli ingegneri che si appoggiano all'IA prima di essersi guadagnati il giudizio per controllarla. Qui sono ingegneri senior a fare la stessa scelta, su un compito più ristretto e con una posta in gioco più alta.

La mia libreria non si è accorta di niente

Nella libreria che mantengo, di tutto questo non si vede traccia. Nessun volume anomalo di PR, nessuna nuova superficie d'attacco, nessun problema di finanziamento, perché un finanziamento da perdere non c'è mai stato. Per ora a pagare sono le grandi infrastrutture come Tailwind e gli ecosistemi molto usati come npm: progetti abbastanza grandi perché valga la pena attaccarli, o con ricavi abbastanza alti perché valga la pena eroderli. Una piccola libreria che una persona sola mantiene per il gusto di mantenerla non è un bersaglio, almeno per ora.

Una cosa però è cambiata, proprio stamattina. Ho chiesto a uno dei modelli IA più recenti di passare in rassegna la codebase. È la stessa domanda che avevo fatto più volte ai modelli precedenti, e la risposta era sempre una variante di "va tutto bene". Questo ha trovato quasi 20 miglioramenti reali. Stesso codice, stessa domanda, modello molto più capace. I numeri sulle vulnerabilità citati più sopra vengono dallo stesso salto di capacità, applicato a codebase molto più grandi.

Cosa viene dopo: una speranza e tre ipotesi

C'è un'obiezione ovvia: l'open source è stato dato per morto più volte, ed è sempre sopravvissuto. È un'obiezione fondata.

I finanziamenti sono sempre stati precari: chiedete a un maintainer qualsiasi che abbia supplicato gli utenti di sponsorizzare una dipendenza usata ogni giorno. E i registry di pacchetti ospitavano malware ben prima che esistessero i language model. La differenza è che stavolta sono saltati entrambi gli assunti insieme, e su scala di interi ecosistemi, non di singoli progetti. Non saprei indicare un altro momento in cui sia successo.

Cosa verrà dopo, non lo so. Ma qualunque cosa arrivi, spero che conservi la cosa migliore che l'open source ha dato a questo settore: la possibilità, per qualcuno senza capitale e senza un'azienda alle spalle, di costruire qualcosa di importante, in pubblico, gratis. Vale la pena proteggerla, comunque si risolva il problema dei finanziamenti.

Oltre a questo ho tre ipotesi, e non sono sicuro di nessuna delle tre:

1. Il divario si chiude dal lato delle correzioni. Trovare vulnerabilità su larga scala è un problema già risolto: lo hanno dimostrato Big Sleep, XBOW e AISLE. Se anche correggerle bene arriva a quel ritmo, infilare di nascosto una vulnerabilità nuova diventa davvero difficile, e la corsa si sposta a favore della difesa invece di restare in equilibrio.
2. Nasce un nuovo linguaggio o un nuovo ecosistema, progettato da zero per codice generato e revisionato dall'IA, con la fiducia nella supply chain come funzionalità nativa.
3. Il settore torna verso qualcosa di simile alla norma precedente all'open source: le aziende proteggono il codice che vale davvero dei soldi, e in pubblico resta il progetto hobbistico di chi non si è mai aspettato un ritorno economico.

Quale delle tre prevarrà dipende da decisioni che nessuno ha ancora preso: come i registry verificheranno chi pubblica, se i fornitori di IA tratteranno la correzione delle vulnerabilità come un prodotto che vale la pena costruire. E dipende da come finirà Tailwind: eccezione isolata o primo di molti casi. Io quella risposta non ce l'ho ancora. E, per quanto ne so, non ce l'ha nessun altro.