Inhaltsverzeichnis
In meinem letzten Beitrag "Vibe Coding" mit dem GitHub Copilot Agent habe ich die interaktive Zusammenarbeit mit dem Copilot direkt in der IDE beleuchtet. Diese synchrone Arbeitsweise ist extrem leistungsfähig, doch der GitHub Copilot Agent kann mehr. Es gibt eine zweite, ebenso mächtige Facette: asynchrone Agenten, die selbstständig und autonom Aufgaben im Hintergrund erledigen. Anstatt den Agenten im Dialog zu führen, weisen wir ihm ein GitHub Issue zu und überlassen ihm die komplette Umsetzung.
Der asynchrone CoPilot in Aktion
Das Konzept ist für Entwickler, die sich mit Automatisierung beschäftigen, sofort einleuchtend: Man erstellt ein detailliertes GitHub Issue, das ein Problem oder ein neues Feature beschreibt, und weist es per @github-copilot dem Agenten zu. Ab diesem Moment arbeitet er als vollwertiges Teammitglied asynchron an einer Lösung.
Für meine Tests habe ich dieses Szenario im Open-Source-Projekt n98-magerun2 angewendet. Voraussetzung war, dem Agenten in den Organisationseinstellungen die nötigen Berechtigungen zu geben, um Tickets bearbeiten und Pull Requests zur Überprüfung erstellen zu dürfen.
Der Prozess im Detail
Sobald der Auftrag erteilt ist, wird ein Premium Request verbraucht und der Agent beginnt seine Arbeit. Man wird darüber benachrichtigt und kann sich dann anderen Aufgaben widmen. Das ist der Kern des asynchronen Ansatzes: Der Entwickler wird nicht blockiert, sondern kann parallel weiterarbeiten.
Die Arbeit des Agenten ist dabei völlig transparent. Über einen Link kann man jederzeit eine Live-Session beobachten, die den Fortschritt in Echtzeit protokolliert. Man sieht jeden ausgeführten Befehl, jede Code-Änderung und jede Entscheidung, die der Agent trifft. So lässt sich genau nachvollziehen, wie er zur finalen Lösung gelangt, die er als Pull Request zur Verfügung stellt.
So sieht das fertige Ergebnis dann bei GitHub aus:
Der Agent als Code-Reviewer
Neben der autonomen Bearbeitung von Issues kann der GitHub Copilot Agent eine weitere zeitaufwändige Aufgabe übernehmen: Code-Reviews. Anstatt einen menschlichen Kollegen um eine Überprüfung zu bitten, kann man den Agenten einfach einem Pull Request als Reviewer zuweisen.
Der Prozess ist denkbar einfach: Man fügt den Agenten zur Reviewer-Liste eines Pull Requests hinzu. Genauso wie einen menschlichen Mitarbeiter. Wie bei der Bearbeitung von Issues arbeitet der Agent auch hier asynchron. Nach einer Weile analysiert er die vorgenommenen Änderungen und postet sein Ergebnis direkt als Review im Pull Request. Er kann auf potenzielle Fehler hinweisen, Verbesserungen vorschlagen und hilft dabei, die Code-Qualität konsistent hoch zu halten.
Wo arbeitet der Agent?
Ein fundamentaler Unterschied zur lokalen IDE-Nutzung ist die Ausführungsumgebung. Lokal greift der Copilot auf meine exakte Entwicklungsumgebung zu. Ein asynchroner Agent startet hingegen in einer standardisierten, sauberen Sandbox auf GitHub. Diese muss erst für die spezifischen Anforderungen des Projekts konfiguriert werden.
Hier kommt die Stärke der Integration mit GitHub Actions zum Tragen. Über eine Konfigurationsdatei unter .github/workflows/copilot-setup-steps.yml werden die notwendigen Schritte definiert, um die Sandbox vorzubereiten.
Der Aufbau dieser Datei ist identisch mit dem von GitHub Actions, was eine enorme Wiederverwendbarkeit ermöglicht. Wer bereits eine CI/CD-Pipeline im Einsatz hat, kann die dort definierten Setup-Schritte einfach kopieren und anpassen.
Typische Schritte in dieser Datei sind:
- Installation von Systemabhängigkeiten
- Setup der passenden Sprachversion (z.B. PHP, Node.js)
- Installation von Projekt-Abhängigkeiten (z.B. via Composer oder npm)
- Ausführung von Build- oder Initialisierungs-Skripten
Ein Beispiel für n98-magerun2 könnte so aussehen:
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Set up PHP
uses: shivammathur/setup-php@v2
with:
php-version: '8.2'
extensions: mbstring, xml, ctype, json, openssl
coverage: none
- name: Install Composer dependencies
run: composer install --prefer-dist --no-progress
Falls noch andere Dinge wie z.B. eine Magento Test-Umgebung fehlen, kann man diese ebenfalls über die gleiche Datei installieren (Zum Zeitpunkt dieses Blog-Beitrags habe ich diese Umgebung für n98-magerun2 noch nicht aufgesetzt).
Fazit
Die Fähigkeit des GitHub Copilot Agent, als asynchroner Entwicklungsassistent zu agieren, ist ein gewaltiger Schritt nach vorne. Es ermöglicht Entwicklern, klar definierte Aufgaben und Routinearbeiten an eine KI zu delegieren und sich selbst auf komplexere Probleme zu konzentrieren. Die enge Verzahnung mit dem GitHub Actions-Ökosystem macht die Konfiguration dabei effizient und konsistent. Aus meiner Sicht könnte dies auch die normale Tätigkeit eines Entwicklers werden. Man delegiert seine Arbeit einfach an viele Agenten, die dann arbeiten. Sobald die Agenten fertig sind, geht es nur noch darum evtuelle Verbesserungen wieder anzuweisen. Nur in seltenen Fällen schreibt man als Mensch noch selbst Code. Wieviele Agenten parallel arbeiten liegt an den techschnichen Ressourcen und den menschlichen Fähigkeiten mit so vielen "Kollegen" gleichzeitig umzugehen. Vermutlich ist das dann kein so richtiges "Vibe Coding" mehr und kann auch in Stress ausarten. Man wird sehen was die Zukunft für uns bringen wird.
Meine ersten Tests zeigen, dass der Agent eine wertvolle Ergänzung im Entwicklungsprozess ist. Für das erste bin ich relativ zufrieden mit der Arbeit der Agenten. Wichtig ist, dass wir den Agenten auch die passende Umgebung bereitstellen und wie immer einen guten Kontext liefern.