73 % der PR wird von KI generiert. Der Schöpfer von Claude Code im Gespräch mit Spotify: 2900 Ingenieure führen täglich 4500 Deployments durch und können sogar in der U-Bahn Code einreichen

Im vergangenen September sprach Boris Cherny, der Gründer von Anthropic Claude Code, mit Niklas Gustavsson, dem Vice - Präsident für Engineering bei Spotify, über die Zukunft von KI - Programmiertools. Damals machte Niklas eine radikale Einschätzung: Bis Jahresende brauchen Entwickler möglicherweise keine traditionellen IDEs mehr.

Boriss erster Gedanke war, dass dies kaum möglich sei. Aus seiner Sicht würde es vielleicht zwei Jahre dauern, bis KI - Programmiertools traditionelle IDEs vollständig ersetzen könnten, aber es sei unmöglich, dass dies in nur zwei Monaten geschehen würde. Doch nur zwei Monate später stellte Boris fest, dass er tatsächlich keine traditionelle IDE mehr benutzte und sich seine gesamte Arbeitsweise vollständig verändert hatte.

„Diese Veränderung ist etwas, das ich in fast 30 Jahren in dieser Branche noch nie gesehen habe.“ sagte Boris in einem kürzlichen Gespräch zwischen den beiden.

Heute ist Spotify eines der repräsentativen Unternehmen weltweit, die KI - Programmierung in großem Maßstab in ihre Softwareentwicklungssysteme integriert haben. Innerhalb dieses Streamingriesen mit rund 2.900 Ingenieuren kann rund 73 % der PRs direkt von KI generiert werden, und die KI - Tools haben die Frequenz der PR - Einreichungen um über 75 % erhöht.

Spotify hat eine fast „augenscheinliche“ Umstrukturierung seiner Entwicklungsmethoden erlebt: Vom schrittweisen Rückzug der IDEs aus dem täglichen Entwicklungsumfeld bis zum gleichzeitigen Betrieb von Agenten im Hintergrund; Vom manuellen Schreiben und Ändern von Code durch Ingenieure bis zur Fertigstellung des größten Teils der Implementierung durch Modelle und der Einbringung in die Produktionsumgebung über automatisierte Validierung; Und schließlich von Wochen oder sogar Monaten für die Funktionsvalidierung auf nur wenige Stunden.

Die Praxis von Spotify ist jedoch nicht einfach die Anschaffung eines Claude Code - Abonnements für die Ingenieure. Hinter dieser Praxis steckt die jahrelange Entwicklung von Infrastrukturen für die Codeautomatisierung, die Standardisierung von Codebibliotheken, die automatisierte Tests, die kontinuierliche Integration, das Berechtigungssystem und die Validierungsschleife.

Die Erfahrungen von Spotify zeigen, dass die Fähigkeiten des Modells nur der Anfang sind. Was wirklich entscheidet, ob KI - Coding in großen Unternehmen umgesetzt werden kann, ist, ob das Unternehmen seinen Code, seine Tests, seine Tools und seinen Entwicklungsprozess in ein System umgewandelt hat, das von Agenten verstanden, aufgerufen und validiert werden kann.

Kurzfassung

F: Sie sehen immer früher als andere die Zukunft. Hängt das mit der Unternehmenskultur oder dem beteiligten Team zusammen?

A: Vor etwa fünf oder sechs Jahren stellten wir fest, dass das Wachstum unserer Unternehmenscodebasis um etwa das Siebenfache schneller war als das Wachstum der Anzahl unserer Ingenieure. Das bedeutet, dass im Laufe der Zeit immer mehr Code gewartet werden muss. Spotify ist ein Unternehmen, das an Produktideen nicht mangelt. Wir haben immer viele Funktionen, die wir unseren Benutzern liefern möchten. Wenn das Team lange Zeit von Wartungsarbeiten behindert wird, ist das offensichtlich kein idealer Zustand.

F: Viele Unternehmen machen den Fehler, nicht genug in die Validierungsschleife zu investieren.

A: Das ist wirklich sehr verbreitet. Als wir begannen, PRs für unseren Quellcode automatisch zu generieren und einzureichen, mussten wir die Anforderungen an die Teams ändern. Die Teams sind möglicherweise nicht an jeder Änderung beteiligt. Wir fusionieren die meisten Änderungen automatisch, und die betroffenen Teams sehen diese PRs möglicherweise gar nicht. Das bedeutet, dass wir ein besseres System für automatisierte Tests aufbauen müssen, um sicherzustellen, dass alle Software diesen automatischen Änderungen standhalten kann. Diese Investition hat uns sehr geholfen.

F: Wie betrachten Sie die ROI?

