Technischer Kontext
Ich habe das Post-mortem von Anthropic vom 23. April sorgfältig durchgelesen. Das Interessanteste daran ist nicht der Bug selbst, sondern wie eine scheinbar stabile KI-Integration durch mehrere kleine Entscheidungen auf einmal zusammenbrach. Wenn Sie KI-Automatisierung auf Basis von LLMs entwickeln, ist dies ein sehr bekanntes Szenario: Das Modell scheint dasselbe zu sein, aber das Produkt wird plötzlich dümmer, vergesslicher und unpräziser.
Anthropic beschrieb drei unabhängige Änderungen. Die erste wurde am 4. März vorgenommen: Der standardmäßige Denkaufwand von Claude Code wurde von hoch auf mittel gesenkt, um die Antworten zu beschleunigen. In internen Tests schien der Qualitätsverlust moderat, aber in der Praxis erhielten die Nutzer einen merklich schwächeren Code-Assistenten. Dies wurde erst am 7. April rückgängig gemacht.
Die zweite Änderung kam am 26. März. Das Team wollte den Reasoning-Cache nach einer Stunde Inaktivität leeren, aber ein Fehler führte dazu, dass er bei jeder nachfolgenden Interaktion in der Sitzung geleert wurde. Dies erweckte den Eindruck, dass Claude den Kontext vergisst, sich wiederholt und sich desorientiert verhält. Dieser Fehler bestand bis zum 10. April.
Die dritte Änderung erschien am 16. April, nach der Veröffentlichung von Opus 4.7. Um überflüssige Ausführlichkeit zu beseitigen und den Token-Verbrauch zu reduzieren, fügte Anthropic Einschränkungen im System-Prompt hinzu. Hier wurde es besonders problematisch: Die neue Anweisung, kombiniert mit anderen Prompt-Änderungen, verschlechterte die Code-Qualität mehrerer Versionen, einschließlich Sonnet 4.6, Opus 4.6 und Opus 4.7. Das Rollback erfolgte am 20. April.
Der entscheidende Punkt: Laut Anthropic waren das Basismodell und die Kern-API nicht fehlerhaft. Es war die darüber liegende Produktschicht. Ehrlich gesagt ist dies meine liebste und gleichzeitig frustrierendste Art von Vorfall, denn der Schuldige ist nicht ein großes Release, sondern die Summe aus „sicheren“ Änderungen an Parametern, der Prompt-Schicht und der Sitzungsverwaltung.
Was das für Unternehmen und Automatisierung bedeutet
Für Teams ist dies ein sehr ernüchterndes Signal: Die Leistungsabnahme eines LLM-Systems kommt oft nicht vom Modell, sondern von der umgebenden Infrastruktur. Wenn Ihre KI-Lösungsentwicklung auf System-Prompts, Caching, Routing und Latenz-Tuning basiert, müssen Sie das gesamte Orchester testen, nicht nur das Modell.
Wer gewinnt? Diejenigen mit gestaffelten Rollouts, aussagekräftigen Kohortenmetriken und schnellen Rollbacks. Wer verliert? Teams, die Prompts als „nicht Code“ betrachten und solche Änderungen mit geringer Ingenieursdisziplin veröffentlichen.
Ich betrachte die Prompt-Schicht schon lange als Teil der Architektur und nicht nur als eine schnell erstellte Textdatei. Im Nahornyi AI Lab lösen wir genau diese Probleme für Kunden: Wir gliedern die KI-Architektur in Schichten, etablieren Beobachtbarkeit und beseitigen Schwachstellen, die plötzlich die Qualität beeinträchtigen können.
Wenn Sie bereits feststellen, dass Ihr Assistent ohne ersichtlichen Grund mal klug und mal dumm ist, ist das normalerweise keine Magie oder „Modellermüdung“. Wir können Ihre Pipeline systematisch analysieren und eine KI-Automatisierung aufbauen, die auf technischen Garantien beruht, nicht auf Glück. Wenn Sie möchten, helfe ich Ihnen im Nahornyi AI Lab, schnell herauszufinden, wo Ihre Produktion undicht ist.