Copilot in Teams: Wie aus einer Bug-Meldung im Chat ein Pull Request wird – und wer ihn freigibt

Es ist Dienstagmorgen, kurz nach acht. Im Teams-Kanal Ihrer Softwareabteilung erscheint die Meldung eines Kunden: Beim Erzeugen einer Rechnung bricht die Anwendung ab. Jemand antwortet mit „Schaue ich mir an“. Dann beginnt der übliche Weg: Der Fehler wird in ein Ticket übertragen, das Ticket landet in einer Warteschlange, ein Entwickler öffnet es, sucht die Stelle im Code, schreibt eine Korrektur, ein Kollege prüft sie. Zwischen der Meldung im Chat und dem ersten Code-Vorschlag liegen oft Stunden oder Tage, und ein großer Teil davon ist Übertragen und Warten, nicht Entwickeln.

Genau an dieser Stelle setzt eine Ankündigung an, die GitHub am 23. Oktober 2026 im Änderungsprotokoll („Changelog“) veröffentlicht hat. Der Titel lautet „Turn notifications into code with GitHub Copilot in Teams“, auf Deutsch etwa: Benachrichtigungen in Code verwandeln. Dieser Artikel zeigt, was in der Quelle steht, was dort nicht steht, was das für ein Unternehmen mit eigener Softwareentwicklung bedeutet und welche Vorbereitung vor dem 16. November sinnvoll ist.

Was GitHub angekündigt hat

Die Primärquelle ist der Changelog-Eintrag von GitHub vom 23. Oktober 2026, eingeordnet als „Improvement“, also als Verbesserung, nicht als Vorschau- oder Beta-Funktion. Wir haben den Eintrag vollständig gelesen. Er ist kurz, deshalb lassen sich die Kernaussagen gut zusammenfassen:

• Eine neue App in Microsoft Teams: Die GitHub-App in Teams verbindet Benachrichtigungen mit Copilot. Teams sollen dadurch Issues schneller in Korrekturen umsetzen können, ohne die Unterhaltung zu verlassen.
• Wo das funktioniert: Benachrichtigungen sind in Kanälen, in Gruppenchats und in privaten Chats möglich.
• Wie es ausgelöst wird: Mit einer Erwähnung von @GitHub lassen sich Updates in Aktionen umwandeln.
• Der Namenswechsel: Die App in Teams heißt jetzt „GitHub“. Vorher hieß sie „GitHub notifications“.
• Die Frist: Die bisherige App wird in „GitHub (deprecated)“ umbenannt und am 16. November eingestellt. Wer Copilot in Teams weiter nutzen möchte, muss die zusammengeführte App installieren.

Ein Hinweis zum Datum: Die Quelle schreibt „16. November“ und nennt das Jahr nicht ausdrücklich. Aus dem Zusammenhang (Veröffentlichung am 23. Oktober 2026) liegt der nächste 16. November nahe; wir geben es hier deshalb als „16. November“ wieder und behaupten keine weiteren Details.

Das Beispiel aus der Quelle: vom Fehlerbericht zum Pull Request

GitHub beschreibt einen Beispielablauf in drei Schritten. Wir geben ihn so wieder, wie er in der Quelle steht, und ordnen ihn danach ein.

1. Benachrichtigung: Ein Fehlerbericht („Bug Report“) erscheint in Teams.
2. Handlung: @GitHub untersucht das Problem, behebt den Fehler und erstellt einen Pull Request.
3. Prüfung und Auslieferung: Das Team prüft den Vorschlag, testet ihn und führt ihn zusammen („mergen“).

Für Leserinnen und Leser ohne Entwicklungshintergrund: Ein Pull Request ist ein Vorschlag für eine Änderung am Programmcode. Er ist zunächst nur ein Angebot. Die eigentliche Software verändert sich erst, wenn jemand den Vorschlag annimmt, das heißt zusammenführt. Genau dieser Zwischenschritt ist der Kern der ganzen Konstruktion: Der Agent darf vorschlagen, aber nicht allein entscheiden.

