GitHub Copilot wird Multi-LLM: Gemini 3 Pro, Claude Opus 4.5 & GPT-5 in der Public Preview

Multi-LLM wird zum Standard in Copilot

Bei GitHub Copilot verschiebt sich der Fokus spürbar: Weg vom „ein Modell für alles“ hin zu einer Multi-LLM-Strategie, bei der Teams je nach Aufgabe das passende Modell wählen (oder wählen lassen). Das ist mehr als ein Feature-Update – es betrifft direkt Codequalität, Durchsatz im Alltag und die Planbarkeit in größeren Organisationen, weil unterschiedliche Modelle unterschiedliche Stärken und Verfügbarkeiten mitbringen.

Die drei Kern-Updates im Überblick

• Gemini 3 Pro in Public Preview – breit in IDEs: Gemini ist in Copilot als Option angekommen und zielt darauf, anspruchsvollere Coding-Aufgaben mit starkem Kontextverständnis zu unterstützen. Praktisch für Teams: Ihr könnt in eurer Standard-IDE bleiben und trotzdem für bestimmte Workflows ein anderes Modell nutzen, ohne Tool-Wechsel oder Parallel-Setups.
• Mehr Modelle: Claude Opus 4.5 sowie GPT-5.x (inkl. GPT-5.2): Claude Opus 4.5 ist besonders interessant, wenn es um komplexe Refactorings, Architektur-Entscheidungen oder „Warum bricht das hier?“–Debugging mit vielen Abhängigkeiten geht. GPT-5.2 spielt seine Stärken oft bei formalen Problemen aus, etwa wenn ihr knifflige Algorithmen, numerische Logik oder Testfall-Herleitungen braucht.
• Agent Skills + Auto-Model-Picker: Copilot kann Aufgaben stärker agentisch abarbeiten (z. B. mehrstufige Änderungen, Tests anpassen, Fehler iterativ beheben) und im „Auto“-Modus das Modell passend zur Anfrage auswählen. Das reduziert Reibung, wenn nicht jeder im Team Modell-Expertise mitbringt.

Warum das für Teams sofort relevant ist

In der Praxis heißt das: Ihr könnt Modellwahl als Teil eurer Engineering-Routine etablieren. Beispiel: Für ein riskantes Refactoring wählt ihr bewusst Claude Opus 4.5, für schnelle Prototypen oder „skizziere mir eine Lösung“ eher ein schnelles Modell, und für mathematisch saubere Edge-Case-Analysen greift ihr zu GPT-5.2. Ein pragmatischer Tipp: Legt in euren Coding-Guidelines fest, wann „Auto“ reicht und wann ein bewusstes Modell-Override erwartet ist (z. B. bei Security-kritischem Code oder großen API-Migrationen).

Mini-Beispiel: Agent-Skills-Ordnerstruktur (Template)

Dieses Template zeigt eine pragmatische Agent-Skills-Struktur, die du in ein Repo legen kannst. Die Idee: klare Instruktionen (für konsistente Outputs), kleine Skripte (für wiederholbare Checks) und optionale Ressourcen (Policies, Beispiele, Mappings). Benenne Skills so, dass ihr Team sie sofort versteht (z. B. pr-reviewer, migration-helper).

.
└─ agent-skills/
   ├─ pr-reviewer/
   │  ├─ instructions.md
   │  ├─ scripts/
   │  │  └─ changed-files.js
   │  └─ resources/
   │     ├─ review-checklist.md
   │     └─ security-baseline.md
   └─ test-generator/
      ├─ instructions.md
      └─ resources/
         └─ test-styleguide.md

1) Beispiel: agent-skills/pr-reviewer/instructions.md

# Skill: PR Reviewer

## Ziel
Prüfe Pull Requests auf Correctness, Security, Tests, Maintainability.

## Do
- Antworte im Format: Findings, Risk, Suggested Patch, Test Notes.
- Referenziere konkrete Dateien/Zeilen, wenn vorhanden.
- Priorisiere nach Severity: Critical, High, Medium, Low.

## Don't
- Keine großflächigen Refactors ohne explizite Anfrage.
- Keine neuen Dependencies vorschlagen, wenn nicht nötig.

## Output-Format (Markdown)
### Findings
- [Severity] Kurzbeschreibung

