Wenn KI-Systeme plötzlich schlechter werden: Was Unternehmen aus der Claude-Code-Debatte wirklich lernen sollten

Viele Unternehmen behandeln LLMs noch immer wie stabile Software-Bausteine. Genau das ist gefährlich. Die aktuelle Debatte rund um Claude Code zeigt: Selbst sehr leistungsfähige Modelle können sich im Zeitverlauf spürbar – und still, ohne Ankündigung – verändern. Entscheidend ist deshalb nicht die Frage, welches Modell „gewinnt", sondern wie Unternehmen ihre KI-Systeme so aufsetzen, dass Qualität, Stabilität und Steuerbarkeit auch bei Modelländerungen erhalten bleiben.

Die jüngste Diskussion um Claude Code ist für viele Technologie-Teams ein Weckruf – und für manche schlicht eine Bestätigung dessen, was sie seit Wochen gefühlt haben.

Auslöser war eine öffentlich dokumentierte Analyse von Stella Laurenzo, Senior Director of AI bei AMD. Ihre GitHub-Analyse ist keine anekdotische Frustration, sondern harte Messdaten: 6.852 Sessions, 234.760 Tool-Calls und 17.871 Thinking-Blocks – ausgewertet über vier IREE/AMD-Compiler-Projekte von Ende Januar bis Anfang April 2026. [¹] Das Urteil: „Claude cannot be trusted to perform complex engineering tasks." [¹] Ihr gesamtes Senior-Engineering-Team hatte unabhängig voneinander dieselben Beobachtungen gemacht. Sie haben inzwischen den Anbieter gewechselt. [²]

Die Daten sind eindeutig: Die Anzahl der Code-Reads vor einem Edit fiel von durchschnittlich 6,6 auf 2,0. Der Anteil blinder Edits – also Änderungen an Dateien, die Claude vorher nicht gelesen hatte – stieg von 6,2 % auf 33,7 %. Stop-Hook-Violations, ein Indikator für vorzeitigen Abbruch und „Ownership Dodging", stiegen von null auf rund zehn pro Tag. [¹] Kurz: Jede dritte Code-Änderung erfolgte ohne vorheriges Lesen der betroffenen Datei.

Was tatsächlich passiert ist – und was Anthropic bestätigt hat

Hier wird die Einordnung wichtig, denn es gab nicht eine, sondern drei gleichzeitige Änderungen, die zusammen eine problematische Kombination ergaben:

1. Adaptive Thinking (ab 9. Februar 2026): Anthropic dokumentiert für Claude Opus 4.6 und Sonnet 4.6 den Einsatz von Adaptive Thinking. Das Modell entscheidet dabei dynamisch, wann und wie intensiv es „denkt" – statt wie bisher ein festes Token-Budget zugeteilt zu bekommen. [³] Der Aufwand kann über den effort-Parameter beeinflusst werden, der als weiches Steuerungssignal wirkt: Bei höherem Effort denkt das Modell tiefer, bei niedrigerem werden einfachere Anfragen schneller – und flacher – beantwortet. [⁴] Anthropic empfiehlt Adaptive Thinking offiziell als die bevorzugte Methode für Opus 4.6. [³]

2. Stille Absenkung des Standard-Efforts von „high" auf „medium" (ab 3. März 2026): Das ist die entscheidende Änderung, die im öffentlichen Diskurs häufig übersehen wird. Ohne breite Ankündigung wurde der Default-Effort in Claude Code von high auf medium gesenkt. [⁵] Wer also weiterhin die bisherige Reasoning-Tiefe erwartet hatte, arbeitete plötzlich mit einem System, das von Haus aus weniger tief denkt. Der Effekt: weniger Tool-Calls, weniger Code-Reads, oberflächlichere Lösungen – genau das, was Laurenzos Daten zeigen. [¹]

3. Thinking-Redaktion (vollständig ab 12. März 2026): Anthropic führte den Header redact-thinking-2026-02-12 ein, der Thinking-Inhalte aus der Benutzeroberfläche und den gespeicherten Logs ausblendet. Boris Cherny, der Schöpfer von Claude Code, bezeichnete dies als „rein kosmetische UI-Änderung", die das tatsächliche Reasoning nicht beeinflusse. [⁶] Laurenzo antizipierte diesen Einwand und entwickelte einen Workaround, um Reasoning-Tiefe unabhängig von der Darstellung zu messen – und zeigte, dass die Tiefe tatsächlich gesunken war, nicht nur die Sichtbarkeit davon. [¹]

Anthropic hat die Kernursache inzwischen teilweise bestätigt: Adaptive Thinking in Kombination mit einem gesenkten Default-Effort hat die Reasoning-Tiefe für Power-User spürbar reduziert. [⁷] Das ist keine böswillige Absicht – es ist eine Optimierung für den Durchschnittsnutzer auf Kosten komplexer Engineering-Workflows.

Wer die volle Reasoning-Tiefe zurückwill, kann mit /effort high oder /effort max im Terminal gegensteuern. [⁵] Wer die Thinking-Zusammenfassungen sehen möchte, aktiviert showThinkingSummaries: true in der settings.json. [⁵] Das sind echte Hebel – aber sie existieren nur, wenn man weiß, dass man sie braucht.

Die eigentliche Lehre ist größer als Claude Code

