Claude Code macht Ihr Produkt nicht besser

• Der Produktivitätseffekt von Coding-Agenten ist nicht gleichmäßig, sondern spaltet sich K-förmig auf; die entscheidende Kennzahl ist nicht die Zahl der Codezeilen pro Stunde, sondern ob sich die Geschwindigkeit der Produktverbesserung pro Engineer tatsächlich erhöht hat
• Dax, Karri Saarinen und David Cramer sind keine AI-Kritiker, sind aber nicht überzeugt, dass Coding-Agenten die Geschwindigkeit der Produktverbesserung deutlich erhöhen; Cramer meint, dass LLMs Komplexität und Aufblähung vergrößern und dadurch das langfristige Tempo verlangsamen
• Wenn Claude Code Anthropic intern sieben Monate lang einen exklusiven Vorteil gegeben hätte, müsste sich der Abstand zu Wettbewerbern durch den Zinseszinseffekt vergrößert haben; stattdessen bleiben Codex, Cursor, Cognition und Factory konkurrenzfähig, was darauf hindeutet, dass die Codeproduktion womöglich nicht der Engpass ist
• Eine gute Engineering-Kultur behandelt Codezeilen nicht als Vermögenswert, sondern als Kosten; mit jeder zusätzlichen Funktion und Integration wachsen Bug-Oberfläche, Abhängigkeiten und Randfunktionen mit, sodass Komplexität nicht linear, sondern exponentiell zunimmt
• An der Frontlinie der Produktqualität sind Geschmack, Kompression, Löschen und die Fähigkeit zum Ablehnen wichtiger als schnelles Schreiben von Code; Claude Code ist nützlich, um von 0 auf Camry-Niveau zu kommen, hilft Ferrari-Handwerkern aber nicht dabei, einen noch schnelleren Ferrari zu bauen

---

K-förmige Produktivitätskurve

• Die Produktivitätssteigerung durch Coding-Agenten ist nicht gleichmäßig, sondern spaltet sich K-förmig auf
  • Senior Engineers zeigen seit dem LLM-Wendepunkt 2023 einen messbaren Anstieg ihres Outputs
  • Der Output von Junior Engineers stagniert weitgehend oder sinkt sogar
  • Die wichtige Kennzahl ist nicht die Zahl der Codezeilen pro Stunde, sondern ob die Geschwindigkeit der Produktverbesserung pro Engineer tatsächlich steigt
• Agentisches Coding verkürzt bei bestimmten Aufgaben die Zeit bis zur Erstellung eines Pull Requests
  • Behauptungen wie „sechs Jahre Backlog in einem Quartal abgearbeitet“, „mit Cursor das Backend in drei Tagen gebaut“ oder „Claude Code wurde vollständig mit Claude programmiert“ tauchen immer wieder auf
  • Ob die Geschwindigkeit der Codeproduktion aber derselbe Maßstab ist wie eine Verbesserung der Produktqualität, bleibt eine andere Frage

Warnsignale von Engineers, die gute Produkte bauen

• Dax, Karri Saarinen und David Cramer sind allesamt keine AI-Kritiker, haben aber keine Gewissheit gewonnen, dass Coding-Agenten die Geschwindigkeit der Produktverbesserung klar erhöhen
  • Dax baut opencode.ai
  • Karri Saarinen ist CEO von Linear
  • David Cramer hat Sentry von Grund auf aufgebaut und auf ein Volumen von 10 Millionen US-Dollar Monatsumsatz skaliert
• David Cramer ist der Ansicht, dass LLMs derzeit keine Nettoproduktivitätssteigerung erzeugen
  • Sie senken die Einstiegshürde, erzeugen aber komplexe Software, die schwer zu warten ist
  • Auf lange Sicht scheinen sie das Tempo zu verlangsamen
  • Als Probleme nennt er die „mangelnde Fähigkeit zu inkrementeller Entwicklung inmitten von Komplexität“, die „mangelnde Fähigkeit zu echter Vereinfachung und zur Erzeugung idiomatischer Interfaces“ sowie „unsaubere Verfahren zur Testgenerierung“
  • Sein Fazit ist letztlich, dass das meiste davon Aufblähung (bloat) ist
• Dax sagt, man habe noch keinen klaren Weg gefunden, Coding-Agenten optimal zu nutzen
  • Von außen gibt es dagegen viele Behauptungen wie „jeder PR ist AI-generiert“, „beispielloses Tempo“ oder „sechs Jahre Backlog abgearbeitet“
  • Die tatsächliche Geschwindigkeit der Produktverbesserung zu erhöhen, fällt ihnen allen jedoch schwer

