Update zum jüngsten Bericht über die Qualität von Claude Code

• Der in den letzten Monaten wahrgenommene Qualitätsrückgang bei Claude ging auf drei voneinander unabhängige Änderungen in Claude Code, Claude Agent SDK und Claude Cowork zurück; die API war nicht betroffen
• Nachdem die standardmäßige Denkintensität auf medium gesenkt worden war, gingen Latenz und Verbrauch der Usage Limits zwar zurück, aber Claude Code wirkte weniger intelligent, weshalb der Standardwert am 7. April wieder zurückgesetzt wurde
• Ein am 26. März ausgerollter Bug in einer Caching-Optimierung führte dazu, dass in Sitzungen nach Überschreiten eines Idle-Schwellenwerts die Denk-Historie bei jedem Turn gelöscht wurde, was zu Vergesslichkeit, Wiederholungen, seltsamer Tool-Auswahl und einem schnelleren Verbrauch der Usage Limits führte
• Eine mit Opus 4.7 am 16. April eingeführte Zeile im System Prompt sollte übermäßige Ausführlichkeit in der Ausgabe reduzieren, doch in breiteren Evaluierungen sank die Leistung einiger Modelle um 3 %, weshalb die Änderung am 20. April zurückgenommen wurde
• Alle drei Probleme wurden behoben und in v2.1.116, ausgerollt am 20. April, aufgenommen; als zentrale Maßnahmen zur Vermeidung von Wiederholungen gelten kleinere Unterschiede zwischen internen und öffentlichen Builds, strengere Kontrolle von System Prompts, breitere Evaluierungen und schrittweise Rollouts

---

Umfang des jüngsten Qualitätsrückgangs und Stand der Wiederherstellung

• Der von einigen Nutzern im vergangenen Monat wahrgenommene Qualitätsrückgang bei Claude ging auf drei separate Änderungen in Claude Code, Claude Agent SDK und Claude Cowork zurück, die API war nicht betroffen
• Alle drei Probleme wurden behoben und in v2.1.116, ausgerollt am 20. April, übernommen
• Da jede Änderung einen anderen Zeitplan hatte und andere Traffic-Bereiche betraf, wirkte das Ganze insgesamt wie ein weit verbreiteter, aber inkonsistenter Leistungsrückgang
• Berichte dazu wurden seit Anfang März untersucht, waren anfangs jedoch schwer von normalen Schwankungen im Nutzerfeedback zu unterscheiden, und auch bei interner Nutzung und in Evaluierungen ließ sich dasselbe Problem zunächst nicht reproduzieren
• Zum Stand vom 23. April wurden die Usage Limits aller Abonnenten zurückgesetzt

Änderung der standardmäßigen Denkintensität in Claude Code

• Als im Februar Opus 4.6 in Claude Code eingeführt wurde, war die standardmäßige Denkintensität auf high gesetzt
• Kurz darauf traten im high-Modus zeitweise übermäßig lange Denkzeiten auf, wodurch die UI eingefroren wirkte und bei einigen Nutzern Latenz und Token-Verbrauch übermäßig anstiegen
• Das Effort-Level in Claude Code dient dazu zu steuern, ob länger nachgedacht werden soll oder stattdessen geringere Latenz und ein geringerer Verbrauch der Usage Limits bevorzugt werden
  • In der Produktschicht wird dafür ein Standardwert auf der Test-Time-Compute-Kurve festgelegt und als Effort-Parameter an die Messages API übergeben
  • Weitere Optionen stehen über /effort zur Verfügung
• Interne Evaluierungen und Tests zeigten, dass medium bei den meisten Aufgaben zu leicht geringerer Intelligenz, aber deutlich geringerer Latenz führte
  • medium hatte auch weniger Probleme mit sehr langen Tail-Latenzen
  • Außerdem war es günstiger, um die Usage Limits der Nutzer zu maximieren
• Auf Basis dieser Ergebnisse wurde der Standard-Effort auf medium gesetzt und der Grund dafür per Dialog im Produkt kommuniziert
• Unmittelbar nach dem Rollout begannen Nutzer jedoch den Eindruck zu haben, Claude Code sei weniger intelligent geworden
  • Es wurden mehrere Designänderungen eingeführt, etwa ein Hinweis beim Start, ein Inline-Effort-Selektor und die Wiederherstellung von ultrathink, um die aktuelle Effort-Einstellung sichtbarer zu machen
  • Dennoch blieben die meisten Nutzer weiterhin beim Standardwert medium
