GitHub Copilot in VS Code: Parallele Agenten kontrolliert einsetzen

Ein Blog braucht eine neue Kartenkomponente, während die bestehende 404-Seite unabhängig davon eine deutsche Übersetzung erhalten soll. Beide Aufgaben sind klein, berühren unterschiedliche Dateien und besitzen eigene Nutzerflüsse. Sie eignen sich deshalb als Beispiel für parallele Copilot-Sessions, solange die Integration kontrolliert bleibt.

GitHub bündelte am 8. Juli 2026 Neuerungen aus den VS-Code-Versionen 1.123 bis 1.127. Dazu gehören der allgemein verfügbare agentische Browser, parallele Chats und Sessions, sichtbarere Kosten einschließlich Subagenten sowie ein weitergehender Autopilot-Modus.

Aufgaben nach Verträgen statt nach Größe schneiden

Die Blogkarte rendert Titel, Kurztext, Datum und Link aus einem vorhandenen Artikeldatentyp. Die 404-Lokalisierung betrifft Fehlermeldung, Sprache und Rücklink. Solange keine Aufgabe den gemeinsamen Router, den Artikeldatentyp oder dieselbe Übersetzungsdatei strukturell ändert, können beide getrennt laufen.

„Klein“ allein reicht nicht als Kriterium. Zwei Einzeiler am selben Datenmodell können stärker kollidieren als zwei größere Komponenten in getrennten Bereichen. Der Beitrag Was sind KI-Agenten? erklärt, warum klarer Aktionsraum und Übergabe wichtiger als maximale Selbstständigkeit sind.

Jede Session mit eigenem Vertrag starten

Die Karten-Session erhält den Auftrag, eine vorhandene Komponente zu erweitern, keine Datenstruktur zu verändern und einen Render-Test für Titel und Link zu ergänzen. Die 404-Session soll eine unbekannte deutsche URL öffnen, den lokalisierten Text umsetzen und den Rückweg zur Startseite prüfen. Beide melden geänderte Dateien, Tests und offene Annahmen.

Formuliere Abnahmen getrennt. Die Karte muss auf schmalen Breiten lesbar bleiben und den korrekten Artikel öffnen; die 404-Seite muss bei einer unbekannten Route erscheinen, deutsche Sprache verwenden und per Tastatur zurückführen. Eine Vorlage dafür findest du in Dein erster guter Prompt.

Arbeitsstände technisch isolieren

Parallele Chats bedeuten nicht automatisch isolierte Dateien. Nutze je nach Projekt eigene Branches und Worktrees oder mindestens klar getrennte Änderungsbereiche. Jede Session startet aus demselben bekannten Basisstand und darf fremde uncommitted Änderungen nicht übernehmen.

Dokumentiere gemeinsame Verträge als unveränderliche Grenze. Erkennt ein Agent, dass er doch den Router oder Artikeldatentyp ändern muss, stoppt er und meldet die Abhängigkeit. Dann werden die Aufgaben nacheinander geplant, statt einen semantischen Konflikt nachträglich zu erraten.

Die Blogkarte separat prüfen

Die erste Session führt den Komponenten- oder Seitentest aus und zeigt ihren Diff. Prüfe, ob vorhandene Designbausteine wiederverwendet werden, der Link aus dem echten Slug entsteht und fehlende optionale Daten keinen Absturz verursachen. Öffne anschließend den Feed im Browser und teste Karte, Fokus und Zielseite.

Der agentische Browser kann diesen Ablauf direkt aus der Coding-Session unterstützen. Er ersetzt den automatisierten Test nicht, belegt aber, dass Komponente, Routing und sichtbares Layout in der laufenden Anwendung zusammenspielen.

Die 404-Lokalisierung separat prüfen

Die zweite Session öffnet eine garantiert unbekannte deutsche URL. Erwartet werden ein verständlicher deutscher Hinweis, ein korrektes Sprachdokument und ein funktionierender Rücklink. Zusätzlich sollte ein Routing-Test verhindern, dass die Änderung versehentlich gültige Seiten auf die 404-Ansicht lenkt.