Der exklusive Vorteil von Claude Code zeigt sich nicht als wachsender Abstand

• Wenn Claude Code vollständig mit Claude programmiert wurde, müsste sich die Geschwindigkeit der Produktverbesserung beschleunigen
  • Wenn der Einsatz von Claude Code die Geschwindigkeit der Produktverbesserung auch nur um das 1,5-Fache erhöht, müsste ein Team, das es von Anfang an nutzt, den Abstand zu Wettbewerbern im Zeitverlauf vergrößern
  • Engineering-Produktivität ist eine Zinseszinsfunktion; der Unterschied müsste von Quartal zu Quartal größer werden
• Die tatsächliche Marktlage zeigt einen solchen Zinseszinsabstand nicht
  • Codex wurde einige Monate nach Claude Code veröffentlicht, ist funktional aber bereits konkurrenzfähig
  • Der Dealflow von Cursor ist stark
  • Cognition und Factory gewinnen weiterhin wichtige Enterprise-Verträge
  • Die Leute diskutieren immer noch darüber, welches Tool besser ist
• Der zentrale Gegenbeleg ist: Wenn Anthropic Claude Code sieben Monate exklusiv hatte, müsste der Abstand zu Wettbewerbern bei einem echten Produktgeschwindigkeitsvorteil so groß geworden sein, dass er nicht mehr aufzuholen wäre
  • Codex hätte bedeutungslos werden müssen, ist es aber nicht
  • Wenn kein Zinseszinseffekt sichtbar ist, war der Engpass bei der Produktqualität wahrscheinlich nicht der Code
• Auch mögliche Gegenargumente stärken dieselbe Schlussfolgerung
  • Selbst wenn es Gewinne gab, könnten sie von Komplexitätsschulden aufgezehrt worden sein
  • Das Engineering-Team von Anthropic könnte so groß gewesen sein, dass der Grenznutzen pro Engineer verwässert wurde
  • Aber auch dann liegt der Engpass nicht in der Codeproduktion, sondern in anderen, schwierigeren Faktoren

Codezeilen sind kein Vermögenswert, sondern Kosten

• Eine gute Engineering-Kultur behandelt Codezeilen nicht als Output, sondern als Ausgabe
  • Für wichtige Funktionen wird Code geschrieben, für unwichtige Funktionen nicht
  • Eine Codebasis ist kein Vermögenswert in der Bilanz, sondern eher eine Verbindlichkeit
• Die Software-Tochter tinychat von comma.ai ließ einen Alarm auslösen, wenn die Codebasis eine bestimmte Größe überschritt, und feierte gelöschten Code
  • Jede Codezeile ist Bug-Oberfläche
  • Jede Funktion wird zur Abhängigkeit der nächsten Funktion
  • Jede Funktionalität erzeugt weitere Randfunktionalitäten
• Die Produktoberfläche erweitert sich fraktal
  • Fügt man eine Slack-Integration hinzu, braucht man auch eine Teams-Integration und einen alternativen E-Mail-Pfad
  • Fügt man Benachrichtigungen hinzu, müssen sie für Mobile, SMS und Enterprise-MDM-Richtlinien neu umgesetzt werden
  • Fügt man MFA-Unterstützung hinzu, muss sie mit Duo, Okta und SAML kompatibel sein
  • Komplexität wächst nicht linear, sondern exponentiell
• Linear hat 178 Mitarbeiter, sechs Jahre Historie und 100 Millionen US-Dollar ARR
  • Jira ist beim kumulierten Engineering-Aufwand 56-mal größer als Linear, erzielt aber einen um sechs Punkte niedrigeren Qualitätswert bei Konsumenten
  • Der Kernpunkt ist, dass Qualität und Masse der Codebasis nicht dasselbe sind
• In einer Größenordnung wie bei Facebook ist die Fähigkeit, UI-Code schnell zu produzieren, nicht der Engpass
  • Ein erfahrener Engineer kann ein Mockup des Facebook-Feeds in einem Tag bauen
  • Die eigentliche Beschränkung besteht darin, die Zahl der Codezeilen zu reduzieren, die nötig sind, um diese Erfahrung Milliarden Menschen bei jeder Last und Latenz mit hoher Verfügbarkeit bereitzustellen
  • Die Zielfunktion ist nicht Produktion, sondern Kompression
  • Bei solcher Arbeit können Coding-Agenten langfristige Trade-offs nicht bewerten und haben keine Theorie des Systems

Der echte Engpass ist die Fähigkeit, die Frontlinie guter Produktideen zu verschieben