• Nach weiterem Kundenfeedback wurde diese Entscheidung am 7. April rückgängig gemacht
  • Für alle Nutzer ist jetzt bei Opus 4.7 standardmäßig xhigh gesetzt
  • Bei allen anderen Modellen ist high der Standardwert
• Diese Änderung betraf Sonnet 4.6 und Opus 4.6

Caching-Optimierung, die frühere Denk-Historie verwarf

• Wenn Claude über eine Aufgabe nachdenkt, bleibt diese Denk-Historie in der Konversationshistorie erhalten, sodass in späteren Turns weiterhin auf Gründe für frühere Änderungen und Tool-Aufrufe Bezug genommen werden kann
• Am 26. März wurde eine Änderung ausgerollt, die die Effizienz dieser Funktion erhöhen sollte
  • Anthropic verwendet Prompt Caching, um aufeinanderfolgende API-Aufrufe günstiger und schneller zu machen
  • Claude schreibt bei API-Anfragen Eingabe-Token in den Cache; nach einer bestimmten Inaktivitätszeit wird der entsprechende Prompt aus dem Cache entfernt, um Platz für andere Prompts zu schaffen
  • Die Cache-Nutzung wird sorgfältig gesteuert; der zugehörige Ansatz ist in diesem approach beschrieben
• Laut Design sollte, wenn eine Sitzung länger als eine Stunde inaktiv gewesen war, der vorherige Thinking-Abschnitt einmal entfernt werden, um die Kosten für das Wiederaufnehmen der Sitzung zu senken
  • Diese Anfrage wäre ohnehin ein Cache Miss, daher sollten unnötige Nachrichten aus der Anfrage entfernt werden, um die Zahl uncached Tokens zu reduzieren, die an die API gesendet werden
  • Danach sollte wieder die vollständige Denk-Historie gesendet werden
  • Dazu wurden der API-Header clear_thinking_20251015 und keep:1 verwendet
• In der tatsächlichen Implementierung gab es jedoch einen Bug: Statt die Thinking-Historie nur einmal zu löschen, wurde sie bis zum Ende der Sitzung bei jedem Turn erneut gelöscht
• Sobald eine Sitzung einmal den Idle-Schwellenwert überschritten hatte, wurden bei allen späteren Anfragen dieses Prozesses alle früheren Denkblöcke bis auf den jüngsten aus der an die API gesendeten Historie verworfen
• Das Problem verschlimmerte sich kumulativ
  • Wenn Claude während der Tool-Nutzung eine Folgemeldung sendete, wurde diese selbst zu einem neuen Turn unter dem fehlerhaften Flag
  • Dadurch konnte sogar das Denken des aktuellen Turns abgeschnitten werden
• Claude lief weiter, agierte aber zunehmend ohne Erinnerung daran, warum bestimmte Handlungen gewählt worden waren
  • Für Nutzer zeigte sich das als Vergesslichkeit, Wiederholungen und seltsame Tool-Auswahl
• Da auch in Folgeanfragen die Thinking-Blöcke weiter verschwanden, führten diese Anfragen zu Cache Misses
  • Separate Berichte, wonach die Usage Limits schneller als erwartet verbraucht würden, werden auf dieses Verhalten zurückgeführt
• Dass der Fehler anfangs schwer zu reproduzieren war, lag auch an zwei nicht damit zusammenhängenden Experimenten
  • ein nur intern laufendes serverseitiges Experiment zur Nachrichtenwarteschlange
  • eine separate Änderung an der Darstellung von Thinking, die den Bug in den meisten CLI-Sitzungen verdeckte
• Der Bug lag an der Schnittstelle von Kontextverwaltung in Claude Code, der Anthropic API und Extended Thinking
  • Er passierte Code Reviews durch mehrere Personen und automatisierte Code Reviews
  • Unit-Tests und End-to-End-Tests
  • sowie automatische Verifikation und Dogfooding
• Da das Problem nur in einem Corner Case mit alten Sitzungen auftrat und sich schwer reproduzieren ließ, dauerte es über eine Woche, die Grundursache zu finden und zu bestätigen
• Im Verlauf der Untersuchung wurden die Pull Requests, die das Problem verursacht hatten, mit Code Review auf Basis von Opus 4.7 rückgetestet
  • Wenn die dafür nötigen Code-Repositories zum Sammeln des Gesamtkontexts mitgegeben wurden, fand Opus 4.7 den Bug
  • Opus 4.6 fand ihn nicht
