- Claude Code führte A/B-Tests ohne Zustimmung der Nutzer durch, wodurch sich das Verhalten des Plan Mode ohne Vorankündigung änderte und die Arbeitseffizienz sank
- Bei einem professionellen Tool für 200 $ im Monat ist es problematisch für Transparenz und Nutzerkontrolle, wenn sich Kernfunktionen ohne vorherige Ankündigung ändern
- Einer der Tests war eine aggressive Variante, die den Plan auf 40 Zeilen begrenzte, Kontextabschnitte verbot und anwies, statt Fließtext nur Dateipfade zu lassen
- Der Anthropic-Ingenieur, der den Test durchführte, erklärte, das Ziel sei die Reduzierung der Rate-Limit-Last gewesen, das Experiment sei jedoch beendet worden, da die ersten Ergebnisse keinen großen Effekt gezeigt hätten
- Es wird betont, dass für die Zuverlässigkeit von AI-Tools und eine verantwortungsvolle Einführung Nutzerkontrolle und transparentes Management von Experimenten unverzichtbar sind
Verschlechterte Nutzererfahrung durch A/B-Tests in Claude Code
- Als begeisterter Nutzer, dessen Arbeitsweise durch Claude Code grundlegend verändert wurde, schildert der Autor, dass sich sein Workflow in der vergangenen Woche verschlechtert habe
- Anthropic führt A/B-Tests in Claude Code durch, wodurch Nutzer-Workflows aktiv beeinträchtigt werden
- A/B-Tests an sich seien nicht falsch, und Anthropic wolle die Erfahrung wohl auch nicht absichtlich verschlechtern, aber das Testdesign ist entscheidend; problematisch sei, dass sich das wahrgenommene Verhalten einer Kernfunktion wie dem Plan Mode ohne Erklärung ändere
Forderung nach Transparenz bei einem Bezahl-Tool
- Da es sich um ein professionelles Arbeitstool für 200 $ pro Monat handelt, braucht es Transparenz über die Funktionsweise und Möglichkeiten zur Konfiguration
- Es sei schwer akzeptabel, wenn Kernfunktionen ohne Vorwarnung geändert werden oder Nutzer ohne Zustimmung in destruktive Tests aufgenommen werden
- Um AI-Tools verantwortungsvoll zu steuern, sind Transparenz und Konfigurierbarkeit zentral, und Nutzer müssen dabei unterstützt werden
- Täglich beschweren sich Ingenieure über Regressionen in Claude Code, wobei manche nicht einmal wissen, dass sie Teil eines A/B-Tests sind
Testinhalt und Belege
- Die erstellten Pläne kamen plötzlich nur noch als knappe Bullet-Listen ohne Kontext zurück
- Auf die Frage, warum Claude so schlechte Pläne schreibe, antwortete es, es folge einer bestimmten Systemanweisung, den Plan auf 40 Zeilen hart zu begrenzen, Kontextabschnitte zu verbieten und „Fließtext zu löschen und nur Dateipfade zu belassen“
- Zu den konkreten Methoden für den Nachweis erklärte der Autor, dass diese auf Hacker News Aufmerksamkeit erhalten hätten und er deshalb Details entfernt habe, damit andere es nicht nachmachen
- Dieses Vorgehen stehe im Widerspruch zu Transparenz und einem verantwortungsvollen Einsatz bzw. Betrieb von AI
Reaktionen auf Hacker News und die Kostenperspektive
- Ein Kommentar auf Hacker News wies darauf hin, dass Anthropic in jedem Schritt von Claude Code Abwägungen beim Durchsatz treffen müsse; würde alles maximal eingestellt, entstünden höhere Verluste bzw. geringere Gewinne pro Nutzer
- Es wurde die Sicht vertreten, dass 200 $/Monat in Wirklichkeit 400 $/Monat an Kosten verursachen könnten und dass es besser sein könne, per A/B-Test eine Baseline für einzelne Prozessschritte zu finden, statt willkürliche Grenzen festzulegen
Antwort eines Anthropic-Ingenieurs
- Ein Claude-Code-Ingenieur, der den Test durchgeführt hatte, antwortete direkt im Hacker-News-Thread
- Der Prompt für den Plan Mode habe sich seit den 3.x-Serienmodellen nicht wesentlich verändert, und 4.x-Modelle könnten mit deutlich weniger Anweisungen erfolgreich arbeiten
- Die Hypothese sei gewesen, dass kürzere Pläne bei ähnlichen Ergebnissen weniger Rate-Limit-Treffer verursachen könnten
- Es wurden mehrere Varianten getestet, und dieser Autor sowie Tausende andere Nutzer wurden der aggressivsten Variante mit einer Begrenzung auf 40 Zeilen zugewiesen
- Da die ersten Ergebnisse keinen großen Einfluss auf die Rate Limits zeigten, wurde das Experiment beendet
- Planung verfolge zwei Ziele: dem Modell zu helfen, die richtige Richtung beizubehalten, und dem Nutzer Vertrauen in die nächsten Schritte des Modells zu geben; beides sei ein mehrdeutiger, komplexer und nicht trivialer Bereich
Fazit: Verantwortung für Experimente mit AI-Tools und Nutzervertrauen
- Der Autor zeigt am Fall Claude Code, dass Experimente mit AI-Tools direkte Auswirkungen auf die Nutzererfahrung haben können
- Er betont, dass transparentes Experiment-Management und garantierte Wahlfreiheit für Nutzer essenziell sind, um das Vertrauen in professionelle Tools zu erhalten
- Auch wenn sich AI-Systeme weiterentwickeln, müsse eine vom Menschen kontrollierbare Struktur erhalten bleiben
1 Kommentare
Hacker-News-Kommentare
Ich halte es für übertrieben, A/B-Tests als „stille Experimente an Nutzern“ zu bezeichnen und dabei Meta zu erwähnen
A/B-Tests an sich sind nicht böse, entscheidend ist das Testdesign
Experimente, die die Leistung von LLMs deutlich verschlechtern, sind allerdings nicht akzeptabel
Es gibt bereits ernste Probleme bei Reproduzierbarkeit und Zuverlässigkeit, und Unternehmen wälzen diese Last auf die Nutzer ab
Wenn Firmen in so einer Lage heimlich Experimente durchführen, bricht die Glaubwürdigkeit der Forschung komplett zusammen
Bei Claude Code könnten negative Ergebnisse wegen A/B-Tests mit dem Hinweis abgetan werden, man sei vielleicht in der Experimentgruppe gewesen
Gerade in sensiblen Bereichen wie Recruiting würden solche Experimente schwere ethische und rechtliche Probleme verursachen
Plötzlich ändern sich UI oder Funktionen, und wenn man Kollegen fragt, weiß niemand Bescheid
Meistens werden solche Änderungen sogar schlechter und werden trotzdem im Namen „objektiver Daten“ durchgedrückt
Selbst etwas Banales wie die Farbe eines Buttons ist letztlich ein Experiment, und die meisten Nutzer werden nicht einmal darüber informiert, dass sie Teil eines Experiments sind
Das war ein Test, den ich selbst durchgeführt habe
Ich habe geprüft, ob sich der plan-mode-Prompt, der seit der 3.x-Serie gepflegt wurde, für das 4.x-Modell vereinfachen lässt und trotzdem ähnliche Ergebnisse liefert
Ich bin davon ausgegangen, dass ein kürzerer Plan seltener zu rate-limit führt, aber da es kaum Unterschiede gab, habe ich den Versuch beendet
Der Plan-Modus dient zwei Zwecken: dem Modell eine Richtung zu geben und den Nutzern zu helfen, dem Ergebnis zu vertrauen
Die Kosten entstehen nicht durch den Plantext, sondern in der Erkundungsphase (subagent)
Der Plan-Modus startet immer drei Erkundungsagenten und berücksichtigt den Sitzungszustand nicht
Selbst wenn Dateien bereits geladen sind, werden sie erneut gelesen, was zu Token-Verschwendung führt
Wenn die Sitzung bereits warm ist, wäre eine bedingte Logik zum Überspringen der Erkundung effektiver
Schon ein einziges unerwartetes Verhalten kann mich für Tage ausbremsen
Solche Auswirkungen nicht zu berücksichtigen, ist verantwortungslos und aggressiv
Es ist sehr unangenehm, dass seltsames Verhalten der letzten Zeit auf Experimente zurückgehen könnte
Statt eines Beta-Kanals sollte es ein ausdrückliches Opt-in geben
Ich persönlich halte die narrative Klarheit des Plans für wichtiger als die Zeilenzahl
Es braucht einen Plan, aus dem verständlich wird, was getan wird und warum
LLMs sind grammatikalisch perfekt, mischen aber Halluzinationen ein und verwirren damit Nutzer
Für Boilerplate-Arbeiten oder schnelles Verknüpfen von Ideen sind sie trotzdem nützlich
Um sie richtig zu nutzen, ist allerdings Grundlagenwissen unverzichtbar
Der Grund, warum der Text abrupt endet, ist, dass der Autor den Teil über das Dekompilieren des Claude-Code-Binaries gelöscht hat, weil darin womöglich ein ToS-Verstoß lag
Die zugehörige Diskussion findet sich in diesem Kommentar
Ich habe dazu zwei Gedanken
Denn datengetriebene Verbesserungen durch groß angelegte A/B-Tests wären dann nicht möglich
Es kann unvorhersehbare Änderungen geben, etwa wie beim „after midnight“-Easter-Egg in man-db
Außerdem gibt es viele Abhängigkeiten, und kaum jemand prüft den Code tatsächlich
Es können auch Monetarisierungsexperimente (enshittification) sein — YouTube ist ein typisches Beispiel
Mit A/B-Tests an sich habe ich kein Problem, aber plan mode gefällt mir nicht
In den meisten Fällen sind die Ergebnisse schlecht
Die Informationsbewahrung über compaction hinweg ist allerdings gut
Wenn man den Gesprächsverlauf in einer Markdown-Datei festhält und diese bei jeder compaction referenzieren lässt, erhält man deutlich bessere Ergebnisse
plan mode ist deutlich effizienter, deshalb nutze ich ihn vor fast jeder Aufgabe
Der Vorteil ist, dass man den Plan prüfen und diskutieren kann, bevor das Modell ihn ausführt
Im aktuellen plan mode ist es gut, dass nach Abschluss der Kontext zurückgesetzt wird und sich so sauber der nächste Plan erstellen lässt
Schade, dass im Blog die Details zur Dekompilierung wegen ToS-Problemen entfernt wurden
Claude soll einer Systemanweisung gefolgt sein, die lautete: „Begrenze den Plan auf 40 Zeilen, verbiete Kontextabschnitte und lösche Prosa“
Es wäre gut, wenn man solche Einstellungen direkt sehen und anpassen könnte
Professionelle Werkzeuge sollten Zuverlässigkeit und Reproduzierbarkeit bieten, aber LLMs tun das nicht
A/B-Tests sind nur ein weiterer Beleg dafür
Dasselbe Problem bestünde auch, wenn Photoshop den Farbton leicht verändert oder Word den Stil von Überschriften anpasst
Das eigentliche Problem sind A/B-Tests ohne Vorwarnung
Quotenlimits und Modellqualität sind instabil, und vor der Veröffentlichung neuer Modelle gibt es Phasen, in denen die vorherigen Modelle kaputtgehen
Auch dieses Experiment wirkt eher wie ein Kostensenkungstest als wie eine Verbesserung der Nutzererfahrung
Ein Business-Tool braucht Konsistenz und Zuverlässigkeit
Profis sollten die Stärken und Schwächen ihrer Werkzeuge verstehen und sie angemessen einsetzen
LLM-Ausgaben blind zu übernehmen ist unprofessionell, aber das heißt nicht, dass Profis keine LLMs verwenden können
Mit ausreichender Evaluierung und Prompt-Steuerung kann man Systeme ziemlich deterministisch machen
Wenn selbst instabile Modelle im Finanzsektor weiterhin betrieben werden, ist Unvorhersagbarkeit offenbar keine absolute Hürde
Ich überprüfe die Ausgaben des Modells wie bei einem Code-Review durch Kollegen
Solche Situationen werden schon lange Vendor Lock-in genannt
Wenn man von einem bestimmten Tool abhängt, kann man nicht mehr arbeiten, sobald es sich verändert oder verschwindet
Ich bin von CC zu opencode gewechselt
CC war mir zu geschlossen, und die Prompts waren zu meinungsstark (opinionated)
Außerdem konnte ich den Pfad für die Websuche nicht steuern
Ich habe mich jetzt für Open Source entschieden, weil ich es nur als Hobby nutze, beruflich hätte ich das vielleicht anders bewertet
Für kleine Projekte war es brauchbar, mehr nicht
Falls du ein gutes Setup hast, würde ich mich freuen, wenn du es teilst