A: Die ersten Diskussionen über die ROI waren relativ einfach, weil die Verbesserungen, die wir sahen, so enorm waren. Aber mit der Reife der Technologie und der Verbesserung der Kostenstruktur steigt die Anforderung an die Genauigkeit der ROI - Berechnung. Ein Teil davon ist die Messung, wie viel die Produktivität gestiegen ist; Der andere Teil ist die Ermittlung, wie viel Kosten wir für diese Verbesserungen tatsächlich aufgewendet haben, einschließlich der Anzahl der verbrauchten Token, der investierten Stunden und der endgültigen effektiven Ergebnisse.

F: Welche Empfehlungen haben Sie für CTOs, VPs und Engineering - Manager anderer Unternehmen?

A: Neben automatisierten Tests und Validierungen ist die Standardisierung ebenfalls wichtig. Wir haben ständig daran gearbeitet, unsere Codebasis konsistenter zu gestalten und die Teams zu einer einheitlichen Nutzung von Tools und Frameworks zu bringen. Diese Investitionen waren ursprünglich darauf gerichtet, die Komplexität der Arbeit für menschliche Ingenieure zu verringern und deren Produktivität zu erhöhen. Aber wir haben festgestellt, dass diese Vorgehensweisen auch sehr gut auf Agenten übertragen werden können.

F: In der Vergangenheit wurde viel Zeit für die Implementierung aufgewendet, und jetzt ist diese Zeit frei geworden.

A: Wir investieren jetzt stark in die Prototypentwicklung. Und diese Investition ist nicht nur für Ingenieure, sondern auch für Nicht - Ingenieure gedacht. Derzeit hat auch einer unserer Co - CEO einen Prototyp in unserem internen App - Store eingereicht.

Nachfolgend finden Sie das ausführliche Gespräch zwischen den beiden. Wir haben es übersetzt und im Wesentlichen unverändert abgekürzt, um es den Lesern zugänglich zu machen.

Codeautomatisierung war schon vor Claude ein Ziel

Boris: Ich erinnere mich, dass ich mit Ihnen im vergangenen September gesprochen habe. Sie sagten damals so etwas wie: „Ich denke, bis Jahresende wird niemand die IDE mehr benutzen.“ Ich dachte damals: „Das ist total verrückt, das kann niemals passieren.“ Ich konnte mir vorstellen, dass eine solche Veränderung in etwa zwei Jahren eintreten könnte, aber zwei Monate waren einfach zu kurz. Aber zwei Monate später stellte ich fest, dass ich tatsächlich keine IDE mehr benutze, und meine gesamte Arbeitsweise hat sich vollständig verändert. Diese Veränderung ist etwas, das ich in fast 30 Jahren in dieser Branche noch nie gesehen habe.“

Niklas: Interessanterweise ist das Gefühl in unserem Unternehmen fast dasselbe wie außerhalb. Wir sind vielleicht nur ein paar Wochen voraus. Nur ein paar Wochen, aber das Gefühl ist wirklich dasselbe.

Boris: Jetzt bringen Agenten und große Modelle enorme Veränderungen mit sich. Aus meiner Sicht sind sowohl Ihre persönliche Arbeitsweise als auch die von Spotify an der Spitze der Branche. Wann haben Sie das erste Mal wirklich das Gefühl gehabt, dass „AGI da ist“?

Niklas: Ich denke, ich habe mehrere solche Momente erlebt, je nachdem, welches Problem wir gerade lösen wollten.

Sobald die großen Modelle auftraten, haben wir relativ früh versucht, sie zur automatischen Durchführung von Codeänderungen zu nutzen. Am Anfang war das sehr schwierig. Aber nach einer Zeit, als wir langsam herausgefunden hatten, wie man die großen Modelle nutzt, bewertet und andere Methoden anwendet, haben wir einige sehr aufregende Ergebnisse erzielt.

Boris: Das war schon vor mehreren Jahren?

Niklas: Ja. Damals gab es noch kein Claude, es war eher die sehr frühe Phase von GPT. Die Ergebnisse, die wir damals erzielten, konnten nicht alle Probleme lösen, aber sie zeigten uns, wohin diese Technologie in Zukunft gehen könnte. Das war definitiv ein wichtiger Moment.

Aber für mich persönlich war der echte Durchbruch möglicherweise Opus 4.5, das im November oder Dezember des vergangenen Jahres veröffentlicht wurde. Es hat sich von einem „klugen Autovervollständigungs - Tool“ zu etwas verwandelt, an das ich echte Probleme direkt geben kann, und ich muss nicht mehr so viel an Prompt - Engineering arbeiten.