• Um Wiederholungen zu vermeiden, wird derzeit Unterstützung dafür eingeführt, bei Code Reviews zusätzliche Repositories als Kontext einzubinden
• Dieser Bug wurde in v2.1.101 am 10. April behoben
• Diese Änderung betraf Sonnet 4.6 und Opus 4.6

Änderung am System Prompt zur Reduzierung von Ausführlichkeit

• Das neueste Modell, Claude Opus 4.7, neigt im Vergleich zu früheren Modellen zu sehr ausführlichen Ausgaben
  • Auf diese Eigenschaft wurde bereits zum Start hingewiesen; weitere Details finden sich in wrote about
• Diese Ausführlichkeit macht das Modell bei schwierigen Problemen zwar intelligenter, erhöht aber auch die Zahl der Output-Tokens
• Einige Wochen vor dem Start von Opus 4.7 begann Claude Code mit Anpassungen an das neue Modell
  • Jedes Modell verhält sich etwas anders, daher werden Harness und Produkt vor einem Release modellabhängig optimiert
• Zur Reduzierung der Ausführlichkeit werden Modelltraining, Prompting und Verbesserungen der Thinking-UX im Produkt gemeinsam genutzt
• Eine der zusätzlich in den System Prompt aufgenommenen Zeilen hatte dabei einen zu starken Einfluss auf die Intelligenz von Claude Code
  • “Length limits: keep text between tool calls to ≤25 words. Keep final responses to ≤100 words unless the task requires more detail.”
• In mehreren Wochen interner Tests und mit den verwendeten Evaluierungssätzen zeigte sich keine Regression, daher wurde die Änderung mit Vertrauen zusammen mit Opus 4.7 am 16. April ausgerollt
• Im Zuge der späteren Untersuchung wurde mit Ablation über breitere Evaluierungssätze hinweg der Einfluss einzelner Zeilen des System Prompts isoliert untersucht
• In einer dieser Evaluierungen zeigte sich ein Rückgang von 3 % sowohl bei Opus 4.6 als auch bei 4.7
• Dieser Prompt wurde als Teil des Releases vom 20. April sofort zurückgenommen
• Diese Änderung betraf Sonnet 4.6, Opus 4.6 und Opus 4.7

Künftige Änderungen

• Um ähnliche Probleme zu vermeiden, sollen künftig mehr interne Mitarbeiter exakt dieselbe öffentliche Claude-Code-Build verwenden
  • Damit soll der Unterschied zwischen internen Versionen zum Test neuer Funktionen und den tatsächlich öffentlich ausgelieferten Builds kleiner werden
• Das intern verwendete Tool Code Review wird verbessert, und diese verbesserte Version soll auch für Kunden bereitgestellt werden
• Für Änderungen an System Prompts werden strengere Kontrollprozesse eingeführt
  • Für alle Änderungen an den System Prompts von Claude Code werden modellübergreifend breite Evaluierungen durchgeführt
  • Ablation wird weiter genutzt, um den Einfluss einzelner Zeilen zu verstehen
  • Außerdem werden neue Werkzeuge gebaut, um Prompt-Änderungen leichter prüfen und auditieren zu können
• Zu CLAUDE.md wurden Leitlinien ergänzt, damit modellspezifische Änderungen nur auf das jeweilige Modell angewendet werden
• Für alle Änderungen, die mit Intelligenz in Konflikt geraten könnten, werden Soak Periods, breitere Evaluierungssätze und schrittweise Rollouts eingeführt, um Probleme schneller zu erkennen
• Um Produktentscheidungen und deren Hintergründe ausführlicher zu erklären, wurde auf X @ClaudeDevs eingerichtet; dieselben Updates sollen auch in einem zentralen Thread auf GitHub geteilt werden
• Informationen, die über den Befehl /feedback oder über konkrete und reproduzierbare Beispiele online eingingen, halfen bei Identifizierung und Behebung der Probleme
• Das Zurücksetzen der Usage Limits für alle Abonnenten wurde an diesem Tag erneut angewendet

[GN⁺]

Hacker-News-Kommentare