Der entscheidende Satz des Beispiels steht im dritten Schritt: Das Team prüft, testet und führt zusammen. Der Agent liefert den Entwurf, der Mensch trägt die Entscheidung.

Das ist bemerkenswert unspektakulär, und das ist gut so. Es bedeutet: Der Neuigkeitswert liegt nicht darin, dass ein Agent Code schreibt. Das war schon vorher möglich. Neu ist der Ort des Auslösers. Der Fehlerbericht muss nicht mehr erst in ein anderes Werkzeug übertragen werden, sondern wird dort bearbeitet, wo das Team ohnehin spricht.

Verfügbarkeit: was die Quelle sagt und was offen bleibt

Bei jeder Neuigkeit rund um KI-Agenten lohnt sich die Frage, ob man sie heute nutzen kann oder ob sie erst angekündigt ist. Für diesen Fall lässt sich Folgendes sagen:

• Status: Der Eintrag ist als Verbesserung gekennzeichnet. Einen Beta- oder Vorschauhinweis enthält er nicht. Er beschreibt die App und deren Installation als vorhanden. Die Abschaltung der alten App ist bereits terminiert.
• Region: Die Quelle nennt keine Einschränkung auf bestimmte Länder. Ob und ab wann die Funktion in jedem Land und für jeden Kontotyp erreichbar ist, belegt sie nicht. Für Deutschland, Österreich und die Schweiz gibt es in der Quelle weder eine Zusage noch einen Ausschluss.
• Voraussetzungen: Genannt werden ein GitHub-Konto, das Sie in der App verbinden, und ein Repository, das Sie auswählen. Ob für die Nutzung von Copilot in Teams eine bestimmte Copilot-Lizenz oder ein bestimmter Tarif nötig ist, steht in der Quelle nicht.

Diese letzte Lücke ist für die Praxis wichtig. Wenn Ihr Unternehmen heute keine Copilot-Lizenz hat, wissen Sie aus dieser Quelle nicht, ob die Funktion ohne zusätzliche Kosten erreichbar ist. Das lässt sich nur klären, indem Sie in der Dokumentation von GitHub nachlesen oder die App in einer Testumgebung ausprobieren. Wir nennen deshalb keinen Preis und keine Lizenzbedingung, weil wir keine geprüft haben.

Die konkrete Frist: der 16. November

Der handfesteste Punkt der Ankündigung ist weder die neue Funktion noch das Beispiel, sondern die Frist. Wer die bisherige Benachrichtigungs-App in Teams im Einsatz hat, bekommt eine Abkündigung: Die alte App wird eingestellt, die neue, zusammengeführte App ersetzt sie. Laut Quelle bleiben bestehende Benachrichtigungsfunktionen erhalten, wenn Sie auf die neueste Version wechseln.

Was daraus folgt, lässt sich in drei Sätzen sagen. Erstens: Wenn Ihr Entwicklungsteam GitHub-Benachrichtigungen in Teams nutzt, gibt es bis zum 16. November etwas zu tun, unabhängig davon, ob Sie die Copilot-Funktion einsetzen wollen. Zweitens: Wer die neue App einfach „mit installiert“, sollte vorher entscheiden, wer sie wo einsetzen darf. Drittens: Die Frist ist ein guter Anlass, die Frage der Freigaben jetzt zu klären und nicht erst nach dem ersten ungeplanten Pull Request.

Wir können nicht beurteilen, wie viele Unternehmen die alte App im Einsatz haben. Die Quelle nennt keine Zahlen zu Nutzern oder Installationen. Auch das gehört zu den Dingen, die wir nicht behaupten.

Was das für ein Unternehmen im Mittelstand bedeutet

Viele mittelständische Unternehmen haben eine kleine IT- oder Entwicklungsabteilung, manche nur wenige Personen, die Webshop, Schnittstellen, Kundenportal oder Produktionssoftware betreuen. Für sie sind die Wege zwischen „etwas ist kaputt“ und „es ist behoben“ besonders lang, weil dieselben Menschen Fehler suchen, neue Funktionen bauen und Anfragen beantworten. Ein Agent, der Fehlerberichte aufnimmt und einen Korrekturvorschlag vorbereitet, kann diese Wege verkürzen, aber nur dann, wenn die Prüfung am Ende zuverlässig stattfindet.

