GitHub Copilot: Gemini-Modelle wechseln

Ein Modell verschwindet aus einer Auswahlliste – und plötzlich ist ein Teil des gewohnten Arbeitsablaufs nur noch Erinnerung. Genau das ist bei GitHub Copilot passiert: Seit dem 31. Juli sind Gemini 2.5 Pro und Gemini 3 Flash dort abgekündigt. Wer GitHub Copilot Gemini bewusst für Chat, Inline-Änderungen oder Agentenläufe gewählt hat, sollte den Wechsel nicht wie eine harmlose Versionsnummer behandeln. Es ist ein kleiner Umbau am Werkzeugkasten.

Die offizielle GitHub-Mitteilung zur Abkündigung nennt die Nachfolger klar: Gemini 3.1 Pro (Preview) für Gemini 2.5 Pro, Gemini 3.6 Flash für Gemini 3 Flash. Das klingt zunächst nach einer sauberen Zuordnung. Im Alltag steckt die Arbeit aber nicht im Namen des Ersatzmodells, sondern in den kleinen Erwartungen, die ein Team über Wochen an Antworten, Code-Reviews und Agentenaufgaben geknüpft hat.

GitHub Copilot Gemini: Was jetzt tatsächlich weg ist

GitHub schreibt ausdrücklich, dass die Änderung alle Copilot-Erfahrungen betrifft: Copilot Chat, Inline Edits, Ask- und Agent-Modus sowie Code Completions. Das ist der Punkt, an dem ein schneller Blick in die Modellliste zu kurz greift. Ein Team kann beispielsweise Chat nur für Verständnisfragen nutzen, den Agent-Modus aber für abgegrenzte Refactorings. Beide Wege können andere Prompts, andere Berechtigungen und andere Erfolgskriterien haben.

Wichtig ist auch die Formulierung „deprecated“. Sie beschreibt hier nicht bloß eine Empfehlung für später, sondern den bereits vollzogenen Wechsel am 31. Juli. Wer noch interne Wiki-Seiten, Prompt-Vorlagen oder Onboarding-Screenshots mit den alten Namen pflegt, produziert unnötige Irritation. Die Lösung ist angenehm unspektakulär: alte Modellnamen suchen, Fundstellen bündeln und mit einer klaren Ersatzzuweisung versehen. Das spart mehr Rückfragen als jede große Migrationsfolie.

Für Einzelpersonen ist die Sache oft schnell erledigt. Im Copilot-Selektor wird ein anderes Modell gewählt, ein paar vertraute Aufgaben laufen erneut, fertig. In Teams entstehen hingegen versteckte Abhängigkeiten: gespeicherte Anweisungen verweisen auf ein Modell, Verantwortliche vergleichen Ergebnisse gegen ältere Pull Requests oder ein Projekt verlangt eine bestimmte Geschwindigkeit bei Routineänderungen. Dort lohnt sich ein kurzer, dokumentierter Check.

Die Ersatzmodelle sind eine Entscheidung, keine Umbenennung

Gemini 3.1 Pro (Preview) und Gemini 3.6 Flash sind die von GitHub vorgeschlagenen Alternativen. Mehr behauptet die Ankündigung nicht – und genau so sollte man damit arbeiten. Es wäre voreilig, aus dem Ersatznamen automatisch identische Qualität, identische Antwortlänge oder identisches Verhalten bei jeder Aufgabe abzuleiten. KI-Modelle sind keine austauschbaren Schrauben. Sie reagieren auf Kontext, Instruktionen, Repository-Struktur und Toolzugriff.

Mein pragmatischer Rat: Trennen Sie zuerst Aufgaben nach Risiko, nicht nach Begeisterung. Eine Erklärung zu einer fremden Code-Stelle ist ein guter erster Test. Danach folgen kleine, reversible Änderungen mit bestehenden Tests. Erst wenn diese Strecke sauber läuft, kommen Aufgaben mit vielen Dateien, migrationskritische Änderungen oder automatisierte Reviews. Das wirkt weniger glamourös als ein „wir probieren einfach den neuen Standard“, verhindert aber, dass ein Modellwechsel mitten in einem wichtigen Sprint zum Ratespiel wird.

Die neue Version von Visual Studio Code liefert dafür nützlichen Kontext. In den Release Notes zu VS Code 1.131 beschreibt Microsoft den Agent Host und zeigt bei laufenden Subagents unter anderem Modell, Laufzeit und aktiven Tool-Aufruf an. Sichtbarkeit ersetzt keine Prüfung. Sie macht aber nachvollziehbar, welches Modell an welcher Stelle eine Aufgabe bearbeitet. Für produktive Teams ist das deutlich wertvoller als eine lange Liste abstrakter Modellversprechen.