### Suggested Patch
```diff
...minimaler Patch...
```

### Test Notes
- Welche Tests ausführen, welche Edge-Cases prüfen

2) Script-Stub: agent-skills/pr-reviewer/scripts/changed-files.js

#!/usr/bin/env node
/**
 * changed-files.js
 * Liest eine Liste geänderter Dateien aus STDIN (z. B. aus git diff) und filtert irrelevante Pfade.
 * Nutzung:
 *   git diff --name-only origin/main...HEAD | node agent-skills/pr-reviewer/scripts/changed-files.js
 */

const fs = require('fs');

const input = fs.readFileSync(0, 'utf8');
const files = input
  .split(/\r?\n/)
  .map(s => s.trim())
  .filter(Boolean);

// Beispiel: ignoriere Build-Artefakte, Lockfiles, generierte Ordner
const ignore = [
  /^dist\//,
  /^build\//,
  /^coverage\//,
  /package-lock\.json$/,
  /pnpm-lock\.yaml$/,
  /yarn\.lock$/,
];

const relevant = files.filter(f => !ignore.some(rx => rx.test(f)));

// Ausgabe als JSON, damit ein Agent es leicht weiterverarbeiten kann
process.stdout.write(JSON.stringify({
  changedFiles: relevant,
  total: files.length,
  relevantCount: relevant.length
}, null, 2));
process.stdout.write('\n');

Praxis-Tipp: Lege in resources/ eine Team-Checkliste ab (Naming, Logging, Threat-Model, Test-Policy). So bleibt der Skill stabil, auch wenn ihr zwischen Modellen wechselt.

Ein Tool, um sie alle zu steuern – oder nur ein neuer Standard-Client?

Für IT-Systemhäuser und Agenturen ist Copilots Schritt zur Multi-LLM-Plattform vor allem ein Governance-Thema: Statt Teams auf ein einziges Modell festzunageln, lässt sich pro Aufgabe das passende Modell wählen – und im „Auto“-Modus übernimmt Copilot die Auswahl anhand von Kontext und Limits. Das kann die operative Reibung senken, weil weniger Tool-Wechsel nötig ist: ein Chat-Workflow, mehrere Modelle (u. a. Claude Opus 4.5, GPT-5.x und Gemini 3) – je nach IDE und Rollout-Status.

Wann ein Wechsel realistisch ist

Ein kompletter Umstieg passiert meist dort, wo Standardisierung mehr wert ist als maximale Spezialisierung: große Kundenprojekte, gemischte Tech-Stacks, mehrere IDEs (VS Code, Visual Studio, JetBrains, Xcode, Eclipse) und wechselnde Teams. Praktisch: Ein Onboarding-Playbook kann sich auf einen Copilot-Workflow stützen, während die Modellwahl je nach Task variiert (z. B. Claude für große Refactors, GPT-5.x für knifflige Logik/Math, Gemini für schnelle Iterationen).

• Projekt-Setups: Definiere pro Repo eine „Default“-Empfehlung (Auto oder ein fixes Modell) und Ausnahmen für Spezialfälle.
• Qualitätssicherung: Lege fest, wann Antworten als „Entwurf“ gelten (z. B. bei Architekturentscheidungen) und wann zwingend Review/Tests laufen müssen.
• Team-Konsistenz: Nutze einheitliche Agent Skills für wiederkehrende Aufgaben (PR-Review, Test-Generator, Security-Check), damit Output-Formate und Regeln stabil bleiben – unabhängig vom Modell.

Wo Copilot nicht automatisch „alles ersetzt“

Viele Agenturen werden nicht vollständig wechseln, sondern konsolidieren: Copilot als zentrale Oberfläche, Spezialtools bleiben für Nischen (z. B. stark terminalbasierte Flows oder sehr spezifische Code-Agents). Entscheidend ist, ob eure Delivery-Prozesse (Branching, PR-Policies, Compliance) von Agent Skills und dem Modell-Picker profitieren. Wenn ihr heute viel Zeit in Prompt-Standards, Review-Checklisten und Tool-Training steckt, kann Copilot als Orchestrator die Komplexität reduzieren – ohne dass ihr euch auf ein einziges Modell festlegt.