Was wir aus der Quelle ableiten können, ist begrenzt, deshalb formulieren wir vorsichtig. Die Quelle sagt, dass Teams Issues schneller in Korrekturen umsetzen können sollen. Sie nennt keine Zeitersparnis, keine Erfolgsquote und keine Messung. Wie oft ein vorgeschlagener Pull Request tatsächlich korrekt ist, wie viel Prüfaufwand er verursacht und für welche Art von Fehlern der Ablauf taugt, erfahren Sie aus dem Eintrag nicht. Das müssen Sie in Ihrem eigenen Code, mit Ihren eigenen Fehlern, beobachten.

Einige Überlegungen, die sich unabhängig von der Quelle für jede Einführung lohnen:

• Chat ist eine breite Tür. In einem Teams-Kanal lesen und schreiben oft viele Personen mit. Wenn aus einer Erwähnung eine Aktion im Code werden kann, stellt sich die Frage, wer überhaupt erwähnen darf. In einem Kanal mit Kolleginnen und Kollegen aus dem Vertrieb ist das eine andere Situation als in einem Kanal, den nur das Entwicklungsteam nutzt.
• Der Auslöser ist ungeprüfter Text. Ein Fehlerbericht stammt vielleicht von einem Kunden, einem Kollegen oder einem automatischen System. Er kann unvollständig, missverständlich oder falsch sein. Ein Agent, der auf Grundlage eines solchen Textes Code ändert, übernimmt auch dessen Unschärfe. Das ist kein Grund, ihn nicht einzusetzen, aber ein Grund, den Vorschlag nicht blind zu übernehmen.
• Ein Pull Request ist nur so gut wie seine Prüfung. Wenn in Ihrem Team Pull Requests bisher ohne zweites Augenpaar zusammengeführt werden, wird ein Agent, der mehr Vorschläge liefert, dieses Problem eher vergrößern als lösen.
• Zugriff muss bewusst vergeben werden. Die Quelle beschreibt, dass Sie ein Konto verbinden und ein Repository auswählen. Das ist der Moment, in dem Sie festlegen, auf welchen Code der Agent überhaupt Zugriff bekommt. Wählen Sie bewusst, und beginnen Sie mit einem unkritischen Repository.

Zu Fragen des Datenschutzes, etwa welche Chat-Inhalte an welchen Dienst übermittelt werden, enthält die Quelle keine Angaben, und wir haben sie nicht geprüft. Klären Sie diese Punkte vor einem Einsatz mit Ihrer Datenschutzbeauftragten oder Ihrem Datenschutzbeauftragten und anhand der Unterlagen von GitHub und Microsoft. Vor allem dann, wenn in Ihren Kanälen Kundendaten oder personenbezogene Angaben auftauchen können.

Warum der Prüfschritt der Kern ist

Man kann die Meldung aus zwei Blickwinkeln lesen. Im ersten ist sie eine Bequemlichkeit: Man muss das Werkzeug nicht mehr wechseln. Im zweiten ist sie eine Verschiebung von Verantwortung: Eine Aufgabe, die früher ein Mensch bewusst angenommen hat, kann jetzt durch eine Erwähnung in einem Chat angestoßen werden. Beide Lesarten sind zutreffend, und die zweite ist die, die ein Geschäftsführer im Blick behalten sollte.

Der Pull Request ist in diesem Ablauf die Stelle, an der die Verantwortung zurück zum Menschen wandert. Man kann ihn sich wie einen Entwurf vorstellen, der auf dem Tisch liegt und noch nicht versendet ist. Ob ein Entwurf gut ist, erkennt man erst, wenn jemand ihn liest. Deshalb gehören vier Dinge zu einem tragfähigen Ablauf:

