Ich sitze hier seit einer Stunde vor dem VS-Code-Blogpost vom 23. September und lese den Absatz über die Ablation zum dritten Mal. Nicht weil ich was nicht verstehe — sondern weil ich’s nicht glauben will. 26 Prozentpunkte. Das ist keine Nebenwirkung, das ist fast die halbe Story, die im ersten Moment ganz anders verkauft wurde.

Nerd-Alarm: Wenn Sie schon mal A/B-Tests für irgendein Feature gefahren haben, kennen Sie das Gefühl. Die Zahl sieht gut aus. Alle freuen sich. Und dann findet irgendwer im Team einen Client-Bug, der die ganze Baseline verzerrt hat — und plötzlich ist die „Verbesserung“ gar keine, sondern die Korrektur eines Messfehlers, den man selbst eingebaut hat. Genau das ist hier passiert. Nur eben bei einem der meistgenutzten Code-Editoren der Welt.

Was GitHub Copilot in VS Code jetzt technisch macht

Kurzer Rückblick, damit wir alle auf demselben Stand sind: In VS Code gab’s bisher grob drei getrennte Inline-Vorschlagsarten. Ghost Text (die grauen Textvorschläge direkt am Cursor, während Sie tippen), Next Edit Suggestions — kurz NES — für Änderungen in der Nähe, und Long-Distance-Edits für Vorschläge, die weiter weg im Code liegen. Drei Systeme, drei Modelle, drei Sets an Heuristiken, wann was angezeigt wird.

Seit dem 23. September laufen diese drei für bezahlte Copilot-Nutzer in VS Code laut GitHub in einem unified 3-in-1-Modell. Ein Modell entscheidet, was, wo und wie angezeigt wird — Ghost Text, Next-Edit, Long-Distance, alles aus einer Hand. Im Blogpost Part Two beschreibt das Team, wie sie diesen Merge technisch hingekriegt haben — und was dabei schiefgelaufen ist. Letzteres ist der eigentlich spannende Teil, aber dazu komm ich gleich.

Die Kurzfassung der Ausgangslage: Ghost Text ist reaktiv und leise, NES ist proaktiver und lauter (kleine Diff-Vorschau, Tab zum Annehmen). Wenn beide Systeme getrennt laufen, kann es zu Konflikten kommen — beide wollen an derselben Stelle im Code was vorschlagen, und der Editor muss irgendwie entscheiden, wer gewinnt. Ein unified Modell soll genau das auflösen, weil es von Anfang an „weiß“, dass es für alle drei Modi verantwortlich ist.

Die Online-Flight-Zahlen: minus 10,1 Prozent klingt nach Sieg

GitHub hat das Ganze in einem Online-Flight getestet — also mit echten Nutzenden, nicht nur offline an historischen Daten. Ergebnis laut Blogpost: Die Dismissal-Rate sank um 10,1 Prozent gegenüber der alten 2-in-1-plus-Completions-Baseline. Dismissal heißt hier: Wie oft wird ein Vorschlag weggeklickt, ignoriert oder aktiv abgelehnt, statt angenommen zu werden. Weniger Dismissals gilt als gutes Zeichen — die Vorschläge treffen offenbar öfter das, was Entwicklerinnen und Entwickler tatsächlich wollen.

Gleichzeitig meldet GitHub: keine signifikanten Regressionen bei den Key Metrics. Klingt nach einem klaren Win, oder? Vorschläge werden seltener ignoriert, sonst bleibt alles stabil — Bilderbuch-Rollout.

Aber dann kommt der Satz, der mich stutzig gemacht hat: Der Anteil von Ghost Text am Cursor ist im selben Zeitraum um 13 Prozent gesunken. Moment. Wenn weniger Ghost Text angezeigt wird, aber gleichzeitig weniger Vorschläge insgesamt abgelehnt werden — heißt das nicht einfach, dass insgesamt weniger vorgeschlagen wird? Weniger Angebot, weniger Ablehnung, das wäre trivial und kein Modell-Erfolg, sondern reine Mengenreduktion. Genau an dieser Stelle wird’s interessant, und genau hier hat GitHub selbst nachgebohrt.

Der Bug, der die eigene Baseline verzerrt hat

Die kurze Version: Es gab einen alten Client-Pfad in VS Code, der ignoriertes Ghost Text nach einer Cursor-Bewegung als NES-Vorschlag wieder auftauchen ließ. Sie tippen was, Ghost Text erscheint, Sie ignorieren es (bewusst oder unbewusst, weil Sie einfach weitertippen), der Cursor bewegt sich — und der gleiche, bereits abgelehnte Vorschlag taucht als vermeintlich „neue“ Next-Edit-Suggestion wieder auf. Sie lehnen ihn wieder ab. Der Zähler für Dismissals tickt nochmal hoch. Für denselben Vorschlag. Zweimal gezählt, weil der Client ihn zweimal präsentiert hat.

