IT EN
· 9 min di lettura

Chi possiede il banco da lavoro

OpenAI compra Astral, Anthropic ha comprato Bun. La colonizzazione silenziosa dello stack di sviluppo è già iniziata, e non è una questione di open source.

C'è una frase su Hacker News che mi è rimasta in testa da ieri sera, da quando ho letto la notizia dell'acquisizione di Astral da parte di OpenAI. La frase dice: "OpenAI and Anthropic are making plays to own the means of production in software." I mezzi di produzione. È una di quelle espressioni che suonano un po' eccessive la prima volta che le leggi, e poi ci pensi, e ci ripensi, e alla fine ti rendi conto che forse non sono eccessive abbastanza.

Astral è la startup dietro uv, Ruff e ty, tre strumenti che in pochi anni sono diventati parte dell'infrastruttura quotidiana di milioni di sviluppatori Python. uv ha risolto il problema della gestione degli ambienti e delle dipendenze con un'eleganza e una velocità che pip non ha mai avuto. Ruff ha reso il linting e il formatting talmente rapidi da renderli invisibili, e ty sta facendo lo stesso con il type checking. Sono strumenti scritti in Rust, tutti open source, tutti con licenza permissiva. E da ieri tutti di proprietà di OpenAI, che li integrerà nel team di Codex, il suo agente di coding che ha già superato i due milioni di utenti settimanali attivi.

Tre mesi fa, a dicembre, Anthropic aveva fatto una mossa simile comprando Bun, il runtime JavaScript creato da Jarred Sumner. Claude Code, il loro strumento di coding agentico che ha raggiunto un miliardo di dollari di revenue annualizzata in sei mesi, gira come eseguibile Bun. Sumner lo ha detto con una chiarezza quasi brutale nel suo post di annuncio: "If Bun breaks, Claude Code breaks." E quindi Anthropic ha comprato l'infrastruttura su cui il suo prodotto da un miliardo di dollari si regge.

Due acquisizioni in tre mesi, da parte delle due aziende che si contendono il mercato degli strumenti di coding assistito da ai. Se le guardi singolarmente, ciascuna ha la sua logica. Se le guardi insieme, il pattern è inequivocabile.

E il pattern è questo: le aziende che costruiscono modelli di linguaggio stanno comprando, pezzo dopo pezzo, la toolchain su cui quei modelli operano. Non il cloud, non i chip, non i data center. Gli strumenti che stanno tra il modello e il codice. Il package manager. Il linter. Il runtime. Il type checker. Tutto ciò che serve a un agente ai per non limitarsi a generare codice, ma per eseguirlo, testarlo, validarlo, e rimetterlo in produzione.

Questo non è filantropia verso l'open source. È strategia infrastrutturale.

Per capire cosa sta succedendo bisogna partire da un dato che spesso viene sottovalutato: i modelli di linguaggio, da soli, generano codice. Ma generare codice non è sviluppare software. Lo sa chiunque abbia provato a far scrivere un progetto intero a un agente e si sia ritrovato con qualcosa che compila ma non funziona, o che funziona ma non rispetta le convenzioni del repository, o che rispetta le convenzioni ma rompe tre test che nessuno aveva previsto. La generazione è il cinque per cento del lavoro. Il restante novantacinque per cento è contesto: risolvere le dipendenze, far passare il linter, gestire i tipi, eseguire i test, integrare nel flusso di CI/CD, mantenere il codice nel tempo quando le librerie si aggiornano e i requisiti cambiano.

E qui sta il punto. Un agente ai che vuole fare quel novantacinque per cento ha bisogno di possedere, o quantomeno di controllare, gli strumenti che lo compongono. Non basta sapere che uv esiste. Serve che uv risponda alle esigenze dell'agente, che sia ottimizzato per i suoi flussi di lavoro, che evolva nella direzione che rende l'agente più efficace. La stessa cosa vale per Ruff, per ty, per Bun. Quando OpenAI scrive nel suo annuncio che l'obiettivo è "move beyond AI that simply generates code and toward systems that can participate in the entire development workflow," non sta facendo marketing. Sta descrivendo esattamente perché ha comprato Astral.

Lo vedo tutti i giorni nel mio lavoro. Uso Claude Code su progetti Laravel, gestisco pipeline di CI/CD con GitHub Actions, e la differenza tra un agente che genera un file e un agente che capisce il contesto in cui quel file deve vivere è la differenza tra uno strumento utile e un giocattolo. Quando l'agente conosce le regole del mio linter, sa come sono strutturate le mie dipendenze, capisce il mio flusso di deployment, allora diventa davvero un collaboratore. E per essere quel tipo di collaboratore, deve parlare la lingua degli strumenti che uso. Se chi costruisce l'agente possiede anche quegli strumenti, il vantaggio competitivo è enorme.

Ma è proprio qui che la cosa diventa interessante, e un po' inquietante. Perché quello che sta emergendo è un nuovo tipo di vendor lock-in, diverso da tutto ciò che abbiamo visto prima.