• Lesbarkeit: Der Vorschlag muss so klein und verständlich sein, dass ein Mensch ihn in vertretbarer Zeit beurteilen kann.
• Tests: Die Quelle nennt ausdrücklich, dass das Team den Vorschlag testet. Ohne automatische Tests und einen Blick auf das Ergebnis ist die Prüfung bloß ein Lesen.
• Namentliche Verantwortung: Jemand bestätigt das Zusammenführen und ist damit für die Änderung verantwortlich, nicht der Agent.
• Nachvollziehbarkeit: Es bleibt erkennbar, wer den Vorgang ausgelöst hat, was vorgeschlagen wurde und wer es angenommen hat.

Ob die Funktion in Teams alle diese Punkte unterstützt, sagt die Quelle nicht. Sie beschreibt den Ablauf bis zum Pull Request und zur Prüfung durch das Team, nicht Rollen, Protokolle oder Berechtigungsmodelle. Wie Sie Branch-Schutz, verpflichtende Reviews und Berechtigungen in GitHub einstellen, ist Sache Ihrer Konfiguration, und diese Einstellungen bestehen unabhängig davon, ob ein Mensch oder ein Agent einen Vorschlag macht.

Welcher Agent bei Amazing Agents dafür zuständig wäre: der Code-Operator

Auf amazing-agents.com ist der Code-Operator einer der acht Agenten. Seine Beschreibung lautet: „Bugs, Fixes, Pull-Requests mit Ihrer Freigabe“. Das ist genau der Zuschnitt, den die GitHub-Ankündigung berührt: Fehler aufnehmen, Korrekturen vorbereiten, Pull Requests erstellen, und der Mensch gibt frei.

Wir möchten hier sorgfältig trennen. GitHubs Funktion in Teams ist ein Produkt von GitHub und Microsoft, kein Produkt von Amazing Agents. Wir behaupten nicht, sie sei Teil unseres Angebots. Die Einordnung als Code-Operator dient dazu, die Aufgabe zu beschreiben: Was ein Agent in diesem Bereich leisten kann und wo seine Grenze liegen sollte. Ein Fehlerbericht wird aufgenommen, ein Korrekturvorschlag entsteht, ein Mensch entscheidet.

Wir beschreiben ein Vorgehen, kein Ergebnis aus einem Kundenprojekt. In einem Audit würden wir mit Ihnen klären, welche Arten von Fehlern ein Agent überhaupt anfassen darf, etwa Rechtschreibfehler in Texten oder kleine, gut getestete Funktionen, und welche nicht, etwa Zahlungsabläufe, Berechtigungen oder Schnittstellen zu Kundensystemen. Dazu gehört auch die Festlegung, wer Vorschläge prüft, wie schnell das geschehen soll und was passiert, wenn niemand Zeit hat. Ein Vorschlag, der wochenlang offen bleibt, ist kein Fortschritt, sondern eine neue Warteschlange.

Auf der Webseite steht allgemein für alle Agenten: Jeder Agent läuft in einem definierten Rahmen mit Freigabe-Schritten bei kritischen Aktionen. Dieser Rahmen ist das, was einen Agenten für ein Unternehmen tragbar macht. Er ist keine Bremse, sondern die Voraussetzung dafür, dass Sie ihm überhaupt Aufgaben geben dürfen.

Agent mit Grenzen und Freigabe-Schritt: der Unterschied

Um den Unterschied greifbar zu machen, stellen wir zwei Abläufe nebeneinander. Es sind Gedankenspiele, keine Berichte aus Projekten.

Ohne Freigabe-Schritt: Ein Agent bekommt einen Fehlerbericht aus dem Chat, ändert den Code und übernimmt die Änderung direkt in die laufende Software. Ist der Bericht ungenau oder der Fix unvollständig, entsteht ein Folgefehler, der erst auffällt, wenn ein Kunde ihn meldet. Niemand hat die Änderung gesehen, und im Nachhinein ist unklar, wer sie veranlasst hat.

Mit Freigabe-Schritt: Der Agent erstellt einen Pull Request. Ein Mensch liest ihn, lässt die Tests laufen, schaut sich den Zusammenhang an und führt ihn erst dann zusammen. Wenn der Vorschlag nicht passt, wird er verworfen oder nachgebessert. Die Entscheidung hat einen Namen, und der Weg ist nachvollziehbar. Das kostet Zeit pro Vorschlag, spart aber die Zeit, die ein unbemerkter Folgefehler später verursachen würde.

