Agentenbasierte Entwicklung: Erste Erfahrungen mit GitHub Copilot Agent

René Adomeit  /  08.09.25  /  Digitale Transformation

 

KI-Modelle haben bereits bewiesen, dass sie Code vervollständigen und Entwickler bei Routineaufgaben unterstützen können. Doch nun stehen wir an der Schwelle zu einer neuen Ära: agentenbasierte Softwareentwicklung, bei der KI-gestützte Agenten aktiv in den Entwicklungsprozess eingreifen und eigenständig Aufgaben übernehmen. Was bedeutet das konkret und wie fühlt es sich an, mit einem solchen Agenten zusammenzuarbeiten?

In diesem Artikel berichten wir von unseren ersten Erfahrungen mit dem GitHub Copilot Agent und beleuchten, was heute schon möglich ist und wo die Grenzen sind.

Was ist ein KI-Coding-Agent?

Ein Agent im Kontext der Softwareentwicklung ist eine KI, die nicht nur einzelne Codezeilen oder Codeblöcke vorschlägt, sondern ganze Aufgaben im Alleingang erledigen kann. Man kann sich den Agenten als eine Art KI-Entwickler vorstellen, der ein Ticket oder eine Anforderung übernimmt, diese analysiert, Code schreibt, Tests ausführt und Pull Requests erstellt.

GitHub Copilot Agent ist ein prominentes Beispiel. Startet man eine Aufgabe mit diesem Agenten, indem man ihm ein Issue in Github zuweist, überprüft er zunächst das Repository und die Aufgabenstellung, erzeugt einen neuen Branch sowie einen Pull Request (PR) und beginnt mit der Implementierung. Anschließend kompiliert er den Code, führt die vorhandenen und neu erstellten Tests aus und validiert seine Änderungen. Ist er zufrieden, erstellt er zum Schluss eine detaillierte Beschreibung der vorgenommenen Änderungen inklusive Testergebnisse im PR.

Als Entwickler schlüpft man in die Rolle des Reviewers: Man begutachtet den PR, gibt Feedback, und der Agent kann ggf. weitere Änderungen vornehmen. Natürlich kann man den Code auch selbst nachbessern oder verwerfen.

Wie und wo arbeitet der Agent? Der Copilot Agent agiert in einer abgeschotteten Linux-Umgebung in der Cloud. Tatsächlich nutzt GitHub dafür sichere, kurzlebige Runner auf Ubuntu-Linux. Der Internetzugang ist über eine standardmäßig aktive Firewall eingeschränkt und Zugriffe nur auf Internetseiten in der Whitelist möglich.

Welche Lizenz wurde verwendet? Github Copilot Pro+. Diese erlaubt die Nutzung der neuesten Modelle, außerdem können Anfragen parallel gestellt werden und man erhält ein relativ großes Premium Request Budget.

Erste Erfahrungen mit GitHub Copilot Agent: Was lief gut?

Zum Testen wurde u.a. ein kleines .NET 8 Web-API-Projekt entworfen – eine Anwendung, die aus einem beliebig großen Text alle URLs extrahiert und per OpenAI-Integration für jeden Link eine kurze Zusammenfassung in einem vorgegebenen Format erstellt und diese strukturiert ablegt. Die Anforderungen wurden der KI nur grob in natürlicher Sprache beschrieben. Das Ergebnis war verblüffend positiv. Bemerkenswert war u.a.:

  • Automatische Projektstruktur & zusätzliche Assets: Der Agent hat auf Basis der vagen Beschreibung selbstständig eine sinnvolle Ordner- und Projektstruktur angelegt. Für die Web-API entstanden sofort die üblichen Verzeichnisse ohne Vorgabe, wie es aussehen soll. Darüber hinaus erstellte die KI ohne Aufforderung direkt Unit-Tests sowie eine verständliche README.md Dokumentation des Projekts.
    Für eine größere Enterprise-API wäre die Struktur nicht ausreichend, aber das war auch nicht gefordert.
  • Zusehen, wie die KI nachdenkt: Faszinierend ist, dass man dem Copilot Agent beim Arbeiten durch einen Klick auf „View Session“ in der Github PR Webseite zuschauen kann. Er beschreibt, welche Dateien er analysiert und editiert, welche Tests er laufen lässt, welche Kommandozeilen-Befehle er ausführt, worüber er gerade nachdenkt usw. Fast, als würde man einem Entwickler über die Schulter schauen.
  • Iteratives Verbessern möglich: War man mit einer Umsetzung nicht ganz zufrieden, konnte man den Agenten einfach nochmal nachbessern lassen. Gefiel uns z.B. die Formatierung der Ausgabe nicht oder wollten wir eine andere Benennung, haben wir das in einem Prompt rückgemeldet. Der Copilot Agent passt dann den Code entsprechend an – ähnlich wie ein menschlicher Entwickler auf Code-Review-Kommentare reagieren würde. Alternativ bleibt immer die Option, selbst Hand anzulegen.
  • Automatisch erstellte PR-Beschreibung: Nachdem der Agent seine Implementierung abgeschlossen hatte, erstellte er wie erwähnt einen Pull Request. Besonders beeindruckend war die ausführliche Beschreibung, die der Copilot Agent formulierte. Darin stand genau, was geändert wurde, welche neuen Dateien hinzugekommen sind, welche Tests durchgeführt wurden und dass alle Tests erfolgreich waren. Eine praktische Zusatzhilfe für den Reviewer.

