Vom Team-Chat zum Pull Request: Was GitHub Copilot jetzt übernehmen darf

GitHub testet Copilot-Agenten in Teams und Slack. Was sich für Teams ändert und warum Pull Requests weiterhin menschliche Prüfung brauchen.

Von Wolfgang

23. Aug. 20265 Min. Lesezeit

GitHub testet Copilot-Agenten in Teams und Slack. Was sich für Teams ändert und warum Pull Requests weiterhin menschliche Prüfung brauchen.

Ein Arbeitsauftrag aus einem Teams-Kanal oder Slack-Thread kann künftig direkt in eine Copilot-Aufgabe übergehen. GitHub hat dafür am 21. August öffentliche Vorschauen vorgestellt. Aus einem @GitHub-Aufruf kann eine gemeinsame, asynchron laufende Agent-Sitzung werden, die ein Problem untersucht, Änderungen vorbereitet und gegebenenfalls einen Pull Request anlegt.

Für Teams ist das mehr als ein neuer Bot im Chat. Die Entscheidung über eine Aufgabe entsteht oft dort, wo Menschen ohnehin sprechen: in einem Meeting, einem Thread oder einer Direktnachricht. Der Ablauf wird damit sichtbarer. Er wird aber nicht automatisch einfacher zu verantworten. Repository-Rechte, Budgets, Tests, Sicherheitsprüfung und die Entscheidung über einen Merge bleiben bei den Menschen und den vorhandenen Regeln des Projekts.

Drei Kolleginnen und Kollegen besprechen an einem Arbeitstisch eine technische Aufgabe neben unmarkiertem Laptop, Smartphone und Diff-Ausdruck — Im Team-Chat beginnt ein sichtbarer Arbeitsweg, doch die Prüfung der Änderung bleibt bei Menschen – durch KI erzeugt

Vom Gespräch zur prüfbaren Änderung

GitHub beschreibt für Teams und Slack zwei getrennte öffentliche Vorschauen. In beiden Fällen kann ein Team eine Unterhaltung als Einstieg nutzen. Ein Auftrag und der vorhandene Kontext gehen an Copilot; andere Beteiligte können Fragen stellen, Informationen ergänzen oder die Richtung korrigieren. Die Sitzung arbeitet im Hintergrund weiter.

In einem Chat oder Thread entsteht eine Aufgabe, etwa ein Fehlerbericht oder eine offene technische Frage.
Ein @GitHub-Aufruf übergibt Aufgabe und Kontext an eine gemeinsame Agent-Sitzung.
Copilot untersucht das Repository und arbeitet je nach Oberfläche in einer ephemeren Cloud-Umgebung an einem Plan, Änderungen, Tests oder Artefakten.
Das Ergebnis landet auf einem Branch und kann als Pull Request zur Prüfung bereitstehen.
Das Team prüft Diff, Tests, Abhängigkeiten, Sicherheitsfolgen und Fachlogik. Erst danach kann ein Mensch einen Merge freigeben.

Diese Prozesskarte trennt vier Dinge, die im Chat leicht ineinanderlaufen: Sichtbarkeit für das Team, das Recht zu handeln, die Kosten der Ausführung und die Qualität der Änderung. Ein sichtbarer Agentenlauf bedeutet nicht automatisch Schreibzugriff. Ein Pull Request ist ein Arbeitsprodukt, keine Freigabe für die Produktion.

Prozessgrafik zeigt Team-Chat, GitHub-Aufruf, Agent-Sitzung, ephemere Arbeitsumgebung, Branch und Pull Request bis zur menschlichen Prüfung — Vom Team-Chat bis zum Pull Request bleibt die menschliche Prüfung der offene letzte Schritt – durch KI erzeugt

Teams und Slack sind nicht dieselbe Integration

In Microsoft Teams nennt GitHub eine gemeinsame Cloud-Agent-Sitzung aus Kanal, Thread oder Direktnachricht. Wer Änderungen veranlassen soll, braucht Schreibzugriff auf das jeweilige Repository. Für Organisationskonten müssen Administratoren Cloud Agent und Cloud Sandboxes aktivieren; außerdem verweist GitHub auf die Microsoft Public Developer Preview als Teams-Voraussetzung.