• Die Erklärung, dass bei mehr als 1 Stunde inaktiven Sitzungen altes Thinking gelöscht wurde, um die Latenz zu senken, überzeugt mich nicht wirklich.
  Ich lasse Sessions oft stunden- oder tagelang liegen und setze dann mit dem gesamten Kontext unverändert wieder an, deshalb war diese Funktion für mich zentral.
  Dass das Standard-Reasoning-Niveau gesenkt wurde, kann ich noch einigermaßen nachvollziehen, aber bei den ständigen Änderungen am System-Prompt muss ich wohl verstehen, wie ich den Refresh-Zyklus bewusst selbst wählen kann.

  • In Claude Code gilt bei einer Unterhaltung mit N Nachrichten normalerweise, dass N-1 Nachrichten im Prompt-Cache liegen, abgesehen von der neuesten.
    Das Problem ist: Wenn man eine Sitzung länger als 1 Stunde idle lässt, sind beim nächsten Senden des Prompts plötzlich alle N Nachrichten ein Cache-Miss.
    Dieser Corner Case hat die Token-Kosten für Nutzer übermäßig erhöht, und bei einem extremen Kontext von 900k Tokens musste man bei der Rückkehr über 900k+ Tokens erneut in den Cache schreiben, was besonders bei Pro-Nutzern das Rate Limit stark aufgefressen hat.
    Deshalb hat man versucht, Nutzer etwa auf X aufzuklären, im Produkt mehrfach Tipps einzubauen, bei der Rückkehr zu alten Gesprächen /clear zu empfehlen, und auch getestet, nach Idle-Zeiten alte Tool-Ergebnisse, alte Nachrichten oder Teile des Thinking wegzulassen — dabei schnitt das Entfernen des Thinking am besten ab.
    Beim Ausrollen sei dann unbeabsichtigt der im Blog beschriebene Bug hineingeraten, und man beantworte gern weitere Fragen.
  • Es überrascht mich, dass ein Unternehmen mit einem Wert von zig Milliarden Dollar so eine Entscheidung getroffen hat.
    Entweder glaubte man wirklich, dass weniger Latenz bei Idle-Sitzungen wichtiger sei als Ausgabequalität, oder das eigentliche Ziel war Kostensenkung, während im Blog Latenz nur als plausibel klingende Begründung diente.
    Es wäre viel natürlicher gewesen, während des erneuten Ladens des Kontexts einfach einen deutlicheren Ladehinweis anzuzeigen.
  • Das ist ziemlich schockierend.
    Früher habe ich CC wie einen Kollegen genutzt: über ein Problem nachdenken, dann den Plan aktualisieren, unter der Dusche weitergrübeln und später neuen Input geben — ich habe das mindestens für etwa einen Tag als statisches Gespräch betrachtet.
    Wenn die Grenze aber bei 1 Stunde liegt, ist das so kurz, dass ich mir ernsthaft überlege, ob ich meinen Anthropic-Plan weiterlaufen lasse.
  • Die Erklärung zum Entfernen von Tokens nach 1 Stunde wirkt auch deshalb verdächtig, weil diese Zeit genau mit dem eigenen Cache-Limit zusammenfällt.
    Es sieht eher nach einer Änderung aus, die vor allem die Kosten stark senken sollte, als nach einem Zufall.
  • Das dürfte auch mit dem zeitbasierten Nutzungs-Reset maximal schlecht zusammenwirken.
    Wenn viele Nutzer ihre Session ruhen lassen, nachdem sie ihr Limit ausgeschöpft haben, und später zurückkommen, ist das kein Ausnahmefall, sondern fast schon das Standard-Nutzungsmuster.

• Dass hier so heftig draufgehauen wird, überrascht mich etwas.
  Der Text selbst war relativ klar und ehrlich und wirkte durchaus plausibel.
  Der Leistungsverlust war real und ärgerlich, hat aber zugleich die Intransparenz offengelegt, was im Hintergrund tatsächlich passiert, und wie willkürlich die Abrechnung nach Token-Kosten aufgebaut ist.
  Wer schon direkt mit LLM-APIs gearbeitet hat, dem war eigentlich klar, dass das Wiederaufnehmen lange ruhender Gespräche Zusatzkosten und Latenz verursacht, aber in der TUI sollte man das wohl deutlich sichtbarer machen.

  • Die Leute sind vor allem deshalb wütend, weil monatelang öffentlich abgestritten wurde, dass es überhaupt ein Problem gibt.
    Darum ist die Ablehnung jetzt trotz der Erklärung so groß.