Ein Agent mit Grenzen und Freigabe-Schritt arbeitet in diesem Sinn nicht gegen Sie, sondern für Sie, und er ist der Gegenentwurf zu dem Versprechen, die Software repariere sich selbst. Die Quelle beschreibt von sich aus die zweite Variante, denn der Pull Request und die Prüfung durch das Team sind Teil des Beispiels.

Was wir nicht wissen

• Die Lizenz: Ob für Copilot in Teams eine bestimmte Copilot-Lizenz oder ein bestimmter Tarif nötig ist, nennt die Quelle nicht.
• Die Region: Die Quelle nennt keine Einschränkung, belegt aber auch keine Verfügbarkeit für Deutschland, Österreich oder die Schweiz.
• Die Qualität: Wie häufig die vorgeschlagenen Korrekturen richtig sind und für welche Fehlerarten, steht nicht in der Quelle.
• Die Berechtigungen: Wer in Teams den Agenten beauftragen darf und welche Rechte im Repository dabei gelten, beschreibt der Eintrag nicht.
• Der Datenschutz: Welche Inhalte aus Chats verarbeitet werden, haben wir nicht geprüft.
• Das Jahr der Frist: Die Quelle nennt den 16. November ohne Jahreszahl.

Das sollten Sie diese Woche tun: drei Schritte

Weil die Funktion nach der Quelle bereits verfügbar ist, die Voraussetzungen aber offen sind, bestehen die Schritte aus Klären und Testen, nicht aus einem Einsatz im Tagesgeschäft.

1. Bestand prüfen: Fragen Sie Ihr Entwicklungsteam oder Ihren IT-Dienstleister, ob die bisherige GitHub-Benachrichtigungs-App in Teams im Einsatz ist. Wenn ja, planen Sie den Wechsel auf die neue App vor dem 16. November ein und bestimmen Sie, wer ihn durchführt.
2. Regeln festlegen: Schreiben Sie auf, wer @GitHub in welchen Kanälen verwenden darf, welche Repositories zugänglich sein sollen und dass jeder Pull Request von einer zweiten Person geprüft und getestet wird, bevor er zusammengeführt wird. Prüfen Sie, ob Branch-Schutz und verpflichtende Reviews in GitHub aktiv sind.
3. Klein testen: Wählen Sie ein unkritisches Repository und eine Handvoll einfacher Fehler. Beobachten Sie zwei Wochen lang, wie viele Vorschläge brauchbar sind, wie lange die Prüfung dauert und was Ihnen auffällt. Halten Sie das schriftlich fest, damit Sie danach auf Basis eigener Erfahrungen entscheiden.

Fazit

GitHub verlegt den Startpunkt eines Korrekturvorschlags in den Chat: Aus einem Fehlerbericht in Teams kann per Erwähnung ein Pull Request werden, den das Team prüft, testet und zusammenführt. Das ist eine nützliche Verkürzung des Weges, solange der letzte Schritt beim Menschen bleibt. Belegt ist laut Quelle der Ablauf, der Namenswechsel der App und die Abschaltung der alten App am 16. November. Nicht belegt sind Lizenzfragen, regionale Verfügbarkeit, Qualität der Vorschläge und Datenschutz.

Für Ihr Unternehmen heißt das: Nutzen Sie die Frist als Anlass, Zuständigkeiten zu klären, und probieren Sie die Funktion in kleinem Rahmen aus, bevor Sie sich darauf verlassen. Ein Agent mit Grenzen und Freigabe-Schritt ist eine Entlastung. Ein Agent ohne beides ist ein Risiko, das nur zufällig nicht auffällt.

Quelle: GitHub Changelog, „Turn notifications into code with GitHub Copilot in Teams“, 23. Oktober 2026 (github.blog/changelog/2026-10-23-turn-notifications-into-code-with-github-copilot-in-teams).