Anthropic zette deze week een gesprek online met Niklas Gustavsson, VP Engineering bij Spotify. Gustavsson is molecularbioloog van opleiding, kwam via genoomdata in de software terecht en zit inmiddels dertig jaar in het vak. Wat hem interessant maakt, is dat Spotify al jaren voor de rest van de markt bezig is met het automatiseren van eigen codebase-onderhoud, en dat die aanpak nu vrijwel volledig op Claude draait. Ik keek het gesprek terug omdat het een van de weinige keren is dat een engineering-leider met concrete cijfers laat zien wat er gebeurt als je agenten loslaat op een codebase van die omvang.
Van deterministische scripts naar agenten
Vijf, zes jaar geleden zag Spotify de eigen codebase zeven keer sneller groeien dan het aantal engineers dat die kon onderhouden. Het antwoord was destijds “fleet management”: in plaats van elk team handmatig dezelfde migratie te laten uitvoeren (een Java-upgrade, een API-vervanging), bouwde Spotify infrastructuur om die wijzigingen als geautomatiseerde mutatie over duizenden repositories tegelijk te zetten. Dat werkte, maar liep tegen een plafond. Code heeft een enorm API-oppervlak, zegt Gustavsson: zodra een methode op vijf verschillende manieren aangeroepen wordt, ontspoort een deterministisch script in duizenden regels edge-case-logica.
Dat plafond is waarom Spotify vroeg met LLM’s ging experimenteren, eerst met matig succes. Wat het team bouwde, groeide uit tot Honk, hun interne tool voor geautomatiseerde codewijzigingen. De eerste versies draaiden nog op eigen gebouwde componenten en een aparte LLM-rechter die output controleerde. Die rechter stuwde het slagingspercentage van PR’s van 20 à 30 procent naar 80 procent, maar is inmiddels weer verwijderd: de modellen en de agent-harnas zijn goed genoeg geworden dat de extra controlelaag geen toegevoegde waarde meer had.
Architectuur: de agent SDK plus een verificatielus
Honk draait nu op de Claude Agent SDK, in een Kubernetes-pod, met toegang tot Spotify’s interne tools. Sinds versie 2 kunnen teams zelf tools toevoegen in plaats van te werken met een vaste allowlist. Het belangrijkste onderdeel is niet de codegeneratie, maar de verificatie: de agent kan zelf CI-builds draaien, op Linux én macOS (nodig voor iOS-werk), en in sommige gevallen zelfs simulators aansturen om een implementatie te testen tegen een Figma-ontwerp.
Gustavsson is daar expliciet over: verificatie is het enige dat echt telt zodra een agent zelfstandig een taak uitvoert zonder mens in de lus. Dat dwong Spotify wel tot een cultuuromslag. Voorheen kon testautomatisering iets slordiger zijn, omdat het eigenaarsteam elke PR nog met eigen ogen zag. Zodra PR’s automatisch samengevoegd worden zonder dat een team ze ooit inziet, moet die testdekking waterdicht zijn. De investering ging dus niet naar snellere agenten, maar naar betere testinfrastructuur, wat volgens hem precies is waarom snelheid en kwaliteit geen tegenstelling hoeven te zijn: kwaliteit die in scripts, een CLAUDE.md of een set MCP’s vastligt, is sneller uit te voeren dan kwaliteit die in iemands hoofd zit.
De cijfers
Spotify draait zo’n 4.500 productiedeployments per dag, verdeeld over ongeveer 2.900 engineers. De metrics die Gustavsson noemt: een verbetering van 75 procent of meer in PR-frequentie die direct aan AI-tooling toe te schrijven is, en 73 procent van alle PR’s die inmiddels AI-authored zijn. Wat hem betreft is dat nog niet het eindpunt. Spotify probeert nu die deliverables (PR’s, deployments, geplande werkitems) door te koppelen naar A/B-tests en uiteindelijk naar gebruikerswaarde en omzet, om precies te weten wat een verbetering aan tokens en uren heeft gekost tegenover wat het opleverde.
Een tweede, minder technisch punt: Spotify heeft de afgelopen maanden intern een prototyping-infrastructuur gebouwd waarmee iedereen, ook niet-engineers, een idee in natuurlijke taal kan omzetten in een werkend prototype binnen de eigen mobiele apps, inclusief een interne appstore om die prototypes te delen. Een van de co-CEO’s heeft er zelf een paar in staan.
Wat mij opviel
Twee dingen wil ik hier kritisch naast zetten, want het verhaal is makkelijk te lezen als pure vooruitgang.
Het eerste is de mate van modelafhankelijkheid. Honk draait nu vrijwel volledig op de Claude Agent SDK, en Gustavsson noemt zelf dat consistentie in codebase en tooling agenten beter laat presteren. Dat is een reëel technisch argument, maar het betekent ook dat een bedrijf van deze omvang zijn kernproces, het onderhoud van een monorepo van 20 miljoen regels, steeds dieper aan één leverancier koppelt. Niets in het gesprek wijst erop dat Spotify daar een uitwijkstrategie voor heeft.
Het tweede is de metric “73 procent AI-authored”. Dat cijfer zegt iets over wie de eerste versie van de code typt, niet over wie er verantwoordelijk voor is als het misgaat. Gustavsson is eerlijk over de investering die nodig was om PR’s zonder mens in de lus samen te voegen, en dat is precies het punt: hoe hoger dat percentage, hoe zwaarder de verificatielaag moet leunen op tests die zelf ook weer door mensen ontworpen zijn. Dat is een verstandige volgorde, maar het is een aanname die je moet blijven checken, niet een resultaat dat vanzelf standhoudt naarmate het percentage stijgt.
Wat blijft hangen is de simpelheid van het advies aan het eind: investeer in standaardisatie en testautomatisering voordat je aan agenten begint, niet erna. Dat is precies het soort saaie, ongeglamoureuze werk dat meestal wordt overgeslagen omdat het geen directe demo oplevert. Bij Spotify is het de reden waarom het wél werkt.
Het volledige gesprek staat op YouTube: How Spotify runs agents across 20M+ lines of code, with Niklas Gustavsson.
Dit stuk verscheen ook in het Engels: How Spotify lets Claude loose on 20 million lines of code.