• Verbesserungen der Produktqualität an der Frontlinie werden nicht dadurch begrenzt, wie schnell man Code schreibt, sondern dadurch, wie schnell man gute genug Ideen entwickelt, um diese Frontlinie zu verschieben
• Der Unterschied zwischen Jira und Linear besteht nicht darin, dass bessere Boxen gezeichnet wurden
  • Linear hatte eine konkrete kreative Vision davon, wie sich Projektmanagement-Software anfühlen sollte, und hat diese über Jahre diszipliniert umgesetzt
  • Diese Qualität entsteht nicht aus Token-Durchsatz, sondern aus Geschmack und aus der Entscheidung, weniger zu bauen
• Die Behauptung „sechs Jahre Backlog abgearbeitet“ ist weniger beeindruckend, als sie klingt
  • Ein Backlog voller CRUD-Funktionen und interner Tools passt gut zu den Aufgaben, die Coding-Agenten beschleunigen
  • Gleichzeitig sind das nicht die Aufgaben, die die Frontlinie des Produkts verschieben
  • Ein Produkt wird nicht besser, weil es schneller ausgeliefert wird, sondern weil das Ausgelieferte den Nutzern wichtiger wird
• AI-Coding-Agenten helfen Produkten, die von 0 auf 1 gehen, schneller die Qualitätsfront zu erreichen
  • Sie verkürzen die Zeit bis zur ersten funktionierenden Version
  • In frühen Phasen existiert der Geschwindigkeitsgewinn tatsächlich
• Das hat jedoch Kosten
  • Die Codebasis wächst schneller als die Qualität
  • Technische Schulden akkumulieren mit Zinseszinseffekt
  • Die heute gewonnene Geschwindigkeit wird mit Kosten erkauft, die später bezahlt werden müssen

Camry für alle, Ferrari für niemanden

• Für Teams an der Frontlinie liegt der Engpass nicht bei Coding-Agenten, sondern bei Menschen mit Geschmack
  • Die Fähigkeit, wie bei Linear und Sentry „durch Weglassen großartig zu werden“, steckt in bestimmten Menschen
  • Als Beispiele werden Nan Yu von Linear und Kelly Johnson von Skunk Works genannt
  • Kelly Johnsons ausgewähltes Team baute die SR-71, die auch 60 Jahre später noch als schnellstes bemanntes luftatmendes Flugzeug gilt
  • Der Blackbird war nicht deshalb schnell, weil mehr Baupläne produziert wurden, sondern weil Johnson eine Theorie davon hatte, was weggelassen werden musste
  • Der Geschmack für Löschen, Kompression und Ablehnung steht auf keiner Frontier-Model-Roadmap und wird mit steigendem Mindestniveau sogar noch wertvoller
• Wenn man bereits an der Frontlinie ist, ist unklar, ob eine Verdopplung der F&E-Kosten durch Token-Ausgaben ökonomischen Wert schafft
  • Engineers bei Ramp sollen ihre effektiven Gehälter im vergangenen Jahr durch Token-Ausgaben faktisch verdoppelt haben
  • Ob das Produkt von Ramp dadurch tatsächlich besser geworden ist, lässt sich schwer feststellen
  • Wenn man bereits auf Platz 1 ist, ist die Siegquote nahezu fix, und „mit größerem Abstand Platz 1“ zu sein, ist schwer messbar
  • Um das Urteil zu ändern, bräuchte es Daten zur Siegquote oder Profitabilität von Ramp
  • Als Ramp-Kunde erklärt der Autor, dass er den Unterschied zwischen heute und dem vergangenen Jahr nicht spürt
• Claude Code kann jedem helfen, ein konkurrenzfähiges Camry-Produkt zu bauen, aber es hilft Ferrari-Handwerkern nicht, einen schnelleren Ferrari zu bauen
  • Für den Weg von 0 auf Camry-Niveau ist es sehr nützlich
  • Die Produktionskosten für Software, die nicht zur Spitzenklasse gehört, werden wahrscheinlich stark sinken
  • Dafür häufen sich an den Dachsparren der Fabrik viel Chaos und viele Schulden an, die am Ende jemand aufräumen muss

[GN⁺]

Lobste.rs-Kommentare

