A. Dina
Qualcuno, dentro GitHub, probabilmente ha guardato quei numeri con una certa soddisfazione. Crescita esponenziale, engagement fuori scala, una metrica che a prima vista sembra il sogno di qualsiasi piattaforma developer-first. Un miliardo di commit in tutto il 2025; poi, quasi con nonchalance, 275 milioni in una sola settimana. Proiettando la traiettoria si arriva a 14 miliardi in un anno, un volume che non è più “attività umana aumentata”, ma qualcosa di qualitativamente diverso, quasi biologico, come una proliferazione cellulare fuori controllo.
La narrativa ufficiale è rassicurante, come sempre. Più CPU, più servizi, più scaling. Il mantra classico della Silicon Valley, quello che ha funzionato per due decenni: quando il traffico aumenta, si aggiunge infrastruttura. È la stessa logica che ha sostenuto Amazon Web Services e che ha reso scalabile il web moderno. Solo che questa volta c’è un problema sottile, e profondamente strutturale: non stiamo scalando utenti, stiamo scalando agenti.
Gli agenti non sono utenti veloci. Sono una specie diversa.
Un ingegnere umano, anche il più produttivo, ha un ritmo cognitivo limitato. Scrive codice, riflette, testa, committa. Un agente, alimentato da modelli come quelli sviluppati da OpenAI o Anthropic, non ha pause, non ha esitazioni, non ha nemmeno il concetto di “costo marginale della riga di codice”. Genera, testa, rigenera, cicla. Il risultato non è un aumento lineare della produttività, ma un’esplosione combinatoria di attività.
Il dato più interessante, e anche il più ignorato, non è il numero di commit. È la quantità di codice che non verrà mai eseguito. Decine di miliardi di linee generate, compilate, testate, e poi abbandonate. In un’economia tradizionale sarebbe considerato spreco. Nel mondo software, lo chiamiamo “pipeline”.
La verità, scomoda ma evidente, è che abbiamo costruito un’intera infrastruttura di sviluppo su un presupposto implicito: la scarsità del codice. Scrivere codice era costoso, lento, cognitivamente impegnativo. Tutto, dalle pull request ai sistemi di code review, fino alle pipeline di CI/CD, è stato progettato per ottimizzare quel collo di bottiglia.
Ora quel collo di bottiglia non esiste più.
Il risultato è che strumenti come GitHub Actions stanno diventando vittime del loro stesso successo. Da 500 milioni di minuti a settimana nel 2023 a oltre 2,1 miliardi oggi. Non è crescita, è saturazione sistemica. Le API raggiungono costantemente i limiti, non perché gli sviluppatori siano diventati più attivi, ma perché gli agenti operano a una frequenza per cui quei limiti non erano mai stati progettati.
Qui emerge un pattern classico nella storia della tecnologia: quando cambia la natura dell’input, l’infrastruttura collassa, anche se la capacità è teoricamente sufficiente. È successo con il web quando i bot hanno iniziato a superare gli umani nel traffico. È successo nei mercati finanziari con l’arrivo del trading algoritmico. Sta succedendo ora nello sviluppo software.
La risposta di scalare hardware è, francamente, una reazione riflessa. Comprensibile, ma miope. Aumentare la capacità senza cambiare il modello equivale a costruire autostrade più larghe per un traffico che cresce esponenzialmente. Funziona fino a quando non smette di funzionare, e poi collassa tutto insieme.
Il punto interessante, quasi ironico, è che una parte dell’industria ha già capito il problema. Non è un caso che Nat Friedman abbia lasciato GitHub per costruire Entire. Non si tratta di un cambio di carriera, ma di una diagnosi implicita: non puoi innestare agenti su infrastrutture pensate per umani e aspettarti che il sistema regga.
Questa è la vera frattura epistemologica.
Gli agenti non sono “developer più veloci”. Sono generatori di stati di sistema. Interagiscono con repository, pipeline, API e ambienti di test come un sistema distribuito autonomo. Ogni loro azione ha effetti a cascata. Ogni ciclo di generazione può attivare decine o centinaia di processi downstream. Senza vincoli, il sistema diventa rumoroso, inefficiente, e paradossalmente meno produttivo.
Il concetto chiave, che molti team stanno ancora sottovalutando, è quello di harness. Non il modello, non la capacità computazionale, ma il sistema che incapsula e governa l’agente. Una sorta di architettura cognitiva esterna che definisce cosa l’agente può fare, quando può farlo e soprattutto cosa non deve fare.
Le organizzazioni che stanno realmente scalando con l’AI non sono quelle con i modelli migliori, ma quelle con i vincoli migliori.
Il contesto diventa la nuova unità di controllo. Un agente con accesso indiscriminato a un repository monolitico produce inevitabilmente codice morto. Un agente confinato in un contesto ben definito, con limiti chiari e obiettivi precisi, tende a generare output più utili. È una banalità teorica, ma nella pratica richiede una riprogettazione radicale delle architetture software.
Le pipeline CI/CD, ad esempio, non possono più essere eventi passivi scatenati da ogni commit. Devono diventare sistemi intelligenti, capaci di filtrare, aggregare, ritardare. L’idea che ogni modifica debba essere testata immediatamente è figlia di un’epoca in cui le modifiche erano rare e preziose. Oggi sono abbondanti e spesso irrilevanti.
Lo stesso vale per le code review. Il modello tradizionale, basato su revisione umana di ogni pull request, non scala in un mondo in cui un agente può generare centinaia di PR in un’ora. Serve un livello intermedio, una sorta di pre-validazione automatica che riduca il rumore prima che arrivi agli umani. In altre parole, serve AI per filtrare l’output dell’AI. Una catena di montaggio cognitiva, che ricorda più una fabbrica che un team di sviluppo.
L’ironia, nemmeno troppo sottile, è che stiamo reinventando il concetto di controllo industriale nel software. Henry Ford, se fosse vivo, probabilmente capirebbe meglio questa transizione di molti CTO contemporanei.
Un altro elemento spesso trascurato è il costo economico nascosto. Ogni minuto di CI/CD, ogni chiamata API, ogni ciclo di test ha un costo reale. Quando gli agenti operano senza vincoli, quel costo cresce esponenzialmente, spesso senza generare valore proporzionale. È una forma di debito tecnico, ma anche finanziario. Un debito che non compare nei bilanci fino a quando non diventa ingestibile.
La narrativa dominante sull’AI tende a concentrarsi sulla produttività individuale. Quanto codice può scrivere uno sviluppatore con l’aiuto di un copilota. È una metrica seducente, ma fuorviante. Il vero problema è la produttività sistemica. Quanto valore genera l’intero sistema rispetto alle risorse consumate.
In molti casi, la risposta è sorprendentemente bassa.
Una frase, secca, quasi brutale: più codice non significa più software. Significa spesso più rumore.
Le aziende che stanno vincendo in questa fase non sono quelle che generano più codice, ma quelle che riescono a limitarlo. Che progettano sistemi in cui la generazione è guidata, filtrata, ottimizzata. Che trattano gli agenti non come sviluppatori junior iperattivi, ma come sistemi complessi da orchestrare.
Questo implica un cambio di mentalità non banale. Richiede di accettare che la scarsità non è più il problema. L’abbondanza lo è. E gestire l’abbondanza è sempre più difficile che gestire la scarsità.
Si potrebbe quasi dire che il software engineering stia diventando una disciplina di controllo del rumore.
Le implicazioni strategiche sono profonde. Le aziende che continueranno a investire solo in capacità computazionale si troveranno presto intrappolate in sistemi costosi e inefficaci. Quelle che investiranno in architetture, vincoli e feedback loop avranno un vantaggio competitivo significativo.
Un ultimo paradosso, che merita di essere sottolineato. L’AI è stata venduta come strumento per ridurre il lavoro umano. In realtà, sta creando una nuova forma di lavoro: progettare sistemi che controllano l’AI. Non è meno complesso, è solo diverso. E richiede competenze che molti team non hanno ancora sviluppato.
La domanda che rimane, inevitabilmente, non è tecnologica ma organizzativa. Chi, dentro le aziende, ha la responsabilità di progettare questi sistemi? Il CTO, il team DevOps, una nuova figura ancora da definire?
La risposta, per ora, è confusa. E quando la governance è confusa, i sistemi tendono a degenerare.
Il rischio non è che GitHub collassi. Il rischio è che continui a funzionare, mentre sotto la superficie accumula inefficienza, costi e complessità. Una sorta di debito invisibile, amplificato dagli agenti, che prima o poi qualcuno dovrà pagare.
Nel frattempo, i numeri continueranno a crescere. E qualcuno continuerà a celebrarli. Perché nella tecnologia, come nella finanza, è sempre più facile misurare il volume che il valore.
📊 scala e crescita di GitHub
- GitHub ha superato i 150+ milioni di sviluppatori e centinaia di milioni di repository
- Circa 1 miliardo di commit in un anno è un ordine di grandezza confermato da dataset recenti
- La crescita dei repository è continua, con centinaia di nuovi repo al minuto
👉 Traduzione: il sistema era già enorme prima dell’arrivo degli agenti.
⚙️ esplosione di GitHub Actions e CI/CD
- Nel 2025 sono stati consumati 11,5 miliardi di minuti di GitHub Actions
- La piattaforma esegue decine di milioni di job al giorno
- GitHub stesso ammette che l’architettura ha dovuto essere modernizzata per reggere la crescita
👉 Questo dato è cruciale: la pressione sulla CI/CD è già strutturale, prima ancora della piena adozione degli agenti.
🤖 impatto degli agenti di coding (dato accademico)
- Gli agenti (tipo Cursor, Claude Code, ecc.) sono già adottati nel 15%–22% dei progetti GitHub
- I commit generati dagli agenti sono più grandi e più densi rispetto a quelli umani
👉 Traduzione strategica: non è solo più volume, è volume qualitativamente diverso.
⚠️ effetti collaterali reali: sicurezza e rumore
Over 29 million secrets were leaked on GitHub in 2025, and AI really isn’t helping
- Nel 2025 sono stati rilevati 29 milioni di secret leak su GitHub
- Il codice assistito da AI ha un tasso di leak circa doppio rispetto alla media
- I commit pubblici sono cresciuti rapidamente con l’adozione dell’AI
👉 Questo è il punto che molti ignorano: più codice ≠ più qualità, spesso significa più vulnerabilità.