• Ein Teil des wahrgenommenen Qualitätsabfalls könnte daran liegen, dass das Modell gar nicht wirklich schlechter geworden ist, sondern dass Nichtdeterminismus hier eine Rolle spielt.
  Vor ein paar Wochen bat ich Claude, eine persönliche Produktivitäts-App zu bauen, beschrieb das gewünschte Verhalten ausführlich und ließ mir einen Implementierungsplan schreiben; das erste Ergebnis war bis auf einen missverständlichen Punkt wirklich ausgezeichnet.
  Nachdem ich diese Unklarheit behoben hatte, ließ ich es in einem neuen Chat ohne Überarbeitung des bestehenden Plans noch einmal von vorn machen — bei unveränderten Modelleinstellungen war das Resultat viel schlechter, der nächste und übernächste Versuch ebenfalls, und erst beim vierten Anlauf war es wieder auf dem Niveau des ersten.
  Deshalb habe ich den Eindruck, dass es oft besser sein kann, dieselbe Aufgabe einfach noch einmal laufen zu lassen, auch wenn das bei Abrechnung nach eigenen Tokens schnell teuer wird.

  • Ich sehe das ähnlich.
    Es gibt zwar ein Muster, bei dem sich das Modell periodisch schlechter anfühlt, aber vielleicht tritt einfach nur der Punkt, an dem man hart an seine Grenzen stößt, jeweils später ein.
    Und sobald man einmal eine schlechte Ausgabe mit Pechfaktor erlebt hat, sieht man danach nur noch das.
  • Dann landet man am Ende vielleicht bei einem Modus wie bei der Bildgenerierung, wo man zu einem Prompt gleich 50 Versionen erzeugt und Menschen anschließend manuell die beste auswählen.
    Für Anthropic wäre das sogar ein willkommenes Muster, weil der Token-Verbrauch dadurch steigt.
  • Bei einer so low-stakes Produktivitäts-App wäre es womöglich schneller gewesen, sie direkt selbst zu bauen als die Zeit hier zu investieren.
  • Vielleicht hat man aus der Sache gelernt, dass LLMs viel nichtdeterministischer sind als gedacht, aber diesen Umstand direkt mit den jüngsten Leistungsverschlechterungen zu verknüpfen, könnte trotzdem ein Fehler sein.
    Nichtdeterminismus gab es schon immer, und der weithin gemeldete jüngste Qualitätsabfall könnte ein separates Phänomen sein.

• Bei Opus 4.7 war ich innerlich schon raus.
  OpenAI drängt bei uns im Enterprise-Bereich extrem hart hinein und hat bis zum Sommer sogar unbegrenzte Tokens angeboten.
  Deshalb habe ich in den letzten 30 Tagen GPT5.4 mit extra high effort genutzt; ich weiß nicht, ob ich Sonderbehandlung bekomme, aber ich habe fast keine Fehler gesehen.
  Der Reasoning-Trace war manchmal geradezu absurd gut, und das Modell hat sogar Dinge mitgedacht, die ich nicht explizit angewiesen hatte, um die Datenintegrität zu 100 % sicherzustellen.

  • Fühlt sich für mich ähnlich an.
    All diese trickreichen Änderungen könnten darauf hindeuten, dass Anthropic massiv unter Compute-Beschränkungen leidet und deshalb mit Gewalt versucht, den Verbrauch zu senken.
  • GPT-5.4 war in vielen Bereichen schon besser als Opus 4.6, besonders bei Genauigkeit und schwieriger Logik.
    Umso gespannter bin ich, wie viel besser 5.5 noch wird.
  • extra high verbrennt viel zu viele Tokens.
    Für 90 % der Aufgaben ist 5.4 auf medium deutlich fokussierter und produziert weniger unnötige Änderungen; auf high würde ich nur hochgehen, wenn medium erkennbar nicht reicht.
  • Stimmt.
  • Ich bin zu 4.5 zurückgegangen und bereue es nicht.
    Außerdem ist es etwas günstiger.