• Komplexität wächst exponentiell und vielleicht sogar noch schneller. Deshalb übersehen selbst Leute, die Angst vor einer AGI-Singularität haben, oft Folgendes: Egal wie klug ein Mensch, ein Modell oder ein Agent ist, sobald Ideen, Systeme, Projekte, Codebasen oder Funktionsumfänge wachsen, stoßen sie am Ende gegen eine steil ansteigende Wand der Komplexität
  Jedes Softwareprojekt läuft anfangs relativ glatt, aber irgendwann überrollt das exponentielle Wachstum der Komplexität alles. Gute Architektur, gutes Design und Qualität verschieben diesen Zeitpunkt nur nach hinten, und wenn fähige Leute gut entwerfen und auf Qualität achten, kann man Größe, Funktionsumfang, Performance und Wow-Faktor vielleicht etwa 10-mal weiter treiben, aber am Ende trifft man trotzdem auf diese Wand
  LLM-Unterstützung hilft dabei, bis zu einem gewissen Grad deutlich schneller Features und Code von meist durchschnittlicher Qualität zu erzeugen. Das heißt auch, dass man diese Wand deutlich schneller erreicht. Für Wachstum, Experimente und relativ einfache, aber zeitaufwendige Aufgaben mit geringer Komplexität ist das gut, aber es ermöglicht nicht, Dinge, die es vorher nicht gab, oder große, komplexe Projekte zu bauen. Dafür braucht man Verbesserungen, die Komplexität eindämmen, und genau das liefern aktuelle LLMs nicht wirklich

  • Das ist ein klassisches Problem. Wenn Ursache und Wirkung direkt aufeinander folgen, sind unmittelbare Vorteile leicht zu erkennen, aber wenn zwischen Ursache und Wirkung Zeit vergeht, sind die negativen Effekte viel schwerer zu sehen
    http://bastiat.org/en/twisatwins.html
    Die Kosten des Einsatzes von Code-Agenten zeigen sich nicht direkt und entstehen vor allem durch den Verlust des kollektiven Verständnisses dafür, wie das System funktioniert
  • Trotzdem bietet hierarchische Organisation einen Weg, großskalige Komplexität zu beherrschen. In der Natur kann man sehen, wie auf diese Weise enorm komplexe Strukturen entstehen. Man kann Systeme so bauen, dass unabhängige Einheiten sich zu größeren Strukturen zusammensetzen
    Robuste Systeme müssen Stöße aushalten und sich selbst anpassen können, daher muss jeder Teil unabhängig scheitern können und der Schaden lokal begrenzt bleiben. Organisiert man ein System als verschachtelte Untersysteme, entstehen zellartige Einheiten, die miteinander sprechen und Arbeit erledigen. Diese Einheiten funktionieren wie stabile Teilbaugruppen, ohne die inneren Abläufe anderer Zellen kennen zu müssen
    Jede Ebene kann sich in ihrem Bereich selbst organisieren und resilient bleiben, ohne von allem aufgehalten zu werden, was anderswo passiert. Im Grunde kapselt man damit zufällige Komplexität hinter Interfaces und schafft Abstraktionen, in denen diese Interfaces Bedeutung tragen. Ebenen versteht man am besten als verbindendes Gewebe zwischen den Bestandteilen eines großen Systems
    Erlang OTP ist ein gutes Beispiel für diesen Ansatz in Software: Große Systeme werden aus isolierten Prozessen aufgebaut, die sich gegenseitig Nachrichten schicken. Selbst wenn einzelne Prozesse abstürzen oder Fehler haben, reißt das nicht das Gesamtsystem mit
  • „Komplexität eindämmen“ erfordert meiner Meinung nach Entscheidungen, klare Positionen und manchmal auch Widerspruch oder Konflikte
    Wenn man jemanden bittet, etwas zu implementieren, kann die Antwort lauten: „Das ist zu komplex“, „Das wird in einem Jahr explodieren“, „Das ist nicht kompatibel mit dem, woran Team Y arbeitet“ oder „Wir haben nicht genug Leute, um das umzusetzen“. Die letzte Aussage kann wörtlich gemeint sein oder indirekt einfach „nein“ bedeuten
    Dass ein LLM so antwortet, ist sehr unwahrscheinlich. Vor allem, weil es auf Optimismus und Höflichkeit getrimmt ist. Außerdem scheint genau diese Tendenz nötig zu sein, um die Nutzung hochzuhalten, daher ist es eher unwahrscheinlich, dass das anders abgestimmt wird
    Das Problem wirkt ähnlich wie bei LLMs, die Nutzern beim Suizid geholfen haben. Das ist ziemlich eindeutig, und trotzdem ist es häufig vorgekommen. Wenn Projekte an unkontrollierter Komplexität sterben, ist das viel weniger offensichtlich, daher erwarte ich nicht, dass LLMs darin in naher Zukunft deutlich besser werden

