Das Claude-Code-Team ist ja echt unverblümt, dass sie sogar solche Dinge nach außen ausplaudern.

Übrigens.

Claude hat ein Interviewvideo veröffentlicht, in dem das Claude-Code-Team erläutert, wie es Claude Code einsetzt, um Claude Code kontinuierlich zu optimieren.

In dem Interview äußerten die Claude-Mitarbeiter große Eindrücke über die Veränderungen ihrer Arbeitsweise im letzten Jahr.

Dabei gingen sie insbesondere auf ihre Sichtweise auf das Thema „Produktentwicklung bei sehr schnellen Iterationsrhythmen“ ein.

△ (Die Szene wirkt so herzlich, als würden drei fürsorgliche Väter über die Kindererziehung diskutieren.)

Dieser Artikel fasst die Kerninhalte des Interviews zusammen, die Highlights umfassen unter anderem:

„Du musst eine sehr unbefangene Haltung zu dem bewahren, was du gerade baust, denn es wird sehr schnell verschwinden.“

„Unser aktuelles Arbeitsniveau liegt bereits eine Abstraktionsebene über den Tokens, die Claude tatsächlich ausgibt.“

„Wir sind gezwungen, Claude selbst handeln zu lassen, denn Vertrauen ist wichtiger als Überwachung.“

„Du musst sowohl an der Spitze der Technik stehen als auch den Menschen, die das Modell heute nutzen, einen Mehrwert bieten. Das ist eine Kunst und gleichzeitig eine Wissenschaft.“

„Softwareentwicklung ist ein „Beruf des Wandels“. Die Probleme, die du löst, ändern sich, aber der Kern bleibt immer das Problemlösen.“

Wir hoffen, dass dies auch für dich, der ebenfalls unter dem Rhythmus schneller technischer Iterationen arbeitet, anregend ist.

Wie arbeitet das Team derzeit?

Das Team gibt an, dass inzwischen 70 % bis 80 % der täglichen Arbeit von dem in Slack (das amerikanische Äquivalent zu Feishu) nativen KI-Agenten Claude Tag erledigt werden.

Vor einem Jahr hingegen lasen die Ingenieure von Claude Code noch die Arbeitsaufzeichnungen der KI Zeile für Zeile durch.

Einschließlich jedes einzelnen Tool-Aufrufs, jeder Parameterauswahl, jedes Schrittes der Schlussfolgerungsentscheidung …

(Das ist ein riesiger Arbeitsaufwand.)

Ihr zentrales Arbeitskonzept lautet nun: Statt jeden Tool-Aufruf und jede Modellentscheidung einzeln zu prüfen, gibt man ein Ziel vor und lässt das Modell es selbst erreichen.

Es ist unklar, ob dieses Konzept mit dem Produktdesign von Claude Tag zusammenhängt – möglicherweise um es wie einen echten Teilnehmer in Slack wirken zu lassen, haben sie die Benutzeroberfläche vollständig von den Denkprotokollen des Modells entkoppelt.

Auf diese Weise wird der innere Monolog der KI von der Slack-Oberfläche verborgen. Jede Nachricht, die Menschen sehen, ist nur das Ergebnis von Claude, der das Tool zum Senden von Nachrichten aufruft – sein echter Denkprozess wird nicht in Echtzeit angezeigt.

Das Team betrachtet dies als eine etwas beängstigende, erzwungene Loslösung von der Kontrolle.

Gleichzeitig nutzen sie Claude Tag auch aggressiv, um Claude Tag selbst weiterzuentwickeln.

Dazu nennen sie ein sehr interessantes Beispiel für die Entwicklung eines neuen internen Tools:

Der erste Schritt lautet, Claude Tag zu fragen: „Ich habe eine Idee, mit wem sollte ich darüber sprechen? Wer würde daran interessiert sein?“

Claude Tag liefert eine Liste von Stakeholdern.

Nach den Gesprächen geht es im zweiten Schritt direkt darum, Claude Tag mit der Erstellung von Prototyp-Skizzen und der konkreten Implementierung zu beauftragen.

Im dritten Schritt lässt man Claude Tag eine große Anzahl von Tracking-Punkten hinzufügen, das Tool für die interne Nutzung bereitstellen und beobachten: „Wie nutzen die Leute es? Gibt es Rückmeldungen für mich?“

Danach überwacht Claude Tag kontinuierlich die Nutzungsdaten dieses Tools. Sobald es Rückmeldungen erhält, erinnert es den verantwortlichen Mitarbeiter aktiv und wird angewiesen: „Verbessere diesen Conversion-Trichter, finde selbst eine Lösung dafür.“

Kurz gesagt, es ist ein rein freies, ungezwungenes Vorgehen. Sie geben an, dass in dieser Phase möglicherweise Vertrauen wichtiger ist als Überwachung.

Der Kernpunkt ist „kein Festhalten an veralteten Lösungen“

Tatsächlich müssen alle Probleme unter einer Voraussetzung betrachtet werden.

Die Fähigkeiten des Basismodells machen alle zwei Monate einen grundlegenden Sprung nach vorne.

„Die technische Grundlage ändert sich alle zwei Monate grundlegend unter deinen Füßen … Du musst an der Spitze stehen, eigentlich sogar über die Spitze hinausgehen, um diese Grenze wirklich zu spüren. Gleichzeitig musst du aber den Menschen, die diese Modelle heute nutzen, einen Mehrwert bieten.“