Il vecchio lock-in era esplicito: sceglievi un cloud provider, sceglievi un database proprietario, e a un certo punto migrare costava troppo. Lo sapevi, facevi i tuoi conti, prendevi la decisione. Il nuovo lock-in è diverso. È implicito. Non ti accorgi che sta succedendo perché ogni singolo pezzo sembra open source, sembra libero, sembra neutrale. uv è ancora sotto licenza MIT. Bun è ancora sotto licenza MIT. Puoi forkare, puoi usarli senza Codex o Claude Code, puoi fare quello che vuoi. Ma la domanda è un'altra: tra due anni, quando l'ottanta per cento dell'evoluzione di uv sarà guidata dalle esigenze di Codex, quando le feature prioritarie saranno quelle che servono all'agente di OpenAI e non quelle che servono a te che usi uv da terminale, il fork sarà davvero un'opzione praticabile? Simon Willison, che ha una delle menti più lucide dell'ecosistema, ieri ha scritto che lo scenario peggiore ha la forma di "fork and move on." Ma poi ha aggiunto, onestamente, che OpenAI non ha ancora un track record nel mantenere progetti open source acquisiti. E che un'acquisizione che nasce come prodotto più talento può trasformarsi, nel tempo, in un'acquisizione di solo talento.

Questo è un punto su cui continuo a tornare. Il codice resta aperto, ma la direzione diventa chiusa. È una forma di controllo che non viola nessuna licenza, non tradisce nessuna promessa esplicita, e che tuttavia concentra potere in modo significativo. Qualcuno su Hacker News ha descritto bene la dinamica: "As they gobble up previously open software stacks, how viable is it that these stacks remain open?" La viabilità tecnica resta, la viabilità pratica si erode.

Lo scrivo e sento già le obiezioni, le stesse che mi sono fatto io. "Ma gli incentivi sono allineati," dicono in molti. "Anthropic ha bisogno che Bun funzioni bene per tutti, non solo per Claude Code, perché l'adozione diffusa crea effetti di rete." Ed è vero, almeno oggi. "La licenza MIT protegge la community," dicono altri. Ed è vero anche questo, almeno in teoria. Ma io ho visto abbastanza acquisizioni nella mia carriera per sapere che le promesse del giorno dell'annuncio hanno una data di scadenza non scritta. Il post di Jarred Sumner è stato onesto su questo punto: "No one can guarantee how motives, incentives, and decisions might change years down the line." E aggiungerei che gli incentivi di una startup con zero revenue e quattro anni di runway davanti sono molto diversi dagli incentivi di una divisione dentro un'azienda che brucia due dollari e mezzo per ogni dollaro di fatturato e deve giustificare ogni acquisizione davanti a investitori che aspettano un'IPO.

C'è anche un altro aspetto che mi colpisce, e che riguarda il modo in cui queste acquisizioni ridefiniscono la competizione. Fino a ieri, la battaglia tra OpenAI e Anthropic si giocava sulla qualità dei modelli. Chi ragiona meglio, chi genera codice più pulito, chi ha il contesto più lungo. Oggi la battaglia si sta spostando su un piano diverso: chi controlla più superficie del flusso di lavoro dello sviluppatore. Non è più solo "il mio modello è più bravo del tuo." È "il mio modello lavora dentro un ecosistema che possiedo e che ottimizza ogni passaggio." La generazione del codice diventa una commodity, e il valore si sposta sull'orchestrazione dell'intero ciclo. Chi possiede il linter, il package manager, il runtime e l'agente di coding ha un vantaggio strutturale che nessun benchmark può catturare.

La domanda che mi faccio, e che non ha ancora una risposta chiara, è cosa significhi tutto questo per chi lavora con stack diversi da Python e JavaScript. Il mondo di tanti team ad esempio non ha (ancora) subito questo tipo di concentrazione (pensate a chi lavora su altri Stack). Ma il pattern è chiaro, e si espanderà. Oggi è Python e JavaScript perché sono i linguaggi dell'ai e del web. Domani potrebbe essere qualsiasi ecosistema in cui gli agenti di coding hanno bisogno di tooling affidabile per operare in autonomia. La corsa ad acquisire i mattoni dell'infrastruttura di sviluppo è appena iniziata.

Mi viene in mente un'analogia che forse è un po' forzata, ma che mi aiuta a pensare. Per decenni, il petrolio è stato il combustibile dell'economia industriale, e chi controllava le raffinerie e le pipeline aveva più potere di chi estraeva il greggio. Nel software, i modelli di linguaggio sono il greggio. Generano output. Ma il valore reale sta nella raffineria: gli strumenti che prendono quell'output e lo trasformano in software funzionante, testato, conforme, deployato. Le AI company lo hanno capito, e stanno comprando le raffinerie.

E noi siamo al centro di questa transizione senza averla scelta. Usiamo uv perché è il miglior strumento disponibile. Usiamo Bun perché è veloce e risolve problemi reali. Le nostre scelte sono razionali e individuali. Ma l'effetto aggregato di milioni di scelte razionali e individuali è la concentrazione del potere infrastrutturale nelle mani di poche aziende che non hanno costruito quegli strumenti, li hanno comprati.

Non so dove porti tutto questo. Forse gli incentivi resteranno allineati abbastanza a lungo da non creare problemi. Forse la licenza MIT si rivelerà una protezione sufficiente. Forse il mercato rimarrà abbastanza competitivo da impedire abusi. Ma forse no. Forse stiamo costruendo una dipendenza che riconosceremo come tale solo quando sarà troppo tardi per uscirne con grazia.

La cosa che so è che la scelta del tuo package manager, del tuo runtime, del tuo linter non è mai stata una scelta solo tecnica. Oggi, che tu lo voglia o no, è anche una scelta politica. E come tutte le scelte politiche, merita di essere fatta con gli occhi aperti.