Wer nur gelegentlich mit Copilot arbeitet, muss daraus kein Messlabor machen. Drei bis fünf typische Aufgaben reichen: eine Fehlermeldung erklären lassen, einen kleinen Test schreiben lassen, einen Dokumentationsabschnitt überarbeiten und einen engen Code-Review-Kommentar einholen. Entscheidend ist, dass dieselben Eingaben für den Vergleich verwendet werden. Sonst vergleicht man am Ende nicht Modelle, sondern zwei verschiedene Arbeitstage.

Vor dem Wechsel: eine kleine Vergleichsstrecke bauen

Eine gute Vergleichsstrecke braucht keinen Tabellenfriedhof. Sie braucht Aufgaben, bei denen Sie ohnehin wissen, woran ein brauchbares Ergebnis zu erkennen ist. Nehmen Sie etwa einen bekannten Bug mit reproduzierbarem Test, eine kleine Umbenennung über mehrere Dateien und einen Review zu einem bereits gemergten Pull Request. Bei allen drei Aufgaben lässt sich prüfen, ob der Vorschlag vollständig, nachvollziehbar und ohne neue Nebenwirkung ist.

Notieren Sie pro Aufgabe nur vier Dinge: Eingabe, gewähltes Modell, Ergebnis und Entscheidung. Ein Satz genügt häufig. „Test grün, aber falsche Datei geändert“ ist hilfreicher als eine diffuse Erinnerung zwei Wochen später. Wenn mehrere Personen testen, definieren Sie vorher, ob Stilfragen überhaupt zählen. Sonst gewinnt nicht das passendere Modell, sondern die lauteste Vorliebe.

Gerade bei Agentenaufgaben zählt außerdem der Weg zum Ergebnis. Hat der Agent eine Datei geändert, die gar nicht zum Auftrag gehörte? Wurden Tests wirklich ausgeführt oder nur erwähnt? Wurde ein Tool-Aufruf abgebrochen? Das sind keine Nebensachen. Sie entscheiden darüber, wie viel Nacharbeit ein Vorschlag erzeugt. Wir bei digital-magazin.de würden deshalb bei jeder Vergleichsaufgabe den Diff und die Testausgabe mitlesen – selbst dann, wenn die Antwort sprachlich sehr überzeugend klingt.

Ein häufiger Fehler ist die Suche nach einem Gesamtsieger. Für eine knappe, wiederkehrende Aufgabe kann ein schnelles Modell gut passen; für eine schwierige Änderung mit viel Kontext vielleicht ein anderes. Die GitHub-Ankündigung liefert die Ersatzoptionen, nicht Ihre Prioritäten. Sie müssen festlegen, ob Tempo, Erklärbarkeit, Testdisziplin oder Kosten in Ihrem Fall Vorrang haben. Diese Reihenfolge sollte im Team sichtbar sein.

Vergessen Sie die Erweiterungen nicht. Wer Copilot nicht nur im Editor, sondern mit verbundenen Diensten einsetzt, hat zusätzliche Kontextquellen und Berechtigungen im Spiel. Unser Überblick zu Copilot Extensions mit Jira, Azure und Datadog zeigt, warum ein Modellwechsel im echten Arbeitsfluss selten nur eine Frage der Antwortqualität ist. Prüfen Sie bei Ihrem Test deshalb mindestens einmal eine Aufgabe, die den normalen Tool- und Projektkontext nutzt.

Das gilt besonders für Vorschläge, die auf den ersten Blick korrekt aussehen. Ein Modell kann eine stimmige Erklärung formulieren und trotzdem die falsche Ticketinformation oder eine veraltete Projektkonvention heranziehen. Die Verantwortung bleibt bei den Menschen am Pull Request. Wer das als Belastung empfindet, sollte es umdrehen: Ein festes Review-Kriterium ist der Preis für schnelleres Ausprobieren – und schützt die Geschwindigkeit, wenn der nächste Wechsel kommt.

Enterprise-Teams: Policies gehören auf die Checkliste

GitHub weist darauf hin, dass Copilot-Enterprise-Administrierende den Zugriff auf Alternativen eventuell über Modellrichtlinien freischalten müssen. Das ist kein Detail am Rand. Ein Migrationsplan, der nur bei einer Person im Editor funktioniert, ist noch keiner. Prüfen Sie deshalb zuerst den Modellselektor mit einem normalen Teamkonto und erst danach mit einem Admin-Konto. Die Reihenfolge mag banal klingen, deckt aber Unterschiede zwischen Theorie und Alltag schnell auf.

Danach sollten Sie vier Fragen beantworten: Ist das Ersatzmodell für die betroffene Gruppe sichtbar? Dürfen die vorgesehenen Copilot-Modi es verwenden? Gibt es Budget- oder Nutzungsvorgaben? Und ist klar, wer bei einer Abweichung entscheidet? Die Antworten müssen nicht in einem großen Governance-Dokument landen. Ein kurzer Eintrag im Engineering-Handbuch reicht, sofern er auffindbar ist und einen Namen nennt.