Das ist im Ernst genau die Art von Fehler, die in Metriken furchtbar unauffällig aussieht — weil sie ja „echte“ Nutzerinteraktionen produziert. Niemand klickt hier falsch. Der Editor zeigt einfach denselben Kram doppelt.

GitHub schätzt selbst, dass dieser Bug für 7 bis 8 Prozent Dismissal-Inflation verantwortlich war. Sieben bis acht Prozentpunkte, die in der alten Baseline drinsteckten, aber nichts mit echter Nutzerzufriedenheit zu tun hatten — sondern mit einem Editor, der sich selbst im Kreis dreht.

Um das Ganze zu quantifizieren, hat das Team eine A/B-Ablation gefahren, gesteuert über ein Flag namens nesMimicGhostTextBehavior. Die Logik: Einmal NES so laufen lassen, dass sie sich wie der alte, buggy Client verhält (Ghost Text nach Ignorieren erneut als NES zeigen), einmal mit dem Fix. Das Ergebnis dieser Ablation ist für mich der eigentliche Knackpunkt des ganzen Posts:

Mit dem buggy Verhalten simuliert: Dismissal-Rate plus 15,9 Prozent.
Mit dem Fix: Dismissal-Rate minus 10,1 Prozent — also exakt die Zahl aus dem Online-Flight-Ergebnis oben.

Das ist eine Differenz von 26 Prozentpunkten zwischen „Bug drin“ und „Bug raus“. 26 Prozentpunkte, nur durch einen einzigen Client-seitigen Anzeigefehler. Nicht durch ein neues Modell, nicht durch bessere Prompts, nicht durch mehr Trainingsdaten — durch einen Pfad im Editor-Code, der zweimal gezeigt hat, was eigentlich nur einmal hätte gezeigt werden sollen.

Warum das die eigentliche Geschichte ist — nicht das Badge

Hier wird’s für mich als jemand, der beruflich (und privat, siehe mein halb kaputtes Smart-Home-Setup im Keller) ständig mit Metriken zu tun hat, richtig lehrreich. Die Presseüberschrift zu diesem Release wäre leicht gewesen: „Copilot 3-in-1 gestartet, Dismissal-Rate runter, alles besser.“ Badge dran, Haken gesetzt, nächstes Feature.

Aber was GitHub hier eigentlich zeigt — und dafür muss man den Blogpost ehrlich loben, weil sie es selbst offenlegen — ist: Ohne die Ablation über nesMimicGhostTextBehavior hätte niemand gewusst, wie viel von der ursprünglichen Verbesserung echt war und wie viel Bug-Korrektur. Das ist der Unterschied zwischen „shipped“ und „UX freigegeben“. Shipped heißt: Es läuft, die Nutzenden sehen ein neues Feature, die Metrik zeigt in die richtige Richtung. UX freigegeben würde heißen: Wir wissen genau, warum die Metrik in die richtige Richtung zeigt, und wir können die Ursache isolieren.

Spoiler: Die meisten Teams machen den zweiten Schritt nicht, weil er teuer ist. Man braucht ein Flag, eine zweite Kohorte, eine Ablationsstudie — Aufwand, den viele Produktteams unter Zeitdruck einfach nicht einplanen. GitHub hat’s hier offenbar gemacht (oder zumindest so dargestellt, und das ist wichtig: Das sind erstmal Angaben von GitHub selbst, keine unabhängig verifizierten Zahlen), und dadurch kam raus: Ein erheblicher Teil der ursprünglich gefeierten Verbesserung war Artefakt, nicht Fortschritt.

Klingt einfach, ist es aber nicht: Metriken, die auf User-Interaktion basieren, sind fragil gegenüber Client-Bugs, die man selbst nicht auf dem Schirm hat. Eine Dismissal-Rate ist letztlich nur so gut wie die Zähllogik dahinter. Wenn der Client denselben abgelehnten Vorschlag zweimal als „neuen“ Vorschlag präsentiert, zählt die Metrik zwei Ablehnungen — obwohl es nutzerseitig nur eine gab. Das ist kein Modellproblem. Das ist ein Rendering- beziehungsweise State-Management-Problem im Editor selbst.

Ghost-Text-Anteil runter, Dismissal runter — passt das zusammen?