• Eine Argumentation nach dem Muster: „Wenn Claude Code wirklich einen Geschwindigkeitsvorteil in der Produktentwicklung bringt und Anthropic ihn 7 Monate exklusiv hatte, dann dürfte der Abstand zwischen Claude Code und allen Wettbewerbern nicht mehr aufzuholen sein. Codex müsste irrelevant sein. Trotzdem diskutieren die Leute immer noch lebhaft darüber, was besser ist“ wirkt nicht besonders solide
  Claude Code ist gute Software, aber kein seltsamer AGI-Zauber, der Konkurrenz unmöglich macht

  • Außerdem wurde Codex ebenfalls mit Vibecoding gebaut, daher ist der Vergleich auch in dieser Hinsicht etwas komisch. Ein paar Monate Vorsprung könnten kaum Bedeutung haben. Viele der hinzugefügten Features ergeben sich daraus, was echte Nutzer tatsächlich mit dem Tool machen
    Claude Code hatte von Anfang an keine vollständig ausgearbeitete Roadmap, und die Hauptbarriere war nicht die Geschwindigkeit beim Schreiben von Code. Die eigentliche Barriere sind Ideen. Das entsteht bei allen erst im Tun
    Ich habe den Text nur grob überflogen, daher will ich dazu nicht zu tief einsteigen, aber abgesehen von der Groß- und Kleinschreibung am Satzanfang wirkte das meiste auf mich wie von einem LLM geschriebene Prosa, die ich nicht lesen möchte

• Bislang neigen Fehler von Agenten dazu, sich multiplikativ aufzusummieren
  Wenn man eine API baut, die technisch funktioniert, aber bei der Nutzung ein wenig zusätzlichen Code erfordert, führt das zu mehr Code und damit zu mehr Stellen für Duplikate, Verzweigungen und Bugs. Dann wird fraktalartig noch mehr nicht besonders guter Code geschrieben
  Ein Agent hat einmal eine Struktur mit einem optionalen id-Feld entworfen. Dieses Feld wurde nur wegen eines einzelnen von ihm selbst geschriebenen Konstruktors benötigt. Danach schrieb er unermüdlich zwei Codepfade, einen für den Fall mit id und einen ohne, und baute sogar eine unbeholfene Ersatzlogik für den Fall ohne id. Diese Ersatzpfade waren natürlich komplex und fragil. Fast jede Verwendung der Struktur und alles, was davon abhing, wurde davon infiziert, und der Konstruktor ohne id wurde am Ende nicht einmal benutzt. Man hätte leicht die Hälfte der Codebase löschen können
  Ich weiß wirklich nicht, ob man das mit genügend Anweisungen wie „Wenn du etwas Dummes tust, hör auf zu graben“ beheben kann und bis zur „Lösung“ des Codings nur noch ein paar Hacks fehlen, oder ob es sich um ein langfristiges Problem stochastischer Papageien handelt, bei dem für lineare Verbesserungen immer weiter exponentiell steigende Kosten nötig sind. Solange sich Fehler wie Zinseszinsen aufaddieren, wird dieses Wachstum am Ende zum Problem

  • Ich habe sehr ähnliche Dinge auch bei menschlichen Entwicklern gesehen. Eines der Merkmale, das die besten Entwickler auszeichnet, ist meiner Meinung nach die Neigung, eine Ebene höher und von außen auf die Sache zu schauen
    Manchmal schließt das sogar Geschäftsprozesse ein. Ein Entwickler mit gutem Domänenwissen kann statt monatelang an einer technischen Lösung zu bauen auch fragen: „Könnten wir den Prozess nicht einfach ändern, statt weiter daran herumzugraben?“ Und manchmal lautet die Antwort: „Natürlich, das ist einfach“
    LLMs werden darin vermutlich irgendwann auch besser werden. Schon jetzt finden sie recht oft etwas, wenn man direkt fragt: „Dieser Ansatz wirkt nicht gut, können wir Alternativen überlegen?“ Im Moment ist der Erfolg aber noch sehr inkonsistent, und wenn so etwas Dummes erst einmal gebaut ist, ist die Wahrscheinlichkeit gering, dass es dem Modell bei einer anderen, nicht zusammenhängenden Aufgabe von selbst auffällt
    Hier gibt es auch einen Trade-off. Leute beschweren sich schon jetzt darüber, dass Modelle Probleme überdenken und dabei Tokens verbrennen. Wenn ein Entwickler Erfahrung und Intuition dafür hat, „wie sich“ Code zur Lösung eines bestimmten Problems anfühlen sollte, weiß er ganz natürlich, wann er innehalten und zurückschauen muss. Vielleicht bekommen Agenten mit besserem Training irgendwann ebenfalls diese Intuition

• Ich würde gern sehen, wie das mit Daten nach dem Wendepunkt im November 2025 aktualisiert aussieht