Vorsicht bei automatisierten Abläufen. Wenn eine Anleitung, ein Skill oder eine Integrationskonfiguration einen Modellnamen hart kodiert, hilft ein Klick in der Benutzeroberfläche nicht weiter. Suchen Sie im Repository, in Konfigurationsdateien und in internen Vorlagen nach „Gemini 2.5 Pro“ und „Gemini 3 Flash“. Dokumentieren Sie jeden Fund und entscheiden Sie bewusst, ob er ersetzt, entfernt oder nur als historische Referenz markiert wird. So bleibt die Umstellung auditierbar.

Prompt-Suites statt Bauchgefühl

Ein Modellwechsel legt eine unangenehme Wahrheit offen: Viele Teams können nicht genau sagen, woran sie die Qualität ihrer KI-Unterstützung festmachen. „Fühlt sich schlechter an“ kann ein guter Alarm sein, ist aber kein Abschlussurteil. Besser ist eine kleine Prompt-Suite aus echten, datensparsamen Aufgaben. Sie bleibt nach der Umstellung erhalten und hilft auch beim nächsten Modellwechsel.

Eine solche Suite darf klein bleiben. Fünf bis zehn Aufgaben, die typische Arbeit abbilden, reichen für den Anfang. Achten Sie auf unterschiedliche Formen: Erklärung, Test, Refactoring, Review und eine Agentenaufgabe mit klarer Grenze. Speichern Sie keine geheimen Kundendaten in einer Vergleichssammlung. Repräsentative, bereinigte Beispiele sind oft sogar besser, weil das Ergebnis leichter besprochen werden kann.

Besprechen Sie Auffälligkeiten unmittelbar. Wenn Gemini 3.1 Pro (Preview) eine Anweisung anders deutet, ist das nicht automatisch ein Mangel. Vielleicht war die Anweisung zu offen. Vielleicht wurde eine Projektkonvention nicht mitgegeben. Der Wert der Suite liegt darin, solche Unterschiede sichtbar zu machen, bevor sie sich still in viele Pull Requests verteilen. Hand aufs Herz: Das ist produktiver als im Nachhinein über einzelne seltsame Antworten zu rätseln.

Auch interne Links können dabei helfen, einen bestehenden Wissensstand nicht zu verlieren. Unsere Einordnung zu Copilot als Cloud-Agent im Ticket-Workflow zeigt, warum Tool- und Prozesskontext bei Agenten wichtiger ist als ein einzelner Modellname. Und wer Grundlagen zu agentischen Abläufen sortieren will, findet in unserem Beitrag über die Operationalisierung von KI-Agenten im Mittelstand weitere Anhaltspunkte.

Was Sie heute erledigen sollten

Sie müssen wegen dieser Abkündigung keinen Produktionsstopp ausrufen. Aber Sie sollten den Wechsel auch nicht in die Kategorie „später mal aufräumen“ schieben. Öffnen Sie Copilot, prüfen Sie die verfügbaren Modelle, testen Sie eine kleine Vergleichsstrecke und kontrollieren Sie die Richtlinien, falls Ihr Team zentral verwaltet wird. Das sind überschaubare Schritte. Ihre Wirkung ist größer, als sie aussehen.

Planen Sie anschließend einen kurzen Rückblick ein. Nach einer Woche echter Nutzung reichen oft zehn Minuten im Team: Welche Aufgabe lief auffällig gut, wo entstand unnötige Nacharbeit, welche Vorlage braucht eine Präzisierung? Dieser Termin macht aus dem Test einen Lernkreislauf statt einer einmaligen Pflichtübung. Wenn keine Auffälligkeiten auftauchen, umso besser – dann ist die Notiz kurz und der Wechsel belastbar dokumentiert.

Halten Sie dabei auch fest, welche Annahmen bewusst offen bleiben. Preview-Modelle können sich ändern; eine heutige Erfahrung ist kein Vertrag für alle kommenden Wochen. Das ist kein Grund zur Panik, sondern ein Argument für kleine, wiederholbare Prüfungen. So bleibt Ihre Werkzeugwahl beweglich, ohne dass jede Produktmeldung den gesamten Entwicklungsprozess durcheinanderbringt.

Die Modelle sind abgekündigt, Ihre Arbeitsweise muss es nicht sein. Ein klarer Test, eine sichtbare Policy und eine kurze Notiz zu den getroffenen Entscheidungen machen aus einer abrupten Änderung einen kontrollierten Wechsel. Genau dafür sind Produktivitätstools da: nicht um Entscheidungen unsichtbar zu machen, sondern um gute Arbeit wiederholbar zu halten.

Wer GitHub Copilot Gemini bisher bewusst eingesetzt hat, sollte diese Woche einen Kalenderblock dafür reservieren. Dreißig konzentrierte Minuten schlagen drei Wochen unterschwelliger Unsicherheit. Der Punkt ist: Nicht der Ersatzname entscheidet über den Erfolg, sondern die Sorgfalt, mit der Sie ihn in Ihre tatsächlichen Aufgaben einführen.