Oltre 650 pull request al mese fuse in produzione, fino al 90% di tempo risparmiato sulle migrazioni complesse, circa la metà di tutte le PR di Spotify oggi passa da agenti che lavorano in background. Sono i numeri di Honk, il sistema interno di coding agent che Spotify ha integrato nella propria infrastruttura Fleet Management nel luglio 2025, costruito sopra Claude Agent SDK e descritto nel customer story ufficiale di Anthropic.
La citazione che ha fatto il giro del mondo arriva dall’earnings call Q4 2025, il co-CEO Gustav Söderström dichiara che gli ingegneri più senior dell’azienda non scrivono una riga di codice da dicembre, e il titolo “AI sostituisce il lavoro degli sviluppatori” si scrive da solo. La storia vera, però, è diversa, e per chi guarda al settore pubblico e alle grandi aziende italiane con codebase legacy è anche più interessante della soundbite, perché dice che l’AI riesce a riscrivere il codice solo dove qualcun altro, prima, ha investito anni in catalogazione, ownership chiara, test suite e portali interni di sviluppatore, quindi non racconta una scorciatoia, racconta un prerequisito.
Indice degli argomenti
Con Honk, Spotify porta 650 pull request al mese in produzione
Il workflow descritto da Söderström è semplice nella narrazione e radicale nelle implicazioni. Un ingegnere apre Slack sul telefono mentre va al lavoro, scrive un prompt in linguaggio naturale del tipo “correggi questo bug” o “aggiungi questa feature all’app iOS”, l’agente naviga la codebase, applica le modifiche, esegue formattatori, linter, build e test, propone una pull request che l’ingegnere rivede dal telefono e fonde in produzione, tutto prima che arrivi in uffici. Il sistema gira in container sandboxati con permessi limitati, niente AI con accesso libero ai sistemi circostanti, e si integra con le pipeline CI/CD esistenti, quindi l’output passa dagli stessi cancelli che attraverserebbe una PR scritta a mano.
I numeri Anthropic-verified sono questi, oltre 650 PR al mese fuse in produzione, fino al 90% di tempo risparmiato per migrazione, e una serie di esempi concreti che danno la misura di cosa sia automatizzabile, conversione di classi Java AutoValue in Records, gestione di upgrade di framework con breaking change, aggiornamenti di configurazione che richiedono consapevolezza dell’intero codebase. La frase chiave nel post di Spotify Engineering è asciutta, Claude Code è oggi l’agente top-performer fra quelli testati, applicato a circa 50 migrazioni e responsabile della maggioranza delle PR background fuse in produzione.
Perché Honk di Spotify supera AST e regex
Per capire perché la storia conta serve fare un passo indietro tecnico. Spotify automatizza modifiche su larga scala da anni, Fleet Management esiste dal 2022, e fino al 2024 circa metà delle PR aziendali passava già da quel sistema, ma le trasformazioni erano scritte come script deterministici basati su manipolazione di alberi sintattici astratti o pattern regex, un approccio che richiede competenza specialistica e che funziona bene solo per modifiche meccaniche, bumping di dipendenze, aggiornamento di configurazioni, sostituzioni di chiamate API uno-a-uno. Tutto ciò che richiede comprensione del contesto, lettura semantica del codice, capacità di prendere decisioni caso per caso, restava lavoro manuale, costoso da pianificare e regolarmente rinviato.
L’esempio paradigmatico è la propagazione esplicita del contesto in tutti i servizi gRPC Java dell’azienda, una standardizzazione tecnica con breaking change che, fatta a mano, richiede ore di lavoro e conoscenza profonda di gRPC per ogni singolo servizio. Adesso Claude automatizza la maggioranza dell’implementazione e gli ingegneri si limitano alla review, e questo è il salto semantico vero, dalla regex che riconosce un pattern alla comprensione di cosa significa quel pattern in quel contesto specifico. Spotify aveva sperimentato prima con agent open source come Aider, poi aveva costruito un proprio loop sopra le API LLM, e alla fine è migrata su Claude Code perché la soluzione interna richiedeva istruzioni troppo rigide e faticava sulle modifiche multistep complesse.
Backstage e Fleet Management: la base di Honk in Spotify
Qui sta il punto editoriale che molti commentatori hanno mancato. Honk viene letto come un caso d’uso di Claude Code, mentre è in realtà il caso d’uso di un’organizzazione che ha investito un decennio in pre-condizioni infrastrutturali, e Söderström stesso lo riconosce in modo implicito quando elenca quello che era già in piedi, Backstage come portale interno di sviluppatore open source che cataloga ogni componente, traccia ownership, standardizza il modo in cui il software viene costruito, Fleet Management come framework per applicare modifiche su migliaia di repository, build system standardizzati, suite di test esaustive.
Niklas Gustavsson, Chief Architect e VP of Engineering di Spotify, è esplicito su questo aspetto, Claude è il modello scelto per le trasformazioni di codice su larga scala perché ha consistentemente offerto la migliore performance, però l’AI è necessaria, non sufficiente, il vero vantaggio competitivo è la maturità infrastrutturale.
Backstage da solo merita una nota a parte, è stato rilasciato come open source da Spotify nel 2020 e oggi è incubato dalla Cloud Native Computing Foundation, lo usano Netflix, American Airlines, Expedia e centinaia di altre aziende. Il fatto che Spotify abbia deciso anni fa di trattare il proprio portale interno come prodotto, e di condividerlo con il mercato, è il segnale che indica come quell’organizzazione pensa l’infrastruttura, come asset di lungo periodo e non come spesa operativa. Senza quella decisione di metodo, presa nel 2016 quando l’AI agentic non era nemmeno uno scenario plausibile, Honk oggi non esisterebbe.
Spotify nell’11% che usa agenti in produzione con Honk
I numeri di mercato confermano la lettura. Lo studio Deloitte 2025 sui trend tecnologici emergenti rileva che il 30% delle organizzazioni sta esplorando l’AI agentic e il 38% è in fase di pilot, ma solo l’11% la usa attivamente in produzione, e Gartner stima che oltre il 40% dei progetti agentic falliranno entro il 2027 perché i sistemi legacy non riescono a sostenere le richieste di esecuzione dell’AI moderna. Spotify sta in quell’11%, e il gap fra Spotify e gli altri non è il modello AI, è il decennio di investimenti che ha reso il modello AI utilizzabile.
Il dato dell’11% è quello che andrebbe letto con più attenzione nei consigli di amministrazione italiani. Indica una soglia di maturità organizzativa che la maggior parte delle imprese non ha attraversato, e che richiede un orizzonte di investimento più lungo del ciclo di pianificazione strategica tipico, tre anni almeno, spesso cinque. Chi guarda solo al ROI di un singolo POC sull’AI sta misurando la cosa sbagliata, perché il valore non sta nel POC ma nell’infrastruttura che lo abilita, e quella infrastruttura non si compra, si costruisce, e qui sta la difficoltà reale.
Honk di Spotify e la lezione per legacy, banche e PA
Il debito tecnico nei sistemi legacy italiani, banche, pubblica amministrazione, sanità, grandi industrie con stack accumulati per stratificazione, si è gonfiato negli anni perché ogni intervento manuale costava troppo rispetto al beneficio percepito, e il rinvio era sempre la scelta razionale nel breve. Honk dimostra che l’AI può rientrare in quei costi, abbassando di un ordine di grandezza il tempo necessario alla migrazione semantica, però lo dimostra anche per contrasto, la condizione abilitante è una mappatura accurata dei componenti, una ownership chiara, una pipeline CI/CD funzionante, una copertura di test sufficiente a fare da rete di sicurezza al lavoro dell’agente. Senza queste pre-condizioni l’AI non aiuta a ridurre il debito tecnico, lo amplifica, perché aggiunge codice generato in modo non deterministico a un sistema già fragile.
La traduzione operativa per chi guida una funzione IT di scala in Italia è netta. Prima di chiedere “quanto possiamo automatizzare con l’AI” conviene chiedere “quanto sappiamo, e quanto è documentato, di quello che abbiamo”, e investire sulla seconda domanda è la pre-condizione perché la prima abbia senso. Il debito cognitivo, la quantità di conoscenza implicita nelle teste delle persone e mai trasferita ai sistemi, è il vero fattore bloccante, e qui le aziende italiane hanno mediamente un ritardo culturale rispetto a chi, come Spotify, ha trattato la documentazione interna come prodotto da quasi un decennio.
In Spotify i prompt di Honk si versionano come codice
C’è un altro spostamento che merita attenzione, perché ridisegna il profilo di competenza richiesto. La frase più onesta del post tecnico di Spotify è che scrivere prompt è difficile, e che istruzioni apparentemente semplici producono risultati comicamente sbagliati se non si conosce a fondo come reagisce l’agente. I prompt per le migrazioni di Spotify sono versionati in Git come il codice, l’orchestrazione interna li applica ai repository target, e la disciplina che serve è quella di chi sa descrivere uno stato finale verificabile, definire pre-condizioni esplicite, fornire esempi concreti, indicare quando l’agente non deve agire. È context engineering, ed è una competenza che non coincide con la capacità di scrivere codice tradizionale, anche se la presuppone.
Il vantaggio competitivo dei prossimi anni, allora, si sposta dal saper scrivere codice al saper specificare condizioni di successo verificabili automaticamente. Le università e i percorsi di formazione tecnica in Italia non sono ancora calibrati su questa competenza, e questa è una lacuna strategica che pesa più del ritardo infrastrutturale, perché senza ingegneri capaci di context engineering non si riesce a sfruttare l’infrastruttura nemmeno quando c’è.
Da Honk di Spotify ai compilatori: il cambio di paradigma
I compilatori ottimizzanti degli anni 80 cambiarono il rapporto fra programmatore e macchina senza eliminare il programmatore, abbassarono la barriera di accesso, alzarono il tetto della complessità trattabile, e spostarono il valore aggiunto verso chi sapeva descrivere meglio cosa il sistema dovesse fare.
Honk e gli agenti di codice generativi stanno facendo lo stesso un livello sopra, abbassano il costo della trasformazione semantica, alzano il tetto di quello che una squadra può tenere sotto controllo, e spostano il valore aggiunto verso chi sa progettare l’infrastruttura abilitante e descrivere stati finali verificabili. La differenza, rispetto agli anni 80, è la velocità, e il fatto che il vantaggio si accumula su chi parte avanti, ed è qui che l’Italia rischia di perdere terreno se confonde il tema tecnologico con il tema organizzativo.