Zurück zur Frage von oben: Wenn der Ghost-Text-Anteil am Cursor um 13 Prozent sinkt, heißt das automatisch weniger Dismissals, weil einfach weniger angezeigt wird? Teilweise ja — aber laut GitHub eben nicht vollständig, und genau deshalb war die Ablation nötig. Die Idee des unified Modells ist ja gerade, dass es lernt, wann Ghost Text die bessere Wahl ist und wann NES oder Long-Distance-Edits sinnvoller sind. Sinkt der Ghost-Text-Anteil, könnte das heißen: Das Modell verschiebt Vorschläge in Modi, die besser zur jeweiligen Situation passen — also weniger „blindes“ Ghost Text bei jedem Tastenanschlag, dafür gezielter NES, wenn eine echte Bearbeitung sinnvoller ist.

Das wäre die positive Lesart. Ich will nicht so tun, als sei das per se unplausibel — ein Modell, das die drei Vorschlagsarten gemeinsam sieht, kann in der Theorie besser entscheiden als drei getrennte Systeme, die sich gegenseitig ins Gehege kommen. Aber: Genau weil dieser Effekt plausibel klingt, hätte man ihn ohne die Ablation leicht mit dem Bug-Effekt verwechseln können. Zwei Ursachen, ein Symptom — klassische Verwechslungsgefahr in der Datenanalyse.

GitHub selbst schreibt (sinngemäß, als Vendor-Claim eben), dass nach dem Fix keine signifikanten Regressionen bei den übrigen Metriken aufgetreten seien. Das ist eine gute Nachricht für alle, die im Alltag mit Copilot arbeiten — heißt aber auch: Die eigentliche „Verbesserung“ durch das neue Modell ist vermutlich kleiner als die ursprünglich verkündeten minus 10,1 Prozent suggerieren, weil ein Teil dieser Zahl schon vorher durch den Bug-Fix zustande gekommen wäre, unabhängig vom neuen Modell.

Um ganz ehrlich zu sein: Der Blogpost lässt an dieser Stelle ein bisschen offen, wie viel von den minus 10,1 Prozent reiner Modell-Verdienst ist und wie viel einfach „Bug ist weg“. Die Ablationsstudie zeigt ja gerade: Mit Bug-Simulation plus 15,9 Prozent, ohne Bug minus 10,1 Prozent — das ist die Differenz zwischen den beiden Zuständen im selben (neuen) System. Ob das neue 3-in-1-Modell an sich, unabhängig vom Bug, überhaupt schon eine Verbesserung gegenüber der alten getrennten Architektur bringt, oder ob die minus 10,1 Prozent komplett durch den Fix erklärt werden — das würde eine dritte Vergleichsgruppe brauchen: altes System, alter Bug, neues System, kein Bug, und eben altes System mit Fix. Diese dreiseitige Aufteilung liefert der Post so nicht explizit.

61 Milliarden Requests und die Frage nach der Relevanz von Prozentpunkten

Copilot: Mechanische Tastatur unter Schreibtischlampe — Symbolbild Detail (Symbolbild)

Kurzer Blick auf Part One vom 16. September, weil die Zahl dort die ganze Diskussion in Perspektive rückt: GitHub berichtet von mehr als 61 Milliarden erfolgreichen Model Requests in 90 Tagen für die Inline-Suggestion-Systeme in VS Code. 61 Milliarden. In drei Monaten. Bei einer Zahl dieser Größenordnung ist jeder Prozentpunkt bei der Dismissal-Rate keine akademische Fußnote — das sind potenziell Hunderte Millionen einzelner Interaktionen, die sich verschieben.

Das erklärt auch, warum GitHub sich die Mühe mit der Ablation gemacht hat. Bei so einem Volumen kann man sich keine 7 bis 8 Prozent „Fake“-Dismissals in der Berichterstattung leisten, ohne dass irgendwann jemand — intern oder extern — die Zahlen hinterfragt. Und genau das ist ja passiert: Jemand im Team hat gefragt „Moment, warum sinkt Ghost Text um 13 Prozent, aber die Gesamt-Dismissal-Rate sinkt nicht proportional mehr?“ — und ist dabei auf den Bug gestoßen.

Ich finde diesen Teil der Geschichte fast sympathischer als das eigentliche Feature-Release. Ein Team, das seinem eigenen Erfolg misstraut genug, um nochmal genau nachzurechnen, warum die Zahl so gut aussieht — das ist die Art von Skepsis, die man sich in der Softwarebranche generell öfter wünschen würde. Viele Firmen (nicht nur bei Copilot, das ist ein branchenübergreifendes Muster) würden bei einer Zahl wie minus 10,1 Prozent einfach die Pressemitteilung rausschicken und weiterziehen.