Prüfe Randfälle wie einen unbekannten Pfad mit Query-Parametern und eine schmale Bildschirmbreite. Wenn die Anwendung mehrere Sprachen unterstützt, darf die deutsche Anpassung keine Texte anderer Locales überschreiben.

Ergebnisse nacheinander integrieren

Erst wenn beide Sessions ihre eigenen Abnahmen erfüllen, werden die Änderungen einzeln auf den gemeinsamen Stand gebracht. Führe nach jeder Integration die relevanten Tests aus; nach der zweiten folgen die gemeinsame Suite und beide Browserflüsse. So ist sichtbar, welche Änderung einen möglichen Rückschritt verursacht.

Ein Merge ohne Textkonflikt ist noch kein Beweis für fachliche Verträglichkeit. Die Blogkarte könnte beispielsweise einen globalen Stil verändern, der auch die 404-Seite beeinflusst. Der gemeinsame Browsercheck bleibt deshalb Teil der Abnahme.

Autopilot und Kosten begrenzen

Autopilot kann weitere Schritte selbstständiger ausführen, doch eine kleine Aufgabe braucht weiterhin Stoppsignale. Setze ein Zeitbudget, eine maximale Anzahl geänderter Dateien und den Auftrag, bei gemeinsamem Vertrag oder fehlender Testumgebung zu stoppen. Beobachte die von VS Code angezeigte Nutzung der Session und ihrer Subagenten.

Mehr Parallelität kann Gesamtlaufzeit senken, aber Token- und Reviewaufwand erhöhen. Vergleiche daher nicht nur die Geschwindigkeit bis zum ersten Patch, sondern auch Korrekturrunden, Integrationsarbeit und gefundene Regressionen.

Repository Overview als Einstieg nutzen

GitHub veröffentlichte am 9. Juli 2026 außerdem die Möglichkeit, Copilot nach einer Repository Overview zu fragen. Sie fasst laut Ankündigung Zweck, verwendete Technologien und Hinweise für Beiträge zusammen. Das kann neuen Sessions Orientierung geben, ist aber kein verlässlicher Ersatz für lokale Anweisungen, Tests und kritische Verträge.

Lass eine Session wichtige Behauptungen an konkreten Dateien bestätigen. Wenn Übersicht und Code widersprechen, gewinnt der aktuelle Code; veraltete Dokumentation sollte als eigener, geprüfter Auftrag korrigiert werden.

Grenzen und typische Fehlerfälle

Ein Browser-Agent kann auf einer falschen Umgebung testen, einen vorhandenen Serverstand statt des aktuellen Branches öffnen oder sichtbare Fehler übersehen. Halte deshalb URL, Branch, Startkommando und Testergebnis fest. Bei Login, Zahlungen oder Schreibzugriffen braucht der Browser zusätzlich sichere Testdaten und minimale Berechtigungen.

Parallele Agenten dürfen keine Ausrede für ungeprüfte Änderungen sein. Sobald Aufgaben dieselbe Zustandsquelle, API oder Migration berühren, serialisiere die Arbeit und entscheide den gemeinsamen Vertrag zuerst.

Checkliste für parallele Copilot-Arbeit

• Jede Aufgabe besitzt einen unabhängigen Dateibereich oder klaren Vertrag.
• Gemeinsame Datenmodelle, Routen und Migrationen werden nicht parallel verändert.
• Branch, Worktree oder anderer Arbeitsstand ist pro Session eindeutig.
• Jede Session hat eigene Tests und einen sichtbaren Abnahmefluss.
• Browserprüfung nutzt nachweislich den aktuellen Arbeitsstand und die richtige URL.
• Zeit-, Datei- und Nutzungsbudgets für Autopilot und Subagenten sind gesetzt.
• Ergebnisse werden einzeln integriert und danach gemeinsam erneut getestet.
• Repository Overview dient nur als Orientierung und wird am Code verifiziert.