Teile ein Gespräch mit dem Leiter von Claude Code

Heute habe ich ein Podcast gehört, bei dem die Gäste Fiona Fung, die Leiterin des Anthropic Claude Code- und Cowork-Teams, war.

Die meisten Leute streiten noch darüber, ob KI überhaupt in der Lage ist, Code zu schreiben, und ob sie Softwareingenieure ersetzen wird. Diese Dame überspringt diese Fragen direkt und spricht stattdessen über das, was danach kommt.

Fiona hat 25 Jahre lang als Softwareingenieurin gearbeitet und hat mehrere Epochen erlebt, in denen sich alles veränderte. Da sie in den vorherigen Epochen überlebt hat, hat sie eine völlig andere Einschätzung dieser Welle der KI als junge Leute, die erst seit zwei Jahren in der Branche tätig sind.

Da der Inhalt lang und sprunghaft war, habe ich ihn nach dem Verständnis neu strukturiert. Zu Beginn des Podcasts stellte sie die These auf: Das Schreiben von Code ist kein Engpass mehr.

Eine Statistik:

Die durchschnittliche Menge an Code, die die Anthropic-Softwareingenieure pro Quartal liefern, ist im Zeitraum von 2021 bis 2025 achtmal so hoch wie zuvor. Die Kurve verläuft zunächst stabil und steigt dann steil an.

Die Explosion der Code-Menge ist nur die Oberfläche. Was sie wirklich interessant findet, ist etwas anderes: Die Personen, die Code einreichen, haben sich verändert.

Im Claude Code-Team reichen Designer und Produktmanager Code ein. Fast alle checken Code ein.

Früher war das Schreiben von Code eine exklusive Aufgabe von Softwareingenieuren. Jetzt ist es eine grundlegende Fähigkeit, die über verschiedene Rollen hinweg verbreitet ist, genauso alltäglich wie das Senden von E-Mails.

Fionas eigene Worte:

Die Frage lautet nun: Wo liegt der neue Engpass? Nicht nur, dass mehr Menschen Code einreichen, sondern auch, dass diese aus verschiedenen Fachbereichen stammen. Die Durchsatzrate ist sehr hoch. Wie können wir die Qualität überprüfen? Wie können wir sicherstellen, dass die schnell generierten Ergebnisse korrekt und qualitativ hochwertig sind?

Dies ist eine sehr subtile Veränderung.

In der Vergangenheit war der Kernbeschränkung für Softwareentwicklungsteams die "Engineering-Bandbreite". Das Schreiben von Code war teuer und die Zeit war knapp. Deshalb haben die Teams umfangreiche Pläne entwickelt, um sicherzustellen, dass die begrenzten Ressourcen an den wichtigsten Stellen eingesetzt werden.

Jetzt ist diese Beschränkung verschwunden. Code kann billig und schnell generiert werden.

Der Engpass ist jedoch nicht wirklich verschwunden, er hat nur seinen Ort gewechselt. Er hat sich in die Bereiche der Validierung, Prüfung und Qualitätssicherung verlagert, die früher eher nebensächlich waren.

Ein Vergleich mit ihrer Zeit bei Microsoft macht das besonders deutlich:

Während der Zeit von Visual Studio wurde die Software auf CDs gespeichert. Die Abgabetermine waren strikt: Die Software musste zur Herstellung der CDs, in die Verpackung und auf den Markt gebracht werden. Die Zeit für die Softwareentwicklung war äußerst kostbar, und die Teams mussten ihre Pläne aufs äußerste optimieren.

Später wechselte die Art der Abgabe zu Online-Veröffentlichungen. Heute wird die Codierung selbst durch KI stark beschleunigt, was eine weitere Veränderung darstellt.

Das Muster in diesen drei Epochen ist eigentlich identisch: Der alte Engpass wird überwunden, und ein neuer Engpass tritt an die Stelle.

Lenny erzählte in der Unterhaltung eine Geschichte. Er kennt einen Softwareingenieur, der früher bei der Ankündigung einer Funktionsanforderung sofort dachte: "Das ist zu schwierig, zu komplex, das geht nicht."