Was das für Sie als Copilot-Nutzerin oder -Nutzer praktisch heißt

Wenn Sie VS Code mit einem bezahlten Copilot-Abo nutzen, läuft die 3-in-1-Vereinigung für Sie mittlerweile im Hintergrund — vorausgesetzt Sie sind auf einer aktuellen Version. Sie werden vermutlich nicht bewusst merken, „aha, jetzt läuft ein unified Modell“, weil sich an der Oberfläche wenig ändert: Ghost Text sieht aus wie Ghost Text, NES-Vorschläge sehen aus wie NES-Vorschläge. Der Unterschied liegt in der Entscheidungslogik dahinter, wann welches System zum Zug kommt.

Praktisch relevanter für den Alltag: Der Fix des Client-Bugs bedeutet, dass Sie seltener denselben, bereits abgelehnten Vorschlag ein zweites Mal als vermeintlich neue Next-Edit-Suggestion sehen sollten. Wenn Sie also das Gefühl hatten, Copilot „wiederholt sich“ nach dem Wegklicken eines Vorschlags — das war vermutlich genau dieser Bug, und er sollte mit dem aktuellen Rollout behoben sein.

Für alle, die sich generell für die Metrik-Seite von KI-Tools interessieren (und nicht nur bei Copilot): Das Muster hier — Feature-Launch, positive Headline-Zahl, dann eigene Nachprüfung, die einen Teil der Zahl relativiert — taucht in der Branche gerade öfter auf. Wer sich zum Beispiel mit den Trainingsansätzen bei OpenAI Academy beschäftigt hat, kennt ähnliche Diskussionen über saubere Baselines bei Lernmetriken. Auch im Smart-Home-Bereich, etwa bei der Home Assistant Matter-Integration, gibt’s regelmäßig Fälle, wo ein Protokoll-Bug erst nachträglich als Ursache für scheinbare „Verbesserungen“ oder „Verschlechterungen“ identifiziert wird. Es ist fast schon ein Running-Gag in der Techbranche: Erst die gute Zahl feiern, dann rausfinden, dass die halbe gute Zahl ein Messfehler war.

Die Ablation als eigentliches Qualitätsmerkmal

Was mich an dieser Geschichte tatsächlich positiv überrascht: dass GitHub die Ablationszahlen überhaupt veröffentlicht hat. Man hätte auch einfach nur „minus 10,1 Prozent, keine Regressionen“ schreiben können und den Bug intern reparieren, ohne die Öffentlichkeit über die Größenordnung der Verzerrung zu informieren. Stattdessen gibt’s die konkrete Zahl: nesMimicGhostTextBehavior, plus 15,9 Prozent im simulierten Bug-Zustand, minus 10,1 Prozent im Fix-Zustand, 26 Prozentpunkte Differenz.

Diese Transparenz ist meiner Einschätzung nach wertvoller als die eigentliche Feature-Ankündigung. Denn sie zeigt ein Verfahren, das andere Teams — auch außerhalb von GitHub — kopieren könnten: Bevor Sie eine Metrik-Verbesserung als Modell-Erfolg verkaufen, bauen Sie ein Flag, das den alten (potenziell buggy) Zustand simuliert, und fahren Sie die Ablation gegen den neuen Zustand. Nur so trennen Sie „das Modell ist besser“ von „der Editor hat vorher Mist gezählt“.

Ehrlich gesagt hätte ich mir gewünscht, dass der Blogpost noch einen Schritt weiter geht und zeigt, wie sich die Zahlen speziell auf Long-Distance-Edits und reine NES-Interaktionen (ohne Ghost-Text-Vermischung) aufteilen. Aber das ist meckern auf hohem Niveau — dass überhaupt eine öffentlich nachvollziehbare Ablationsstudie mit konkretem Flag-Namen existiert, ist schon mehr Transparenz, als man von den meisten Produktankündigungen in dem Bereich gewohnt ist.

Was daraus für andere KI-gestützte Tools zu lernen ist

Die generelle Lektion, die ich aus diesem Fall mitnehme, geht über Copilot hinaus. Immer wenn ein Tool mehrere vorher getrennte Vorschlags- oder Interaktionssysteme zusammenlegt — sei es bei Automatisierungsplattformen wie Make.com, wo unterschiedliche Trigger-Logiken verschmelzen, oder bei Consumer-Feature-Merges wie kürzlich bei Android Auto — entsteht dieselbe Grundgefahr: Alte Client-Zustände, alte Zähllogiken, alte Caches können im neuen, vereinten System Artefakte produzieren, die aussehen wie echte Nutzersignale, es aber nicht sind.

