Die Gegenreaktion auf GPT-5 war heftig, und dafür gibt es viele Gründe. Eine Sache wird uns dabei aber klar: Die Menschen wirklich mochten die Gedächtnisfunktion von ChatGPT.
Zeit für ein kurzes Geständnis: Wir nutzen sie eigentlich nicht. Warum? Weil wir ihr nicht wirklich vertrauen … Sie wirkte nie besonders zuverlässig, und obwohl sie besser geworden ist, fühlte sie sich eher wie ein Gimmick als tatsächlich nützlich an (siehe meinen Artikel über kontinuierliches Lernen für eine Erklärung).
Google und Anthropic ziehen daraus Konsequenzen und haben gerade beide ihre eigenen Vorversionen eines Gedächtnisses veröffentlicht: Google macht Gemini persönlicher, indem es aus deinen früheren Chats lernt (standardmäßig aktiviert), während Anthropic eine On-Demand-Suche in früheren Claude-Unterhaltungen eingeführt hat, die du ausdrücklich anfordern musst.
Das ist ein nützlicher Kontrast (standardmäßige Personalisierung gegenüber explizitem Abruf) mit klaren Auswirkungen auf Teams, die zwischen Komfort und Datenschutz abwägen.
So funktionieren die beiden Systeme:
- Geminis „Persönlicher Kontext“. Wenn die Funktion aktiviert ist, merkt sich Gemini wichtige Details und Präferenzen aus früheren Chats, um Antworten anzupassen. Sie ist standardmäßig aktiviert und wird zunächst für Gemini 2.5 Pro in ausgewählten Ländern, mit einem Schalter in den Einstellungen, eingeführt.
- Claudes Gedächtnis. Anthropics Version „Chats suchen und referenzieren“ (wird für Max, Team und Enterprise eingeführt) ruft nur dann relevante frühere Unterhaltungen ab, wenn du darum bittest (kein dauerhaftes Profil) – im Web sowie auf Desktop und Mobilgeräten. Der Schalter befindet sich unter Einstellungen → Profil.
Beispiele aus der Praxis:
- Frag Gemini: „Kannst du mir ein paar neue Vide Ideen geben, ähnlich wie bei der Serie über die japanische Kultur, die wir besprochen haben?“ Gemini erinnert sich an deine Chats und schlägt Anschlussfragen vor.
- Frag Claude: „Setze die Überarbeitung des Dashboards fort, die wir vor dem Urlaub unterbrochen haben.“ Claude durchsucht daraufhin frühere relevante Chats, fasst sie zusammen und macht weiter.
Upgrade auf Sonnet 4
Anthropic hat seinem Modell Claude Sonnet 4 gerade ein massives Upgrade spendiert: ein Kontextfenster mit 1 Million Tokens, über das Gemini schon seit einiger Zeit verfügt. Zum Vergleich: Das reicht aus, um eine gesamte Codebasis mit mehr als 75.000 Codezeilen in einem einzigen Prompt zu lesen.
Abgesehen vom Offensichtlichen: Warum sind Gedächtnis und lange Kontextfenster wichtig?
Weil sie die Zuverlässigkeit in der Praxis beeinflussen. Erinnerst du dich an jene Studie des KI-Forschungslabors METR, die zeigte, dass Entwickler zwar dachten , KI mache sie um 20 % schneller, sie tatsächlich aber um 19 % langsamer?
wurden? Nun haben METR-Forscher eine weitere beunruhigende Diskrepanz aufgedeckt , die den Grund dafür erklärt. In dem Bericht mit dem Titel „Algorithmische vs. ganzheitliche Bewertung“ setzten die Forscher einen autonomen KI-Agenten ein, der von Claude 3.7 Sonnet angetrieben wurde (bezeichnenderweise eine weniger leistungsfähige Version als das führende Claude 4 Sonnet), und beauftragten ihn mit der Erledigung von 18 praxisnahen Softwareentwicklungsaufgaben aus großen, komplexen Open-Source-Repositories. Anschließend bewerteten sie die Arbeit der KI auf zwei Arten.
Zunächst verwendeten sie eine algorithmische Bewertung, den Standard bei den meisten KI-Benchmarks. Sie führten einfach die automatisierten Tests aus, die der ursprüngliche menschliche Entwickler für die Aufgabe geschrieben hatte. Nach diesem Maßstab wirkte der KI-Agent mäßig erfolgreich: In 38 % der Fälle bestand er alle Tests. Wäre dies ein Benchmark wie der beliebte SWE-Bench, wäre das ein respektables Ergebnis.
Dann folgte die zweite Bewertung: eine ganzheitliche Beurteilung. Ein menschlicher Experte prüfte den Code der KI manuell, um festzustellen, ob er tatsächlich nutzbar war – ob er in das reale Projekt integriert werden konnte. Die Ergebnisse waren vernichtend. Kein einziger der Beiträge der KI war ohne weitere Änderungen integrierbar.
Selbst in den 38 % der Fälle, in denen der Code der KI „funktional korrekt“ war und alle Tests bestand, war er immer noch ein einziges Chaos. Die Forscher schätzten, dass ein erfahrener menschlicher Entwickler durchschnittlich 26 Minuten benötigen würde, um die „erfolgreiche“ Arbeit der KI zu reparieren. Diese Bereinigungszeit entsprach etwa einem Drittel der Gesamtzeit, die ein Mensch gebraucht hätte, um die gesamte Aufgabe von Grund auf zu erledigen.
Allerdings sind 33 % mehr Produktivität natürlich trotzdem großartig. Aber ist das Aufräumen von KI-Murks wirklich befriedigende Arbeit? Wir denken oft darüber nach, wenn wir KI testen, um uns beim Schreiben unserer Artikel zu helfen. Manchmal verbringen wir mehr Zeit damit, Dinge neu zu formatieren und überall erneut Links zu setzen, sodass daraus gewissermaßen die Einstiegsarbeit wird, die gerade automatisiert wird. Warum also erledige ich als sogenannter „Wissensarbeiter“ Aufgaben, die eine KI standardmäßig beherrschen sollte? Um Sam Altman zu zitieren: Ist das ein „Skill-Problem“?
Die „weichere“ Seite des Scheiterns
Also: Woran scheiterte die KI? Nicht an der Kernlogik, die durch die automatisierten Tests überprüft werden konnte. Sie scheiterte an all den entscheidenden, „weicheren“ Aspekten guter Softwareentwicklung, die ein ganzheitliches Projektverständnis erfordern. Die KI erzeugte durchgehend Code mit:
- Unzureichender Testabdeckung: Sie schrieb nicht genügend eigene Tests, um sicherzustellen, dass ihr neuer Code robust war.
- Fehlender oder fehlerhafter Dokumentation: Sie erklärte nicht, was der Code tat – eine schwere Sünde in gemeinschaftlich entwickelten Projekten.
- Verstößen gegen Linting und Formatierung: Der Code hielt sich nicht an den etablierten Styleguide des Projekts.
- Mangelhafter Codequalität: Der Code war häufig ausschweifend, fragil oder für Menschen schwer zu warten.
Jeder einzelne Versuch der KI wies mindestens drei dieser fünf Fehlerarten auf. Es war, als würde man einen brillanten Architekten einstellen, der einen statisch einwandfreien Raum entwerfen kann, aber Tür, Fenster und Steckdosen vergisst und die Baupläne anschließend auf einer fleckigen Serviette liegen lässt.
Diese neue Studie liefert die definitive Erklärung für das Paradox der Entwicklerproduktivität. Entwickler fühlen sich schneller, weil die KI das Kernproblem übernimmt – oft ein mühsames logisches Rätsel im Zentrum einer Aufgabe. Letztlich sind sie aber langsamer , weil sie enorm viel Zeit damit verbringen müssen, das Chaos zu beseitigen und all die kontextbezogenen Elemente zu korrigieren, die die KI ignoriert hat. Die KI gewinnt die Schlacht, aber verliert den Krieg.
Aktuelle KI-Coding-Benchmarks ignorieren diesen zusätzlichen Zeitaufwand. Das erklärt möglicherweise, warum Entwickler mit KI paradoxerweise langsamer sind, obwohl sie sich produktiver fühlen.
Ach ja, erinnerst du dich an METRs andere Studie , die gemessen hat, wie gut KI lange Aufgaben erledigen kann, und gezeigt hat, dass sich die Dauer dieser Aufgaben jeweils verdoppelt? Auch diese Studie basiert auf Testfällen und nicht auf einer Umsetzung in der realen Welt … wie „vollständig“ diese Aufgaben im echten Leben tatsächlich sind, ist also noch offen.
Hier kommen lange Kontextfenster und Gedächtnis ins Spiel
Die METR-Studie beweist, dass KI scheitert, wenn sie nicht das ganze Bild sehen kann. Funktionen wie ein Fenster mit 1 Million Tokens ermöglichen es einer KI, die gesamte Codebasis auf einmal zu lesen und ihre Struktur und Standards zu verstehen. Das Gedächtnis hilft ihr, sich an frühere Anweisungen und Projektziele zu erinnern (und hoffentlich werden diese Fähigkeiten NOCH besser). Genau das kann helfen, das „Mitte-zu-Mitte“-Problem der KI zu lösen (die Tatsache, dass wir oft damit beschäftigt sind, KI-Ausgaben zu überprüfen – beziehungsweise zu reparieren –, statt sie Aufgaben vollständig erledigen zu lassen).
In diesem Fall könnten ein besseres Gedächtnis und längere Kontextfenster genau das sein, was nötig ist, um die Lücke zwischen einer KI, die Tests besteht, und einer KI, die tatsächlich nutzbaren Code schreibt, zu schließen.
Bedenke: Als die Agenten von METR keinen integrierbaren Code erzeugten, scheiterten sie nicht daran, dass sie das algorithmische Kernproblem nicht lösen konnten. Sie scheiterten, weil ihnen der umfassendere Kontext darüber fehlte, was Code in diesem speziellen Repository produktionsreif macht. Sie übersahen Dokumentationsstandards, Testkonventionen, Erwartungen an die Codequalität und Formatierungsanforderungen, die jeder erfahrene Entwickler, der an diesem Projekt arbeitet, aus dem Gedächtnis kennen würde.
Aktuelle KI-Tools arbeiten mit einem engen Fenster des unmittelbaren Kontexts und konzentrieren sich ausschließlich auf die funktionalen Anforderungen, während sie die Dutzenden impliziten Standards und Praktiken ignorieren, die Code tatsächlich integrierbar machen. Mit besseren Gedächtnissystemen, die projektspezifische Coding-Standards, früheres Feedback zur Codequalität und das gesammelte Wissen darüber abrufen können, was in einer bestimmten Codebasis als „gut“ gilt, könnte die KI beginnen, jene 26 Minuten an Nacharbeit zu vermeiden, die derzeit selbst „erfolgreiche“ KI-Codebeiträge unbrauchbar machen … und möglicherweise die Lücke zwischen dem Gefühl, produktiv zu sein, und dem tatsächlichen Produktivsein schließen. Vom Vibe-Coding … zum Programmieren.
Anmerkung der Redaktion: Dieser Inhalt erschien ursprünglich in unserer Schwesterpublikation The Neuron. Mehr von The Neuron kannst du hier für den Newsletter anmelden.