Jetzt hat sich seine Reaktion völlig verändert: "Das kann definitiv gemacht werden. Lass Claude Code es erledigen."

Fiona erzählte eine ähnliche Geschichte. In ihrem Team gibt es einen Softwareingenieur, der normalerweise nicht an der mobilen Entwicklung beteiligt ist. Bei einer Funktion musste die App auf das Mobile erweitert werden. Früher wäre dieser Vorgang an diesem Punkt gescheitert, da er kein Android-Experte war. Jetzt kann er mit Claude als Partner auch in technischen Bereichen, die ihm weniger vertraut sind, voranschreiten.

Fiona sagte: "Das hebt tatsächlich die Obergrenze dessen, was jeder leisten kann."

Dieser Satz klingt einfach, aber er beinhaltet vieles.

In der Vergangenheit war die technische Komplexität der Faktor, der die Leistung eines Softwareingenieurs einschränkte. Wenn man etwas nicht konnte, konnte man es nicht umsetzen. Jetzt hat sich der einschränkende Faktor verändert. Es ist jetzt die eigene Urteilsfähigkeit und der Ehrgeiz.

Theoretisch können viele Dinge umgesetzt werden. Das Wichtige ist:

Was wählst du aus, und wie überprüfst du, ob es richtig ist? "Wie schnell man schreibt" ist keine Frage mehr. Die Frage ist, ob man richtig schreibt.

Das ist das Ganze, was Fiona sieht: Die Explosion der Code-Menge, die Verschwammung der Rollengrenzen und die Erhöhung der Leistungsobergrenze treten gleichzeitig auf.

Klingt alles nach guten Nachrichten, oder?

Hinter den guten Nachrichten verbirgt sich eine Reihe neuer Probleme: Wer übernimmt die Verantwortung für die Qualität? Die KI kann dir alles tun, aber wie weißt du, dass es richtig ist? Wenn die Produktivität des Teams um das Achtfache gestiegen ist, kann man die alte Managementmethode, das Qualitätssicherungssystem und den Planungsrhythmus noch nutzen?

Fionas tägliche Arbeit bei Anthropic besteht darin, diese Fragen zu beantworten.

......

Ihr erster Schritt war die Installation einer Claude Code-Remotesitzung in allen Repositories.

Diese Instanz hat Zugang zu allen Repositories des Teams, den Slack-Kanälen und den Indikator-Dashboards. Mit anderen Worten: Sie hat einen "Gottessicht" und kann jederzeit sehen, was jeder macht und wie gut es geht.

Früher sah ihr Morgen so aus:

Mit einer Tasse Kaffee in der Hand öffnete sie verschiedene Feedbackkanäle und las, was die Benutzer und die internen Kollegen sagten. Wenn sie Zeit hatte, bearbeitete sie ein paar Probleme.

Jetzt hat sich dieser Ablauf komplett verändert.

Vor etwa ein bis zwei Monaten hat Claude Code Routines eingeführt, und ihr gesamter Arbeitsablauf wurde neu gestaltet.

Fiona sagte selbst: "Früher musste ich selbst Prompts schreiben. Jetzt habe ich mit Routines einen Agenten, der mir Prompts generiert und sogar Pull Requests erstellt.

Beispielsweise stelle ich eine Routine ein, die jeden Morgen den Feedback-Kanal überwacht und die Themen automatisch extrahiert. Wenn ich aufwache, ist eine Feedback-Zusammenfassung bereits erstellt, und nebenan liegen einige Pull Requests, die ich überprüfen muss."

Lenny fragte sie: "Als Managerin hast du früher Probleme identifiziert und Kollegen beauftragt, sie zu beheben. Jetzt hat Claude bereits die Lösung erstellt, und du musst nur überprüfen, ob du sie zusammenführen möchtest?"

Fiona sagte ja, und es geht noch weiter. Wenn die Validierung gut genug ist, kann man dem Agenten sogar mehr Autonomie geben und ihn direkt ausführen lassen.

Hast du bemerkt, dass hier eine interessante Rollenveränderung stattfindet?

Früher hast du selbst Anweisungen geschrieben und auf das Ergebnis gewartet. Später hast du mehrere Anweisungen gleichzeitig gesendet und nicht mehr warten müssen, sondern alle Ergebnisse zusammen abholen können.