Für mich war die größte Veränderung, dass ich endlich nicht mehr selbst Code bearbeiten musste. Vorher war mein Arbeitsablauf normalerweise, dass das Modell etwa 80 % des Codes schrieb oder, je nach Fähigkeiten des Modells, 70 %. Dann musste ich immer noch in die IDE gehen und die letzten Änderungen vornehmen. Dann war ich plötzlich nicht mehr darauf angewiesen. Das Gefühl war wirklich verrückt.

Boris: Ich denke, das ist auch der Grund, warum diese Veränderung wie ein großer Sprung wirkt. Wie sieht Ihr Arbeitsablauf jetzt aus?

Niklas: Meine Nutzung ist eher grundlegend. Ich öffne normalerweise mehrere Tmux - Sitzungen im Terminal. Wenn ich etwas zu tun habe, laufen im Hintergrund normalerweise mehrere Agenten gleichzeitig.

Boris: Wie viele Terminal - Tabs öffnen Sie normalerweise?

Niklas: Etwa 5 bis 10. Ich nutze auch einige Panels, weil ich gerne ein Terminal separat behalte, um Codeunterschiede und ähnliche Informationen zu sehen. Also konfiguriere ich jetzt normalerweise eine matrixartige Arbeitsumgebung: Auf der einen Seite sind mehrere Claude - Sitzungen, auf der anderen Seite die dazugehörigen Terminals, und ich nutze mehrere Git - Arbeitsbäume.

Wir haben jetzt einige sehr große monolithische Code - Repositories, und wir migrieren schrittweise zu dieser Architektur. Aber gleichzeitig behalten wir noch Tausende kleinerer multi - Code - Repositories bei.

Der größte Teil meiner Arbeit findet in diesen monolithischen Code - Repositories statt, also laufen normalerweise zu jeder Zeit mehrere Claude - Sitzungen und Terminals gleichzeitig. Wenn ich kurzzeitig in ein multi - Code - Repository gehen muss, öffne ich dort eine temporäre Claude - Sitzung.

Boris: Welche Art von Code - Repository, monolithisch oder multi, ist für Claude Code besser geeignet?

Niklas: Ehrlich gesagt war ich am Anfang ein wenig besorgt über die Kombination von monolithischen Code - Repositories und Agenten. Weil wir bei der Nutzung früherer Tools Probleme mit der Codeindizierung hatten. Und unsere Code - Repositories sind wirklich sehr groß, nur das Backend - monolithische Code - Repository hat über 20 Millionen Codezeilen.

Aber es hat sich gezeigt, dass Claude in diesen Code - Repositories sehr gut funktioniert. Wir haben festgestellt, dass Claude sehr gut darin ist, andere Code - Teile im Repository zu betrachten und daraus Hinweise und Inspirationen für die Lösung des aktuellen Problems zu ziehen.

Das Codewachstum ist siebenmal schneller als die Anzahl der Ingenieure, was zur Suche nach automatisierten Lösungen führt

Boris: Ich möchte auch über einige Infrastrukturen sprechen, die Sie aufgebaut haben. Spotify hat Honk (ein internes KI - Automatisierungs - System für die Programmierung) entwickelt. Von den ersten Versuchen mit Modellen bis zur Entwicklung von Honk und schließlich zur Entwicklung von Hintergrund - Agenten auf Basis des Agent SDK – Sie sehen immer früher als andere die Zukunft. Hängt das mit der Unternehmenskultur von Spotify oder dem Team zusammen, das an dieser Arbeit beteiligt ist?

Niklas: Vor etwa fünf oder sechs Jahren stellten wir fest, dass das Wachstum unserer Unternehmenscodebasis um etwa das Siebenfache schneller war als das Wachstum der Anzahl unserer Ingenieure.

Das bedeutet, dass im Laufe der Zeit immer mehr Code gewartet werden muss. Spotify ist ein Unternehmen, das an Produktideen nicht mangelt. Wir haben immer viele Funktionen, die wir unseren Benutzern liefern möchten. Wenn das Team lange Zeit von Wartungsarbeiten behindert wird, ist das offensichtlich kein idealer Zustand.

Deshalb haben wir angefangen, diese Wartungsarbeiten so weit wie möglich zu automatisieren. Viele dieser Arbeiten sind sehr langweilig, wie die Migration zur neuesten Java - Version, die Aktualisierung von Abhängigkeiten oder ähnliche Updates. Viele Arbeiten bestehen auch darin, eine API im gesamten Code - Repository auf eine andere API zu migrieren. Also haben wir eine Infrastruktur namens „Code - Flottendienst“ aufgebaut.

Vorher haben wir immer, wenn eine Migration erforderlich war, die Migrationsanweisungen oder - tutorials an alle Teams geschickt und dann jedes Team gebeten, die Migration für seine eigenen Komponenten manuell durchzuführen. Aber dann haben wir uns gefragt, ob es nicht möglich wäre, die Änderungen direkt auf das gesamte Code - Repository, das in Tausenden von Repositories verteilt ist, anzuwenden, anstatt dass jedes Team die gleichen Aktionen wiederholen muss.