Für Slack beschreibt GitHub eine öffentliche Vorschau für Organisationen mit Copilot Business oder Enterprise. Dort kann Copilot unter anderem Fragen zum Code beantworten, Issues bearbeiten, Fehler untersuchen, Änderungen implementieren und validieren oder einen Pull Request öffnen. Slack Code soll Plan, Diffs und Vorschauen in einem eigenen Kanal bündeln. Das hilft bei der gemeinsamen Steuerung, ist aber keine Zusage, dass Teams und Slack denselben Funktionsumfang, dieselben Voraussetzungen oder dieselbe Verfügbarkeit haben.

Rechte begrenzen den Agenten, sie prüfen den Code nicht

GitHub bindet die Agentenarbeit an bestehende Repository-Berechtigungen und Organisationskontrollen. Administratoren können zusätzlich verlangen, dass Pull Requests der Copilot-Identität vor einem Merge noch einmal genehmigt werden. Das ist sinnvoll, weil der Chat-Aufruf nicht beantwortet, ob eine Änderung fachlich richtig ist, sensible Daten berührt oder eine Abhängigkeit neue Risiken mitbringt.

Die unabhängige Forschung im Dossier betrifft andere Agenten und Datensätze, nicht die neue Teams- oder Slack-Integration. Sie liefert deshalb keine Fehlerquote für GitHub Copilot in diesen Vorschauen. Sie zeigt aber, warum ein erzeugter Pull Request nicht mit fertiger Software verwechselt werden sollte: In einer Untersuchung zu agentengenerierten Pull Requests fanden Forschende Security Smells in 38,9 Prozent der betrachteten Pull Requests. Eine weitere Studie zu Claude-Code-Pull-Requests berichtet, dass 45,1 Prozent der gemergten Änderungen zusätzliche Anpassungen brauchten.

Vergleichsgrafik stellt die unterschiedlichen Voraussetzungen und Kontrollschichten der Copilot-Vorschauen in Microsoft Teams und Slack gegenüber — Teams und Slack bieten getrennte Chat-Einstiege mit eigenen Voraussetzungen, Budgets und offenen Praxisfragen – durch KI erzeugt

Auch die Kosten haben zwei Schichten

Für die Nutzung von Copilot spielen AI Credits eine Rolle; GitHub dokumentiert sie als modell- und tokenabhängige Abrechnungseinheit. Cloud-Sandboxes werden davon getrennt budgetiert. Daraus lässt sich keine seriöse Pauschale pro Auftrag ableiten. Entscheidend sind unter anderem Modell, Tokenverbrauch, Laufzeit und die konkrete SKU.

Für kleinere Teams ist das kein Detail am Rand. Ein kurzer Chat-Hinweis und ein mehrstufiger Agentenlauf im Repository sind unterschiedliche Vorgänge. Wer die Vorschau ausprobiert, sollte daher vorab klären, welches Repository der Kanal ansprechen darf, welches Budget greift und wer einen Lauf stoppen kann.

Was deutsche Teams vor einem Test klären sollten

Eine deutsche oder EU-weite Verfügbarkeit sowie eine Datenschutz- oder Compliance-Freigabe ergeben sich aus den Ankündigungen nicht. Für einen ersten Test ist deshalb ein begrenztes Repository sinnvoll, dazu getrennte Budgets, sichtbare Zwischenstände und eine klare Regel für die menschliche Abnahme. Der nächste belastbare Nachweis wäre ein dokumentierter Praxiseinsatz unter solchen Bedingungen, nicht bloß ein Chat-Screenshot oder ein erzeugter Pull Request.

GitHub verlegt den Startpunkt der Agentenarbeit in den Team-Chat. Das kann Übergaben nachvollziehbarer machen. Verlässlich wird der Prozess erst dort, wo Aufgabe, Rechte, Kosten und Review konkret geregelt sind.