Jetzt geht es noch einen Schritt weiter: Du legst einen festen Ablauf fest, der selbst Anweisungen schreibt und diese an verschiedene KI-Assistenten verteilt. Deine Rolle hat sich von "Selbsthandeln" zu "Nachträgliche Überprüfung" verändert. Wenn du einen Schritt weiter gehst, wirst du zum "Systembauer".

Fiona war sehr offen:

Früher musste sie sich Zeit nehmen, um Code zu schreiben. Jetzt muss sie sich Zeit nehmen, um die Arbeit aller KI-Assistenten zu verarbeiten.

Mit anderen Worten: Früher war ihr Kopf beim Schreiben von Code beschäftigt. Jetzt ist es die ständige Umschaltung und die individuelle Prüfung, was eine völlig neue Art der Kontextwechselbelastung ist.

......

Der Arbeitsablauf der Manager wurde neu gestaltet, und die Effizienz ist maximiert. Darauf folgt eine Frage: Die Produkte werden schneller hergestellt, aber wer übernimmt die Verantwortung für die Qualität?

Fiona sprach über einige Methoden, manche hart, manche etwas unkonventionell.

Zuerst die harte Methode: Automatisierte Codeüberprüfung. Sie sagte: "Denken Sie mal darüber nach. Vor einem Jahr hatten wir noch nicht einmal die Funktion, dass Claude Code Code automatisch überprüft. Früher war der menschliche Prüfer ein großer Engpass."

Natürlich müssen in Bereichen, die tiefgehende Fachkenntnisse erfordern, immer noch Menschen tätig sein. Viele Prüfungen, die als Standard festgelegt werden können, können jetzt vollständig an Claude übergeben werden.

Ihre Empfehlung ist sehr konkret:

Wenn du eine Definition von "gut" hast, sei es in Bezug auf Designrichtlinien, Code-Stil oder Architekturprinzipien, schreibe sie einfach auf und lege sie in das Code-Repository als Regeldatei ab.

Claude ist sehr gut darin, Validierungen gemäß diesen klaren Rahmenbedingungen durchzuführen.

Es gibt nur eine Voraussetzung: Diese Richtlinien-Dokumente müssen synchron mit dem Code aktualisiert werden. Wenn du es einfach so liegen lässt, ist es ein veraltetes Papier, das sogar schlimmer ist als gar nichts.

Die zweite Methode ist Testgetriebene Entwicklung, im Fachjargon TDD. Mit anderen Worten: Schreibe zuerst die Testfälle und dann den Code. Lege zuerst die Standards fest, die du erreichen möchtest, und dann beginne mit der Arbeit.

Beim ersten Bug, den sie in Claude Code repariert hat, hat sie die KI bitten, diesen Prozess durchzuführen: Zuerst die Tests schreiben, um sicherzustellen, dass sie fehlschlagen, und dann den Code reparieren, damit die Tests bestehen.

Ihre eigenen Worte:

TDD war in den 2000er Jahren sehr populär, und die Theorie ist gut. Ich hatte damals Schwierigkeiten, ich fühlte mich wie gezwungen, zuerst Brokkoli zu essen, während ich eigentlich lieber Produkte entwickeln und veröffentlichen wollte.

Jetzt ist die Testgenerierung automatisiert, und die richtigen, aber eher langweiligen Methoden aus der Vergangenheit sind plötzlich wieder aktuell.

Ich mag diese Metapher: Brokkoli ist gesund, aber schmeckt nicht gut. Tests sind wichtig, aber langweilig zu schreiben. Jetzt kaut die KI den Brokkoli für dich, und du musst nur das Fertige essen.

Die dritte Methode ist ein von ihr selbst entwickeltes Urteilsrahmenwerk, das sie "Bad vs Sad" nennt. Die englischen Begriffe sind nicht wichtig, merke dir nur die Bedeutung.

"Bad" sind schwerwiegende, nicht wiederherstellbare Fehler. Beispielsweise bricht die Befehlszeile während der Arbeit ab, und alles, was du geschrieben hast, geht verloren. Das ist "Bad".