Die Regel, die ich daraus ziehen würde: Jede Metrik, die auf „Nutzerin hat abgelehnt/akzeptiert/ignoriert“ basiert, ist nur so vertrauenswürdig wie die darunterliegende Zähllogik im Client. Und die Zähllogik zu prüfen ist meistens der langweiligste, unsexyste Teil eines Feature-Launches — weshalb er gerne übersprungen wird, bis jemand zufällig eine Unstimmigkeit entdeckt, so wie hier offenbar bei der 13-Prozent-Ghost-Text-Abweichung.

Mal ehrlich: Wie oft haben Sie selbst schon eine Kennzahl präsentiert bekommen — im Job, im Reporting, irgendwo — und einfach angenommen, dass die Zähllogik dahinter stimmt? Ich tu das ständig, bis mich mal wieder ein Fall wie dieser daran erinnert, genauer nachzufragen. Copilot-Dismissal-Rate ist da nur ein besonders gut dokumentiertes Beispiel, weil GitHub die Ablation offengelegt hat. Bei den meisten anderen Tools bleibt so ein Client-Bug vermutlich einfach in den Baseline-Zahlen versteckt, unbemerkt, weiter im Live-Betrieb.

Was noch offen bleibt

Ein paar Dinge, die der Blogpost nicht restlos klärt, und die ich als Nerd natürlich gerne genauer wüsste: Erstens, wie lange lief der Bug schon in Produktion, bevor er entdeckt wurde — Wochen, Monate? Zweitens, ob es neben dieser einen Ablation weitere Segmentierungen gibt, etwa nach Programmiersprache oder Editor-Nutzungsverhalten (Viel-Tipper vs. Wenig-Tipper könnten unterschiedlich stark vom Bug betroffen gewesen sein). Drittens, ob und wie sich die minus 10,1 Prozent über verschiedene VS-Code-Versionen und Rollout-Phasen stabil zeigen, oder ob es dort noch Schwankungen gibt, die erst mit mehr Zeit sauber sichtbar werden.

Das sind Fragen, die man wahrscheinlich erst mit einem Part Three beantworten kann, falls GitHub das Format fortführt. Nach den ersten beiden Teilen würde mich das nicht überraschen — das Team scheint Spaß daran zu haben, öffentlich vorzurechnen, wie die Wurst gemacht wird. Und das, im Ernst, ist selten genug, dass es Aufmerksamkeit verdient, unabhängig davon, wie man am Ende die eigentliche Feature-Qualität bewertet.

https://digital-magazin.de/openai-academy/

Die kurze Version für alle, die nur bis hier gescrollt haben

GitHub hat Ghost Text, Next-Edit-Suggestions und Long-Distance-Edits in VS Code zu einem gemeinsamen Modell zusammengelegt. Die Dismissal-Rate sank dabei um 10,1 Prozent — klingt nach einem klaren Erfolg. Ist es teilweise auch, aber eben nicht komplett so, wie die erste Schlagzeile suggeriert: Ein alter Client-Bug hatte ignorierte Ghost-Text-Vorschläge nach Cursor-Bewegungen als „neue“ NES-Vorschläge wiederauftauchen lassen und dadurch die alte Baseline um geschätzt 7 bis 8 Prozent künstlich aufgebläht. Die eigene Ablationsstudie über das Flag nesMimicGhostTextBehavior zeigt die volle Größenordnung: plus 15,9 Prozent mit simuliertem Bug, minus 10,1 Prozent mit Fix — 26 Prozentpunkte Unterschied, nur durch einen Anzeigefehler im Editor.

Die eigentliche Story ist also nicht „Copilot 3-in-1 shipped, alles besser“. Die eigentliche Story ist: Ohne diese eine Ablationsstudie hätte GitHub (und alle, die die Zahl weiterverbreitet hätten, mich eingeschlossen) Modell-Verdienst mit Bug-Korrektur verwechselt. Das Badge „3-in-1 shipped“ sagt nichts über UX-Qualität aus, solange man nicht getrennt hat, was das Modell wirklich verändert hat und was einfach ein Fehler im Client war, der zufällig gerade jetzt gefixt wurde.

Parallel dazu die andere Zahl aus Part One, die die Dimension klarmacht: über 61 Milliarden erfolgreiche Model Requests in 90 Tagen für diese Inline-Systeme. Bei diesem Volumen ist jede Prozentangabe kein Nischenthema, sondern betrifft potenziell Hunderte Millionen Interaktionen — Grund genug, bei der nächsten großen Prozentzahl in einer Produktankündigung erstmal zu fragen: Ist das der Fortschritt, oder ist das der Bug, der gerade rausgeflogen ist?