• In letzter Zeit produziert Claude oft Ausgaben, die wie Antworten auf den internen Prompt wirken.
  Zum Beispiel sagt es, ein Satz in Klammern sei ein Prompt-Injection-Versuch und werde ignoriert, oder jemand versuche, seine allgemeinen Richtlinien zu verbergen, denen es deshalb nicht folgen werde, oder ein solcher Ansatz sei unnötig, weil diese Regeln ohnehin immer angewandt würden.
  Ich habe so etwas überhaupt nicht versucht, aber solche Formulierungen hängen inzwischen oft am Ende der Antwort.
  Offenbar gibt es in den internen Richtlinien irgendeinen groben Teil, den es nicht sauber von meiner eigentlichen Frage trennen kann.

  • Ich nutze stop hook scripts, die bei jeder Codeänderung Tests erzwingen, aber seit 4.7 führt Claude die Skripte zwar aus und ignoriert die Regeln dennoch regelmäßig.
    Fragt man nach dem Grund, antwortet es, es habe gedacht, das sei nicht nötig.
  • Bei OpenAI sehe ich ebenfalls oft, dass Modelle auf ihre eigenen Aussagen antworten.
    Es wirkt fast wie ein einfacher Weg der Firmen, den Token churn zu erhöhen.
  • Ich sehe auch häufig, dass es selbst erzeugte Punkte in den Memory schreibt und sie später so wieder aufgreift, als kämen sie von mir.
    Dann entsteht eine selbstverstärkende Schleife: Das Modell behauptet etwas, speichert es als Erinnerung und baut später auf genau dieser Erinnerung weiter auf — manchmal sogar dann noch, wenn ich ausdrücklich sage, dass es damit aufhören soll.
  • Mich würden das Effort-Level und der konkrete Prompt interessieren.
    Das könnte nach einem Effekt von zu hohem reasoning effort riechen; mit etwas niedrigerer Denktiefe würde sich das möglicherweise bessern.
  • Ich lasse Claude oft sogar Commits und PRs übernehmen, aber letzte Woche habe ich mehrfach gesehen, wie es beim Committen eigenmächtig unnötige Zusatzarbeit eingebaut hat.
    Bei git add ist es zwar gescheitert, aber im Auto-Mode wäre das einmal fast einfach durchgerutscht.

• Dass der Standard-Reasoning-Effort von high auf medium gesenkt wurde, weil die Latenz so hoch war, dass die UI eingefroren wirkte, macht mich noch misstrauischer.
  Das heißt ja, man hat nicht die UI korrigiert, sondern zuerst die Standard-Intensität der Inferenz gesenkt — und dass man gleichzeitig die Berichte über Leistungsabfall ernsthaft untersucht habe, klingt dann schwer glaubhaft.

  • Das Team sagt, man habe beides getan.
    Die Ladezustände für Thinking wurden verbessert, ebenso die Anzeige der heruntergeladenen Token-Menge, also habe man auch an der UI mehrfach gearbeitet.
    Nach Evaluierungen und Dogfooding habe man den Standard-Effort trotzdem gesenkt, das sei aber eine falsche Entscheidung gewesen und inzwischen zurückgenommen worden.
    Man räumt ein, dass viele Leute nicht verstanden hätten, dass sie mit /effort die Intelligenz hochstellen können, und deshalb beim Default geblieben seien — das hätte man vorhersehen müssen.

• Dass idle Sessions von mehr als 1 Stunde ein Corner Case seien, passt überhaupt nicht zu meinem Nutzungsverhalten.
  Bei privater Arbeit lasse ich Claude Code oft 10- bis 15-minütige Aufgaben ausführen und verbringe davor viel Zeit damit, mit dem Modell den Plan mehrfach hin und her zu besprechen.
  Wenn die Ausführung startet, hole ich mir meist einen Kaffee oder arbeite mit Codex an einem anderen Projekt, sodass es sehr wahrscheinlich ist, dass mehr als 1 Stunde vergeht, bis ich zu Claude zurückkehre.

  • Das ist vermutlich nur aus Entwicklerperspektive ein Corner Case.
    Die eigenen Gewohnheiten mit dem Verhalten der gesamten Nutzerschaft zu verwechseln, ist eine klassische Falle in der Produktentwicklung.
  • Es klingt auch so, als hätte man bei einer derart großen Änderung genau diesen Edge Case nicht gründlich genug getestet, was Zweifel an der Testdisziplin aufwirft.