Das ist eine Balance, zur Hälfte Kunst, zur Hälfte Wissenschaft.

Daraus ergibt sich eine Arbeitsregel: „Du musst eine sehr unbefangene Haltung zu dem bewahren, was du baust.“

Schließlich dienen viele Funktionen, die in Harness aufgenommen werden, im Wesentlichen dazu, die damaligen Mängel der Modellfähigkeiten auszugleichen. Sobald das Modell stärker wird, müssen diese Funktionen sofort entfernt werden.

Ein klassisches Beispiel ist die Funktion To-Do-Liste.

In der Phase von Sonnet 3.5 konnte das Modell noch keine komplexen Aufgaben mit mehreren aufeinanderfolgenden Schritten erledigen, daher brauchte es eine Aufgabenliste.

Ein Jahr später verfügt das Modell über komplexere Gedächtnisfähigkeiten, und diese einst unverzichtbare Funktion wurde wie ein Gerüst abgebaut.

Ein weiteres Beispiel ist das Tool AskUserQuestion.

Ursprünglich wurde es sorgfältig entwickelt, damit Claude mitten in einer Aufgabe aktiv Fragen an Nutzer stellen kann. Nachdem die Fähigkeit des Modells zur Generierung von HTML gestiegen ist, sind die Entwickler natürlich dazu übergegangen, Claude direkt visuelle Artefakte mit Diagrammen und Mockups erstellen zu lassen, um Fragen zu stellen.

Angesichts dieser instabilen Realität verfolgt das Team den Ansatz, keine vollständigen festen Lösungen mehr zu bauen, sondern einzelne, frei kombinierbare „Primitive“ zu erstellen.

Zum Beispiel Berechtigungen, Visualisierungen, Überprüfungen, Code-Reviews, Feedback …

Der Vorteil davon ist, dass der Aufwand geringer ist, wenn ein Primitive veraltet ist und ersetzt werden muss.

Und wenn diese Primitive übereinandergeschichtet und kombiniert werden, entstehen oft unerwartete neue Fähigkeiten.

Der Kern eines Ingenieurs ist immer das Problemlösen

Wenn man die größte Veränderung der Arbeitsweise in diesem Jahr nennen müsste, lässt sie sich kurz zusammenfassen: Die Granularität der Interaktion zwischen Mensch und KI verschiebt sich ständig nach oben.

Angefangen bei Tokens und konkreten Tool-Aufrufen, über eine einzelne Sitzung (Session), dann zu einem vollständigen Ziel (Goal), bis hin zu dem heutigen „dauerhaft laufenden Arbeitssystem, das die Grenzen mehrerer Sitzungen überschreitet“.

Die Abstraktionsebenen steigen ständig an, was sich auch in zwei parallelen Entwicklungslinien zeigt.

Die erste ist die Weiterentwicklung der Infrastruktur: Von der lokalen Ausführung in den Anfängen über Remote-Entwicklungsrechner bis hin zu gehosteten Containern und schließlich der Webversion, die in Cloud-Containern laufen kann, wird sichergestellt, dass Aufgaben ständig im Hintergrund ausgeführt werden und Routineaufgaben erledigt werden können.

Die zweite ist die Entwicklung des Code-Review-Ansatzes.

Menschen können sich von den trivialen Code-Reviews lösen: Claude durchsucht einen großen Bereich nach so vielen vermuteten Problemen wie möglich, führt dann für jedes vermutete Problem ein adversatives Review durch und macht eine Gegenprüfung aus drei verschiedenen Blickwinkeln, um den Großteil des Rauschens herauszufiltern und nur die wirklich beachtenswerten Probleme an Menschen weiterzugeben.

Dieser Ansatz hat sich später zu Workflows weiterentwickelt, bei denen Claude selbst Code schreibt, um die Zusammenarbeit mehrerer Sub-Agenten zu orchestrieren und die deterministische Codelogik mit der autonomen Beurteilung der Agenten zu verbinden.

Derzeit haben die Mitarbeiter im Claude-Code-Team, die sich handwerklich mit der Code-Erstellung befassen, die Sorge „ersetzt zu werden“ abgelegt und genießen den Vorteil der gesteigerten Leistung …

Schließlich ist die Softwareentwicklung im Wesentlichen eine vom Wandel geprägte Branche – obwohl die zu lösenden Probleme sich ständig ändern und die Werkzeuge zum Lösen der Probleme sich ständig weiterentwickeln.

Wer hätte das gedacht? Vor zehn oder zwanzig Jahren schrieben Menschen noch JavaScript ohne jegliches Framework von Hand.

Heutzutage ist die Geschwindigkeit des Wandels höher, aber die zugrundeliegende Logik hat sich nie geändert – letztendlich:

Ein Ingenieur ist immer ein Beruf, der sich um „das Lösen von Problemen“ dreht.

Referenzlink: [1]https://www.youtube.com/watch?v=S-sYlFiGFv8

Dieser Artikel stammt aus dem WeChat-Offiziellen Konto „QbitAI“, Autor: Cheng Qian, veröffentlicht mit Genehmigung von 36Kr.