Unerwartete Schwierigkeiten: Wo der Agent an seine Grenzen stieß

Reibungslos lief es allerdings nicht in jedem Fall:

  • Kurioser Bugfix-Versuch: Besonders lustig wurde es, als der Agent einen kleinen Bug beheben sollte. Statt das Problem zu lösen, entfernte er kurzerhand den gesamten Code des Features, in dem der Bug auftrat aus der Codebasis, inklusive der dazugehörigen Tests. Aus Sicht der KI war damit das Problem gelöst. Natürlich würde kein menschlicher Entwickler so vorgehen. In diesem Fall hätte ein Blick in die Dokumentation der verwendeten Drittbibliothek gereicht, um den Bug in ein paar Minuten korrekt zu beheben. Das zeigt auf jeden Fall, dass menschliche Validierung weiterhin unerlässlich ist.
  • Altprojekte: Ein weiterer Test verlief weniger erfolgreich. Wir wollten den Copilot Agent auf ein älteres, kleineres .NET-Framework 4.8 Legacy-API-Projekt loslassen, das nur unter Windows gebaut, getestet und gehostet werden kann. Hier stießen wir schnell an die Grenzen: Da der Agent sein eigenes Linux-basiertes Build-Environment nutzt, konnte er dieses Projekt gar nicht erst kompilieren, geschweige denn die Tests laufen lassen. Ohne lauffähige Build-Umgebung konnte der Agent seine Änderungen aber nicht überprüfen. Dementsprechend schlecht waren auch die Ergebnisse.

    Wir haben dann noch versucht, den Copilot Agent die komplette Migration des Projekts auf .NET 8 durchführen zu lassen. Der Agent war damit aber heillos überfordert, z.B. schaute er sich nicht einmal die vielen Fremd-Libraries an, die das Projekt nutzt. Diese müssten eigentlich alle einzeln nach ihrem jeweiligen Upgrade-Guide (wenn vorhanden) aktualisiert werden bzw., wenn sie nicht .NET 8-kompatibel sind, ersetzt werden. Fairerweise muss man sagen, dass ein menschlicher Entwickler für diese Migration voraussichtlich mehrere Tage benötigen würde.

    Dieses Experiment zeigt aber deutlich, dass je komplexer eine Anforderung ist, desto schwieriger wird es für den Agenten, diese umzusetzen.

    Das gleiche gilt wohl auch für die Größe und Komplexität der Code-Basis. Große Projekte werden den Agenten vermutlich schnell überfordern. Allerdings werden auch die Kontextfenster der LLMs immer größer.

Fazit: Wohin geht die Reise?

Die ersten Gehversuche mit agentenbasierter Softwareentwicklung waren insgesamt positiv. Der GitHub Copilot Agent hat in kurzer Zeit Code geschrieben, der auf Anhieb funktionierte, inklusive Tests und Dokumentation – etwas, das die Produktivität in kleinen Projekten spürbar steigert.

Klar ist aber auch: Dieser Ansatz steckt noch in den Kinderschuhen. Nicht jeder Issue wird von der KI so bearbeitet werden, wie wir es erwarten würden, und nicht jedes Projekt ist bereits in einem Zustand, dass ein Agent es übernehmen kann.

In Zukunft könnte ein großer Teil der Entwicklerarbeit darin bestehen, Anforderungen möglichst detailliert aufzunehmen, in klare Prompts zu übersetzen (je detaillierter, desto besser) inkl. z.B. Architekturvorgaben und die KI-Agenten zu orchestrieren. Der Entwickler setzt die KI-Tools ein, überwacht sie und stellt die Qualität sicher.

Es lohnt sich auf jeden Fall, schon jetzt mit diesen Agenten zu experimentieren. Die Technologie entwickelt sich rasant und was heute noch Limitierungen hat, könnte morgen schon deutlich leistungsfähiger sein.

Eines hat unser Erfahrungsbericht aber gezeigt: Ganz ohne den Menschen geht es (noch) nicht.

Links:

 

Artikel erstellt von René Adomeit

Github Copilot Agent Tests durchgeführt zusammen mit Steffen N., Michal R. und Dennis G.

 

Anmerkungen:

Für MCP Server Test war leider keine Zeit mehr.