• Der Blackbox-Ansatz der großen Frontier Labs wird die Leute am Ende vertreiben.
  Wenn sie derart grundlegende Verhaltensweisen ändern, ohne vorher Bescheid zu sagen, und erst später Erklärungen liefern, werden Nutzer zwangsläufig zu selbst gehosteten Modellen abwandern.
  Auf einem Fundament, das ständig wackelt, kann man keine stabilen Pipelines, Workflows oder Produkte aufbauen.

• Es wirkt, als würden die zuständigen Leute für Claude Code bei Anthropic die Kommentare lesen; vor ein paar Tagen habe ich ein Video von theo t3.gg gesehen, in dem es darum ging, ob Claude dümmer geworden ist.
  Der Ton war rau und teils überzogen, aber gerade die Hinweise zu harness bloat fand ich ziemlich treffend.
  Jetzt sollte man neue Funktionen erst einmal zurückstellen und stattdessen Politur und Optimierung mit Nachdruck vorantreiben.
  Sonst werden viele nach leichteren und besser optimierten Alternativen suchen, und entscheidend ist, den Harness zu verbessern und den Token-Verbrauch zu senken.
  https://youtu.be/KFisvc-AMII?is=NskPZ21BAe6eyGTh

  • Ganz unabhängig von allem anderen hat mich schon allein der Test, CC aus dem Pro-Plan zu entfernen, ernsthaft über Alternativen nachdenken lassen.
    Ich war ohnehin immer wachsam gegenüber Vendor Lock-in, aber das war ein guter Warnschuss, und wahrscheinlich schaue ich mir als Erstes opencode+openrouter an.
  • Man darf niemals vergessen, wie theo bei GPT 5 erst massiv gehypt und das später wieder zurückgenommen hat.
    Zwischen einigen Content-Creatorn und OpenAI scheint im Hintergrund eindeutig etwas zu fließen, ob Geld oder Einfluss.
  • Ehrlich gesagt wirkt das fast wie etwas, das sich einfach mit git reset --hard beheben ließe.

• Das wirkt wie ein Fall von Funktionsdrang statt Fokus auf die Qualität des Kernprodukts.
  Ich denke oft, Anthropic könnte ein paar erfahrene Produktverantwortliche mehr gebrauchen; ein Blickwinkel wie in „Escaping the Build Trap“ täte offenbar gut.
  Nur weil man Features schnell hinzufügen kann, heißt das nicht, dass man sie auch hinzufügen sollte.
  Ich erwähne das Buch nicht, um irgendein banales Produktorganisationsgerede abzuladen; gutes Produktgespür ist eine andere Begabung als gutes Engineering, und genau daran scheint es Anthropic zuletzt zu fehlen.

  • Sie müssen mit der Nachfrage Schritt halten, aber offenbar fehlt es klar an Compute-Ressourcen.
    Möglicherweise hatten sie deshalb gar nicht viele Optionen: Ohne solche Maßnahmen wäre das System vielleicht kollabiert oder sie hätten keine neuen Kunden mehr aufnehmen können, und beides wäre schwer hinnehmbar gewesen.
  • An Talenten dürfte es nicht mangeln bei einer Firma, in der zeitweise rund 100 Entwickler 600.000 Dollar pro Jahr bekommen haben.
    Eher wirkt es so, als würde man die vibe-coding-Erzählung zu aggressiv pushen, weshalb manche Kandidaten Interviewanfragen inzwischen ablehnen.
  • Sie scheinen schon tief in der Komplexitätsfalle zu stecken.
    Die probabilistische Natur der Modelle ist das eine Problem, aber inzwischen wirkt es, als könnten sie selbst über ihre eigene Software nicht mehr sauber nachdenken.
    Es gibt zu viele Hebel und Stellschrauben, und möglicherweise versteht niemand mehr den gesamten Code vollständig.
    Noch schlimmer ist, dass Aussagen von Dario und anderen darauf hindeuten, dass die Führungsebene für diese Qualitätsbedenken kaum Sympathie hat.
    Unter der Vorstellung, dass SWEs ohnehin ersetzt werden, wirkt es so, als würden Forderungen nach Guard Rails für Werkzeuge ignoriert oder sogar aktiv unterdrückt, und insgesamt riecht Claude Code immer noch eher nach einem wissenschaftlichen Experiment als nach einem ausgereiften Produkt mit belastbaren Best Practices.