"Sad" sind Probleme, die etwas unangenehm sind, aber von denen du dich erholen kannst. Beispielsweise flackert die Benutzeroberfläche kurz auf, was etwas nervt, aber keine Daten verloren gehen, und du kannst weiterarbeiten. Das ist "Sad".

Jedes Produkt ist anders, und jedes Team muss selbst definieren, was in ihrem Fall "Bad" und was "Sad" ist.

Hier gibt es eine sehr wichtige Erkenntnis: Wenn sich zu viele "Sad"-Probleme ansammeln, werden sie "Bad".

Fiona sagte: "In der Vergangenheit hatten wir zu viele Überwachungsdashboards, und es war schwierig, einen Überblick zu gewinnen. Deshalb ist es besser, statt auf eine Vielzahl von Rohdaten zu starren, ein Urteilsrahmenwerk zu haben, das dir hilft, zwischen wirklich schlechtem Benutzererlebnis und etwas unangenehmem, aber noch tolerierbarem zu unterscheiden."

Stelle sicher, dass du die echten "Bad"-Probleme löst, und überwache gleichzeitig die Tendenz der "Sad"-Probleme, damit sie sich nicht verschlechtern.

Die letzte Methode ist etwas ungewöhnlich. Im vergangenen September schlug ein Softwareingenieur im Team vor, dass wir die Häufigkeit, mit der Benutzer Flüche verwenden, verfolgen sollten.

Fiona fand es eine gute Idee. Klingt ziemlich absurd, oder? Dieser Indikator wurde tatsächlich zu einer Möglichkeit, die Stimmung der Benutzer zu überwachen. Wenn die Fluchhäufigkeit steigt, bedeutet das, dass das Produkt an einer Stelle frustrierend ist.

Es kann nicht die offiziellen Leistungsindikatoren ersetzen, aber es bietet eine völlig andere Perspektive: Ist der Benutzer bei der Verwendung deines Produkts glücklich oder ärgerlich?

Es gibt ein Qualitätssicherungssystem und Methoden zur Überprüfung. Wer soll es umsetzen? Welche Art von Menschen können in dieser Geschwindigkeit überleben und gut funktionieren?

......

Fiona sucht jetzt zwei Arten von Menschen.

Die erste Art nennt sie "dreamers". Übersetzt heißt das, kreative Menschen mit einem Gespür für Produkte.

Diese Menschen haben eine Idee im Kopf und setzen sie um. Sie beobachten das Feedback und verbessern das Produkt, bis das Benutzererlebnis zufriedenstellend ist. Sie tragen die gesamte Verantwortung für das Produkt von der Idee bis zur Umsetzung.

Die zweite Art sind Experten für tiefe Systeme.

Als sie dem Claude Code-Team beitrat, stellte sie fest, dass es zwar sehr gute allumfassende Produktmanager gab, aber es an einer Art von Menschen fehlte: Softwareingenieure, die wirklich das zugrunde liegende System und die verteilte Architektur verstehen. Selbst wenn das Modell sehr stark ist, müssen in vielen Bereichen Menschen verstehen, was im Hintergrund passiert, um vernünftige Entscheidungen treffen zu können.

Es reicht nicht, nur die richtigen Menschen zu haben. Sie betont wiederholt das Konzept der Paarung: Hohe Initiative und hohe Verantwortlichkeit.

Die englischen Begriffe sind "agency" und "accountability". Du musst sie nicht merken, merke dir nur die Bedeutung:

Jeder im Team kann eigene Ideen haben, um Probleme zu lösen. Das heißt hohe Initiative. Voraussetzung ist, dass du zwei Fragen beantworten kannst: Was willst du lösen? Was sind deine Annahmen? Du darfst nicht einfach nur Eifer haben, sondern auch Rechenschaft ablegen.

Mit anderen Worten: Du kannst loslegen, aber du musst die Ergebnisse akzeptieren.

Dann hat sie eine Methode, die ich als ziemlich hart empfinde: Alle neuen Manager müssen zunächst wieder an der Frontlinie Code schreiben und sich in die Codebasis einarbeiten, mindestens für ein Quartal. Das soll dir das Gefühl für das Produkt bewahren.

Ihre Logik ist einfach:

Die