Boris: Das heißt, hunderte Teams müssen manuell die gleiche Aktion an Tausenden von Komponenten ausführen.

Niklas: Ja. Jede Migration kann mehrere Monate dauern, und wir können pro Jahr möglicherweise nur etwa 10 solche Migrationen durchführen, oder wir können uns nur schwerersterstellen, dass wir immer noch die unterstützten Versionen der verschiedenen Frameworks nutzen. Also haben wir diese Arbeit automatisiert und dafür eine vollständige Infrastruktur aufgebaut. Später haben wir Millionen solcher PRs zusammengeführt.

Anfänglich waren alle diese Änderungen von deterministischen Skripten abhängig. Die Skripte wurden auf das Code - Repository angewendet, um die entsprechenden Code - oder Konfigurationsänderungen vorzunehmen. Aber wir haben frühzeitig festgestellt, dass die Schnittstellen, Aufrufmethoden und Abhängigkeiten im Code extrem komplex sind, und sobald man versucht, den Code zu ändern, steigt die Schwierigkeit schnell an. Also haben wir schnell eine Grenze erreicht: Wie komplexe Codeänderungen können wir nur mit deterministischen Methoden durchführen? Selbst wenn es nur darum geht, eine Methode oder API zu ersetzen, wird das Problem sehr komplex, wenn es 5 verschiedene Aufrufmethoden gibt.

Boris: Das heißt, Sie haben damals hauptsächlich auf traditionelle statische Analyse und abstrakte Syntaxbaum - Transformationen zurückgegriffen, um diese Arbeiten durchzuführen? Wenn das Ergebnis einer API beispielsweise zunächst einer Variablen zugewiesen wird, müssen Sie dann die Variable und ihren Zustand verfolgen.

Niklas: Genau richtig.

Boris: Das kann sehr mühsam sein.

Niklas: Ja. Jedes Skript, das wir für die Code - Migration geschrieben haben, ist schließlich auf Tausende von Zeilen angewachsen, um alle Grenzfälle im Code zu behandeln. Deshalb habe ich auch erwähnt, dass wir, sobald die frühen großen Modelle auftraten, überlegt haben, ob wir sie für dieses Problem nutzen könnten.

Am Anfang waren die Ergebnisse nicht gut. Einerseits waren die Modelle damals noch nicht stark genug, andererseits war auch unsere Herangehensweise an das Problem sehr naiv. Wir haben im Wesentlichen nur den Code direkt vor das Modell gestellt und dann das Modell gebeten, die Änderungen auf einmal vorzunehmen. Das hat natürlich nicht funktioniert.

Später haben sich die Modelle verbessert, und unser Verständnis für diese Probleme hat sich auch vertieft. Wir haben angefangen, große Modelle als Bewertungsinstrumente zu nutzen, um zu überprüfen, ob die Ergebnisse unseren Erwartungen entsprechen, und wir haben die Aufgaben auf verschiedene Weise aufgeteilt und zerlegt. Wir haben viele Iterationen durchgeführt und auch viele Experimente in unserem Unternehmen gemacht, um verschiedene Methoden zur Lösung dieses Problems zu testen. Später haben wir diese Methoden zusammengeführt und schließlich das heute bekannte Honk entwickelt.

Honk sah anfangs ganz anders aus als heute. Es war zunächst nicht auf Claude aufgebaut, sondern enthielt viele von uns entwickelte Komponenten. Aber es hat uns zum ersten Mal Hoffnung gemacht: Dieses Problem kann tatsächlich gelöst werden.

Seitdem haben wir Honk viele Male weiterentwickelt. Die Version, die wir jetzt veröffentlichen, ist V2, aber es ist wahrscheinlich eher V8, wir haben nur nicht jede Version nummeriert.

Honk wurde zunächst hauptsächlich zur automatischen Durchführung von Codeänderungen und zur Planung und Koordination dieser Änderungen in allen Code - Repositories eingesetzt. Aber die Ingenieure haben schnell festgestellt, dass es auch für andere Dinge genutzt werden kann. Beispielsweise möchte jemand Honk direkt in Slack erwähnen und es bitten, eine Aufgabe für ihn zu erledigen oder andere ähnliche Arbeiten zu übernehmen. Heute ist Honk ein sehr weit verbreitetes Tool innerhalb von Spotify.

Bei KI - Programmierung ist die Validierung wichtiger als die Generierung

Boris: Können Sie die Gesamtarchitektur von Honk beschreiben? Aus welchen Teilen besteht