LLM-basierte Systeme sind keine statischen Produkte. Sie sind abhängig von Modellen, Modus-Einstellungen, Inferenzpfaden, Tooling, Prompt-Architektur – und Anbieterentscheidungen, die ohne Vorwarnung getroffen werden. Drei simultane Default-Änderungen, keine proaktive Kommunikation, und ein $200-Milliarden-Chiphersteller entdeckt das Problem durch Telemetrie-Auswertung von fast einer Viertelmillion Tool-Calls. [¹] Die klassische Denkweise „einmal gebaut = dauerhaft stabil" ist in der LLM-Welt strukturell falsch.

Genau deshalb halten wir eine Multi-Model-Strategie für zentral. Unternehmen sollten sich nicht in eine einzige Modelllogik einschließen lassen. Unterschiedliche Use Cases benötigen unterschiedliche Stärken: Manche profitieren von tieferem Reasoning, andere von Geschwindigkeit, Kostenkontrolle oder stabiler Tool-Nutzung. Ein modernes KI-Setup sollte so aufgebaut sein, dass Modelle austauschbar bleiben, Vergleiche möglich sind und ein Fallback auf alternative Modelle jederzeit realistisch ist.

Aus unserer Sicht gehören dazu mindestens fünf Dinge: erstens eine saubere Observability über Outputs, Fehlermuster und Qualitätsdrift – Laurenzos Analyse war nur möglich, weil ihr Team Logs strukturiert gesammelt hat; [¹] zweitens Regressionstests auf echten, geschäftsrelevanten Use Cases; drittens kontrollierte Rollouts statt unbemerkter Default-Änderungen; viertens eine Architektur, in der mehrere Modelle parallel betrieben und bewertet werden können; und fünftens die Bereitschaft, KI-Produkte als lebende Systeme zu managen – nicht als einmal implementierte Features.

Und genau deshalb braucht es keine weiteren KI-Tools – sondern Enterprise AI Management- und Orchestrierungsplattformen. Denn erst durch solche Plattformen wird die Entwicklung und der Betrieb von Dutzenden, oder gar Hunderten von KI-Anwendungen, Tausenden von KI-Assistenten und unzähligen KI-Agenten in einer Multi-LLM-Umgebung überhaupt erst verwaltbar. Der neuland.ai HUB ist genau dafür gebaut: Investitionsschutz, Sicherheit, Governance, Compliance, Rollen- & Rechteverwaltung, Zuverlässigkeit und Rechtskonformität – nicht als nachträgliche Add-ons, sondern by design. Nur so lässt sich das, was die AMD-Analyse schmerzhaft sichtbar gemacht hat, strukturell verhindern: dass ein stiller Default-Wechsel beim Anbieter unbemerkt durch die gesamte KI-Landschaft eines Unternehmens propagiert.

Meine persönliche Einschätzung

Ich halte die aktuelle Debatte für wichtig, weil sie ein Missverständnis offenlegt, das viele Unternehmen noch haben. Das Problem ist nicht, dass Anthropic „versagt" hat oder ein anderes Modell „gewonnen" hat. Das eigentliche Problem ist die Erwartung, dass Modellverhalten, Reasoning-Tiefe und Tool-Qualität dauerhaft konstant bleiben – und dass ein Anbieter breaking changes kommuniziert, bevor ein AMD-Team 234.760 Tool-Calls auswerten muss, um sie zu entdecken. [¹]

AWS senkt nicht still die Performance von EC2-Instanzen. Google Cloud drosselt nicht ohne Ankündigung Datenbank-Throughput. KI-Modell-Anbieter tun genau das – und „Wir verbessern unsere Modelle kontinuierlich" gilt bislang als ausreichende Rechtfertigung. [⁸]

Die richtige Konsequenz lautet daher nicht: „Wir setzen ab morgen nur noch auf Modell X." Die richtige Konsequenz lautet: Wir bauen unsere KI-Landschaft so, dass Modellwechsel, Qualitätsdrift und stille Default-Änderungen beherrschbar werden. Nur dann entsteht echte technologische Resilienz.

Quellen

[¹] Stella Laurenzo (AMD Senior Director, AI Group): GitHub Issue #42796 – „[MODEL] Claude Code is unusable for complex engineering tasks with the Feb updates", anthropics/claude-code, 2. April 2026. https://github.com/anthropics/claude-code/issues/42796

[²] The Register: „Claude Code has become dumber, lazier: AMD director", 6. April 2026. https://www.theregister.com/2026/04/06/anthropic_claude_code_dumber_lazier_amd_ai_director/

[³] Anthropic API-Dokumentation: Adaptive Thinking. https://platform.claude.com/docs/en/build-with-claude/adaptive-thinking

[⁴] Anthropic API-Dokumentation: Effort Parameter. https://platform.claude.com/docs/en/build-with-claude/effort

[⁵] Pasquale Pillitteri: „Claude Code Getting Worse? Two Settings 90% of Users Don't Know About", 12. April 2026. https://pasqualepillitteri.it/en/news/805/claude-code-effort-adaptive-thinking-guida (inkl. Bestätigung durch Boris Cherny/Anthropic)

[⁶] VentureBeat: „Is Anthropic 'nerfing' Claude? Users increasingly report performance degradation", 14. April 2026. https://venturebeat.com/technology/is-anthropic-nerfing-claude-users-increasingly-report-performance

[⁷] North Denver Tribune / Fact-Check: „What's up, Claude?", April 2026. https://northdenvertribune.com/technology/whats-up-claude/

[⁸] Eva Daily: „AMD's AI Director Says Claude 'Cannot Be Trusted' After Silent Performance Downgrade", April 2026. https://www.evadaily.com/article/amd-ai-director-claude-performance-downgrade-trust