Mit GitHub Copilot von Prompts zu mehr Produktivität

Dieser Artikel ist Teil der XPRT. Magazin Nr. 21

Einführung

Für viele Entwickler ist die erste Erfahrung mit KI im Editor zwar hilfreich, wirkt jedoch begrenzt.

Sie stellen eine Frage, erhalten eine Antwort, übernehmen einen Vorschlag und machen weiter. Vielleicht passen Sie eine Funktion an, erstellen einen Test oder bereinigen einen Codeabschnitt. Das ist zwar nützlich, kann sich aber dennoch wie eine Abfolge kleiner, unzusammenhängender Hilfestellungen anfühlen.

Die agentische Entwicklung verändert dies.

Anstatt nur bei einem einzelnen Schritt zu helfen, unterstützt die KI nun bei der gesamten Aufgabe. Ein Entwickler kann damit beginnen, die App von der KI überprüfen zu lassen, um zu verstehen, wie sie aufgebaut ist, mögliche Problemstellen zu identifizieren, Lösungsvorschläge zu erhalten, Tests hinzuzufügen oder zu aktualisieren, die vorgenommenen Änderungen zusammenzufassen und sogar die Arbeit für die Überprüfung vorzubereiten. Die Erfahrung fühlt sich zunehmend weniger so an, als würde man nach vereinzelten Antworten fragen, sondern eher so, als würde man mit einem Kollegen aus dem Entwicklungsteam zusammenarbeiten.

Diese Veränderung lässt sich anhand einer konkreten Anwendung besser nachvollziehen. In diesem Artikel dient „Movie Explorer“ als Beispiel. Die Anwendung bildet den Rahmen für einen praxisorientierten Bericht darüber, wie Entwickler die agentische Entwicklung von Anfang bis Ende einsetzen können. Der Weg beginnt mit der Erkundung: dem Verstehen der Struktur der App, der Hauptkomponenten und der Art und Weise, wie die einzelnen Teile zusammenpassen. Von dort aus geht der Arbeitsablauf weiter zur Behebung eines Fehlers, zur Validierung des Ergebnisses durch Tests und schließlich zur Erweiterung auf größere Aufgaben, die an den Coding Agent in der Cloud übergeben werden können, sobald der Arbeitsaufwand über eine schnelle lokale Änderung hinausgeht.

Dieser durchgängige Arbeitsablauf ist der eigentliche Kernpunkt. Der Mehrwert besteht nicht nur darin, dass KI Code vorschlagen kann. Der Mehrwert liegt vielmehr darin, dass sie dazu beitragen kann, die Dynamik durch den gesamten Entwicklungsprozess hindurch aufrechtzuerhalten. Die Entwickler entscheiden nach wie vor, was wichtig ist, wie ein gutes Ergebnis aussieht und ob das Ergebnis tatsächlich korrekt ist. Doch anstatt jeden kleinen Schritt manuell zu steuern, können sie mithilfe der agentenbasierten Entwicklung mit deutlich weniger Reibungsverlusten von der Untersuchung über die Umsetzung bis hin zur Validierung voranschreiten.

Die meisten Entwickler benötigen KI nicht nur zur Generierung von Code auf einer leeren Seite. Sie benötigen Unterstützung bei den Aufgaben, die einen normalen Arbeitstag ausfüllen: das Verstehen eines unbekannten Teils einer Anwendung, das Nachverfolgen von Verhaltensweisen, das Vornehmen einer sicheren Änderung, das Überprüfen, ob dadurch keine anderen Probleme entstanden sind, sowie das Aufbereiten der Arbeit in einer Form, die zur Überprüfung bereit ist.

Anstatt KI also als ein intelligenteres Tool zur automatischen Vervollständigung zu betrachten, befasst sich dieser Artikel mit einem praktischeren Modell, bei dem GitHub Copilot als aktiver Partner im Arbeitsablauf eingesetzt wird. Wir beginnen in VS Code, wo Entwickler den Agent-Modus nutzen können, um über mehrere Schritte hinweg zu prüfen, zu analysieren und zu handeln. Anschließend entwickeln wir eine umfassendere Strategie weiter, bei der wir wissen, wann die Arbeit lokal verbleiben sollte und wann der Coding Agent in der Cloud für umfangreichere oder länger andauernde Aufgaben eingesetzt werden sollte.

Ab diesem Zeitpunkt wirkt GitHub Copilot plötzlich anders – nicht mehr nur als Hilfsmittel für Eingabeaufforderungen, sondern als Teammitglied bei der Entwicklung.

Was ändert sich in VS Code, wenn Sie in den Agent-Modus wechseln?

Die nächste Frage liegt auf der Hand.

Was ändert sich tatsächlich, wenn ein Entwickler von einer normalen GitHub-Copilot-Chat-Erfahrung zu einer agentenbasierten wechselt?

Auf den ersten Blick nicht viel. Sie befinden sich nach wie vor in VS Code. Sie haben nach wie vor ein Eingabefeld. Sie kommunizieren nach wie vor mit GitHub Copilot. Aus diesem Grund übersehen viele Entwickler die Veränderung, wenn sie sie zum ersten Mal wahrnehmen. Es sieht vertraut aus, doch die Arbeitsweise ist eine andere.

Bei einem eher traditionellen Chat-Ablauf verläuft die Interaktion größtenteils im dialogischen Stil. Sie bitten um Hilfe, GitHub Copilot antwortet, und Sie entscheiden, wie Sie mit der Antwort verfahren möchten. Das funktioniert gut, wenn Sie eine Erklärung, eine schnelle Anleitung oder Unterstützung beim Durchdenken eines Problems benötigen, bevor Sie selbst Änderungen vornehmen. Der Agent-Modus verändert die Art der Interaktion.

Der „Ask“-Modus hilft Ihnen beim Nachdenken. Der „Agent“-Modus hilft Ihnen beim Handeln.

Diese Unterscheidung ist wichtiger, als es auf den ersten Blick erscheint. Ein Entwickler, der mit dem Movie Explorer arbeitet, beginnt möglicherweise mit einfachen Fragen: Welche Teile der App sind für Routing, Status, Persistenz und Tests zuständig? Wo würde ein Problem mit der Benutzeroberfläche am ehesten auftreten? Wo ist der sicherste Ansatzpunkt für die Analyse? Diese Art der Erkundung ist nach wie vor Teil der Arbeit und oft der klügste erste Schritt.

Sobald der Entwickler über genügend Kontext verfügt, ändert sich das Ziel. Er hat ein Bild von der App im Kopf. Er weiß, welches Verhalten er korrigieren möchte. Nun möchte er, dass GitHub Copilot mehr tut, als nur Fragen zu beantworten. Er möchte, dass es Nachforschungen anstellt, Änderungsvorschläge unterbreitet, Tests erstellt oder aktualisiert und dabei hilft, die Aufgabe auf nahtlose Weise voranzubringen.

An dieser Stelle beginnt der Agent-Modus, seinen Platz im Arbeitsablauf einzunehmen.

Der wichtigste Unterschied besteht darin, dass der Arbeitsumfang größer wird. Anstatt um einen einzelnen, isolierten Vorschlag zu bitten, kann der Entwickler die Aufgabe in einfacher Sprache beschreiben und GitHub Copilot mehrere Schritte gleichzeitig bearbeiten lassen. Anstatt separat nach Diagnose, Code, Tests und Erläuterungen zu fragen, kann der Entwickler das gewünschte Gesamtergebnis formulieren.

Das verändert den Arbeitsrhythmus. Anstatt die Aufgabe in eine Reihe unzusammenhängender Eingabeaufforderungen aufzuteilen, behält der Entwickler den Schwung bei. Er bleibt in einem einzigen Arbeitsablauf. Das ist nicht nur schneller, sondern auch übersichtlicher. Eine aussagekräftigere Eingabeanweisung reduziert unnötiges Hin und Her mit dem Modell, was bedeutet, dass weniger Zeit für die erneute Erläuterung des Kontexts aufgewendet wird und weniger wertvolle Anfragen verschwendet werden, um einen unklaren Anfang wieder auszugleichen.

Es gibt noch einen weiteren Aspekt, der an Bedeutung gewinnt, sobald der Arbeitsablauf stärker agentisch geprägt ist.

Sobald ein Entwickler möchte, dass GitHub Copilot über die gerade bearbeitete Datei hinaus funktioniert, reicht der Kontext allein nicht mehr aus. Es bedarf weiterer Werkzeuge. An dieser Stelle wird die GitHub-Anbindung zu einem integralen Bestandteil der Arbeitserfahrung. Anstatt den Editor und das Repository als getrennte Welten zu betrachten, kann der Arbeitsablauf damit beginnen, lokale Arbeit mit Issues, Pull-Anfragen und Überprüfungsaktivitäten zu verknüpfen.

Das Ziel besteht nicht lediglich darin, dass die KI Code schneller generiert. Das Ziel ist es, die Dynamik während der gesamten Aufgabe aufrechtzuerhalten.

Ein Entwickler kann zunächst den Movie Explorer lokal untersuchen. Sobald er bereit ist, Maßnahmen zu ergreifen, kann er in den Agent-Modus wechseln. Zur Validierung der Arbeit kann er Playwright nutzen. Sobald die Aufgabe dann umfangreicher wird oder mit mehr Rechenkapazität besser bewältigt werden kann, kann er sie weitergeben.

An dieser Stelle kommt „Coding Agent“ in der Cloud ins Spiel.

Ich betrachte den „Agent-Modus“ und den „Coding Agent“ als zwei Teile desselben Ganzen. Der „Agent-Modus“ steht für die Zusammenarbeit zwischen dem Entwickler und GitHub Copilot im Editor – nah am Code, nah am Browser und nah an der schnellen Validierung. „Coding Agent“ ist das, worauf Sie zurückgreifen, wenn eine Aufgabe mehr Zeit erfordert, wenn Sie Arbeit delegieren und weiterlaufen lassen möchten, während der bereits aufgebaute Kontext erhalten bleibt.

Diese Aufgabenteilung ist wichtig, da nicht jede Aufgabe auf dieselbe Weise bearbeitet werden sollte. Manche Aufgaben erfordern genaues Lesen und schnelle Korrekturen, und diese sollten vor Ort erledigt werden. Andere Aufgaben erfordern wiederholte Überarbeitungen, Geduld und Zeit – und genau hier macht die cloudbasierte Delegation Sinn.

Dies ist das Muster, das wir für den Movie Explorer verwenden werden. Beginnen Sie mit dem Verstehen. Wechseln Sie in den Agent-Modus, sobald Sie bereit sind, Maßnahmen zu ergreifen. Bleiben Sie lokal, wenn die Aufgabe fokussiert ist. Übergeben Sie umfangreichere, klar abgegrenzte Aufgaben an den Coding Agent, wenn die Arbeit über Ihre unmittelbare Bearbeitungssitzung hinaus fortgesetzt werden soll.

Erste Schritte mit der Suche im Movie Explorer

Bevor ein Entwickler GitHub Copilot bittet, etwas zu korrigieren, gibt es einen vorhergehenden Schritt, der wichtiger ist, als es auf den ersten Blick erscheinen mag.

Sie müssen die App verstehen, und genau hier kommt die Erkundungsphase ins Spiel.

In einer realen Codebasis besteht einer der häufigsten Fehler darin, sich zu schnell auf eine Lösung zu stürzen. Ein Entwickler bemerkt, dass etwas nicht stimmt, öffnet die erste Datei, die relevant erscheint, und beginnt mit Änderungen, bevor er vollständig verstanden hat, wie das Verhalten zusammenhängt. Später stellt er fest, dass das Problem mehr als einen Teil der Anwendung betrifft. Movie Explorer ist ein gutes Beispiel hierfür. Auf den ersten Blick wirkt es überschaubar, enthält jedoch genügend komplexe Komponenten, sodass eine übereilte Änderung leicht an der falschen Stelle landen kann. Movie Explorer umfasst mehrere zustandsabhängige Verhaltensweisen und benutzerseitige Interaktionen, weshalb ein frühzeitiges Verständnis besonders wichtig ist.

Ein Entwickler könnte damit beginnen, die App so zu prüfen, wie es ein Nutzer tun würde. Öffnen Sie sie im Browser. Klicken Sie sich durch die wichtigsten Abläufe. Beobachten Sie, wie sich die App verhält. Achten Sie darauf, was sich flüssig anfühlt, was inkonsistent wirkt und wo das Verhalten möglicherweise davon abhängt, dass der Status über Bildschirme oder Sitzungen hinweg beibehalten wird.

Entdeckung ist keine Zeit, die man vor der eigentlichen Arbeit verbringt, sondern sie ist Teil der eigentlichen Arbeit.

Bei „Movie Explorer“ ist das Ziel in dieser Phase einfach: Erstellen Sie sich ein mentales Modell davon, wie die App aufgebaut ist. Welche Pfade prägen die Benutzererfahrung? Wo werden möglicherweise gemeinsame Verhaltensweisen initialisiert? Welche Dateien scheinen für das Verhalten der App von zentraler Bedeutung zu sein? Da „Movie Explorer“ Herausforderungen im Bereich der Zustandsverwaltung mit sich bringt, ist dieses Verständnis vor der Durchführung einer Änderung umso wichtiger.

Hier erweist sich GitHub Copilot auf sehr praktische Weise als nützlich – nicht, weil es bereits Code schreibt, sondern weil es dem Entwickler hilft, die Zusammenhänge schneller zu verstehen.

Anstatt Datei für Datei manuell zu öffnen und alles eigenhändig zusammenzusetzen, kann der Entwickler GitHub Copilot bitten, die Struktur in einfacher Sprache zu erläutern. Welche Komponenten scheinen die Benutzererfahrung zu steuern? Wo der Zustand offenbar beginnt. Welche Dateien am ehesten mit dem beobachteten Verhalten in Verbindung stehen (z. B.: „Welche Dateien sind in dieser App für die Persistenz des Themes und den lokalen Speicher zuständig?“). Dadurch wird GitHub Copilot zu etwas Wertvollerem als einem bloßen Codegenerator. Es wird zu einem Teamkollegen, der dem Entwickler hilft, sich zurechtzufinden.

Eine gut formulierte Abfrage spart doppelt Zeit. Sie verkürzt den Weg zum Verständnis und verringert die Wahrscheinlichkeit, dass das falsche Problem gelöst wird. Zudem reduziert sie unnötige Hin- und Her-Kommunikation mit dem Modell. Ist die erste Eingabeanweisung fundiert und konkret, ist es weniger wahrscheinlich, dass der Entwickler zusätzliche Zeit und zusätzliche Premium-Anfragen verschwendet, indem er Folgefragen stellt, die mit einem besseren Kontext von vornherein hätten vermieden werden können.

Das verändert die Qualität all dessen, was danach folgt. Ein Entwickler, der mit einer Bestandsaufnahme beginnt, kann eine wesentlich fundiertere Eingabeformulierung verfassen, wenn es an der Zeit ist, zu handeln. Er weiß, welche Dateien wahrscheinlich betroffen sind. Er weiß, ob die Änderung wahrscheinlich isoliert ist oder sich über mehrere Teile der Anwendung erstreckt. Er weiß, welches Verhalten während der Arbeit beibehalten werden muss. Er gibt seine Eingaben nicht mehr im Blindflug ein.

Das ist einer der praktischsten Vorteile dieser Art der Nutzung von GitHub Copilot. Die KI dient nicht nur dazu, Ergebnisse zu generieren. Sie soll dem Entwickler dabei helfen, schneller einen Kontext aufzubauen, und genau dieser Kontext sorgt dafür, dass die nachfolgenden Schritte effektiver werden. Je besser das Verständnis, desto besser die Eingabeaufforderungen. Je besser die Eingabeaufforderungen, desto besser kann GitHub Copilot als Teamkollege beitragen.

Movie Explorer bietet hierfür eine solide Grundlage, da es genau die Art von Anwendung widerspiegelt, die Entwickler auf Anhieb erkennen. Es verfügt über ein modernes Frontend, vernetztes Anwendungsverhalten sowie ausreichende Zustands- und Persistenzfunktionen, sodass es sich lohnt, die Anwendung zu erkunden, bevor Änderungen vorgenommen werden. Es geht nicht um Komplexität um ihrer selbst willen. Der springende Punkt ist, dass es sich wie eine Anwendung anfühlt, bei der es darauf ankommt, den Ablauf zu verstehen.

Bei der Entdeckungsphase geht es also nicht wirklich darum, das Tempo zu drosseln, sondern darum, eine bessere Dynamik aufzubauen.

Öffnen Sie die App. Betrachten Sie sie aus der Perspektive eines Nutzers. Bitten Sie GitHub Copilot, sich einen Überblick zu verschaffen. Ermitteln Sie die relevanten Dateien. Verschaffen Sie sich Klarheit darüber, wo das betreffende Verhalten wahrscheinlich zu finden ist. Gehen Sie dann zielgerichtet vor.

Sobald der Entwickler die Funktionsweise von Movie Explorer verstanden hat, fällt der nächste Schritt wesentlich leichter. Nun kann GitHub Copilot dabei helfen, vom Verständnis zur Umsetzung überzugehen, eine gezielte Korrektur vorzunehmen, diese mit Playwright zu validieren und sicherzustellen, dass das Ergebnis den Anforderungen entspricht.

Mit dem Agent-Modus und Playwright von der Fehlerbehebung zur Validierung übergehen

Die Erkundung gibt einem Entwickler Orientierung und das nötige Selbstvertrauen zum Handeln.

An diesem Punkt hört GitHub Copilot auf, dem Entwickler dabei zu helfen, die Anwendung zu verstehen, und beginnt stattdessen, ihm bei deren Änderung zu helfen. Im „Movie Explorer“ bedeutet dies in der Regel, ein Problem aufzugreifen, das einem Nutzer auffallen würde – beispielsweise ein Verhalten, das bei Aktualisierungen, bei der Navigation oder bei wiederholten Interaktionen nicht konsistent bleibt –, und daraus eine gezielte technische Aufgabe zu machen, die zuverlässig behoben, getestet und überprüft werden kann. Der Movie Explorer eignet sich gut für diese Art von Fallbeispielen, da er genau die Probleme umfasst, mit denen Frontend-Entwickler im Arbeitsalltag konfrontiert sind, darunter Persistenzprobleme, zeitabhängiges Verhalten und Instabilitäten bei Tests.

An dieser Stelle beginnt sich der Agent-Modus von einer normalen Chat-Interaktion zu unterscheiden.

Ein Entwickler bittet GitHub Copilot nicht mehr nur um einen einzelnen Vorschlag. Er beschreibt vielmehr eine Aufgabe. Untersuchen Sie das Problem, beheben Sie den Fehler, fügen Sie Tests hinzu, die die Korrektur bestätigen, und erläutern Sie, was sich geändert hat. Der Mehrwert liegt nicht nur in der Geschwindigkeit, sondern auch in der Kontinuität. Ein und derselbe rote Faden kann sich von der Diagnose über die Umsetzung bis hin zur Validierung ziehen, anstatt den Entwickler zu zwingen, die Kommunikation bei jedem Schritt neu zu beginnen.

Anstatt die Aufgabe in ein Dutzend unzusammenhängende Eingabeaufforderungen aufzuteilen, kann der Entwickler das gewünschte Ergebnis formulieren und GitHub Copilot dabei helfen lassen, dieses umzusetzen. Je besser die anfängliche Formulierung, desto reibungsloser verläuft die Ausführung.

Movie Explorer liefert hierfür ein praktisches Beispiel anhand einer Korrektur, bei der es um die Beibehaltung des Designs geht. Das Problem selbst ist aus Sicht des Benutzers leicht nachvollziehbar: Die App sollte sich das ausgewählte Design merken und die Benutzererfahrung auch nach dem Neuladen und beim Navigieren konsistent halten. Entscheidend sind hier nicht die genauen Implementierungsdetails. Entscheidend ist vielmehr, wie der Entwickler die Aufgabe mit GitHub Copilot als Teamkollegen angeht. GitHub Copilot kann beauftragt werden, die Ursache zu untersuchen, die Korrektur umzusetzen, eine gezielte Playwright-Abdeckung zu erstellen und nach Abschluss der Arbeit die Grundursache sowie die Lösung zu erläutern.

Das ist eine weitaus bessere Arbeitseinheit. Sie spiegelt wider, wie Entwickler tatsächlich denken, wenn sie für eine Fehlerbehebung verantwortlich sind. Sie wollen nicht nur Code, der plausibel aussieht. Sie wollen, dass das Verhalten korrigiert, das Risiko verringert und das Ergebnis durch Belege untermauert wird.

An dieser Stelle wird Playwright Teil der Geschichte – nicht als nachträglicher Einfall, sondern als Partner des Agent-Modus.

Eine Fehlerbehebung ist nur die halbe Miete. Die andere Hälfte besteht darin, nachzuweisen, dass die Lösung auch hält, was sie verspricht. In Movie Explorer überprüft Playwright das sichtbare Verhalten, die Beständigkeit bei Neuladungen und den Ablauf bei der Navigation – und nicht nur, ob sich zufällig ein interner Zustand geändert hat. Die aussagekräftigsten Tests überprüfen das Verhalten, das der Benutzer tatsächlich beobachten kann, und decken jene Randbedingungen ab, bei denen es im Zuge der Weiterentwicklung des Codes am ehesten zu Fehlern kommen kann.

Eine Korrektur, die auf den ersten Blick einwandfrei erscheint, kann dennoch genau an der Stelle versagen, auf die es den Nutzern am meisten ankommt. Eine Schaltfläche wird korrekt angezeigt, bis die Seite aktualisiert wird. Eine Einstellung scheint gespeichert zu sein, bis sie durch die Navigation zurückgesetzt wird. Eine Funktion funktioniert einmal, aber nicht zweimal. Playwright schließt diese Lücke, indem es die Validierung in den Browser verlagert, wo sich das Verhalten unter realistischen Nutzungsbedingungen bewähren muss.

GitHub Copilot fügt sich nahtlos in diesen Kreislauf ein. Der Entwickler kann GitHub Copilot nicht nur bitten, die Codeänderung vorzunehmen, sondern auch eine kleine Auswahl gezielter Playwright-Tests zu generieren, die dem erwarteten Verhalten entsprechen. Im Movie Explorer umfasst dies die Validierung dessen, was der Benutzer sieht, die Überprüfung der Persistenz nach dem Neuladen sowie die Bestätigung, dass das Verhalten auch bei Routenänderungen erhalten bleibt. Das Ergebnis ist keine riesige Flut generierten Testcodes, sondern ein straffer, zielgerichteterer Validierungsdurchlauf, der auf derselben Absicht basiert wie die Korrektur selbst.

Genau hier beginnt GitHub Copilot, sich wie ein echter Teamkollege anzufühlen. Es hilft dem Entwickler nicht nur dabei, schneller zu schreiben. Es unterstützt ihn dabei, in vollständigen Arbeitseinheiten zu denken: Worin besteht das Problem, wie sollte das Ergebnis aussehen, wie lassen sich die Ergebnisse belegen und welche Erläuterungen benötigt der nächste Prüfer?

Dies hat noch einen weiteren Vorteil: Dadurch bleibt die Änderung nachvollziehbar.

Eine gezielte Korrektur mit fokussierter Playwright-Abdeckung ist leichter zu verstehen, leichter zu überprüfen und weckt mehr Vertrauen. Selbst wenn GitHub Copilot einen Großteil der Arbeit übernimmt, behält der Entwickler weiterhin die Kontrolle darüber, was beibehalten, was überarbeitet wird und ob der resultierende Diff tatsächlich in das Repository aufgenommen werden soll.

Dies ist das Muster, das es zu beachten gilt. Ein Entwickler beobachtet das Verhalten, definiert die Aufgabe klar und präzise, lässt GitHub Copilot den gesamten Code und die Tests durcharbeiten und überprüft anschließend das Ergebnis im Browser und im Testrunner. Das ist eine ganz andere Erfahrung als wenn man nach einem Code-Schnipsel fragt, diesen in eine Datei einfügt und auf das Beste hofft.

Sobald dieser Rhythmus sitzt, liegt der nächste Schritt auf der Hand. Wenn GitHub Copilot einem Entwickler dabei helfen kann, bei einer konkreten Aufgabe nahtlos vom Verständnis über die Behebung bis hin zur Validierung zu gelangen – was geschieht dann, wenn der Arbeitsumfang über eine einzelne konkrete Aufgabe hinausgeht? Was geschieht, wenn die Aufgabe ein eigenes Issue, einen eigenen Branch, einen vorläufigen Pull-Request und mehr Spielraum für die Umsetzung verdient?

Wenn der Auftrag umfangreicher wird, übergeben Sie ihn an Coding Agent

Es gibt einen Punkt, an dem ein Entwickler spürt, dass sich die Aufgabe ausweitet.

Eine gezielte Korrektur ist eine Sache. Das können Sie lokal erledigen. Sie können in VS Code bleiben, Seite an Seite mit GitHub Copilot arbeiten, die Anwendung ausführen, das Verhalten überprüfen und das Ergebnis optimieren, bevor Sie fortfahren.

Doch manchmal ist die Aufgabe umfangreicher als das.

Es handelt sich nicht mehr nur um eine Korrektur, sondern um einen Feature-Wunsch. Dies kann mehrere Dateien betreffen, sich über Frontend und Backend erstrecken, neue Interaktionen mit sich bringen und genügend Raum für die Weiterentwicklung benötigen, bevor es zur Überprüfung bereit ist. An dieser Stelle ändert sich der Arbeitsablauf erneut – nicht, weil sich der Entwickler zurückzieht, sondern weil diese Art von Arbeit nun eine andere Art der Zusammenarbeit mit den Teammitgliedern erfordert.

An dieser Stelle wird der Nutzen von Coding Agent deutlich.

Bei Movie Explorer könnte eine umfangreichere Anforderung beispielsweise darin bestehen, die Benutzererfahrung im Zusammenhang mit Filmdetails zu verbessern, eine Wunschliste-Funktion hinzuzufügen oder eine ausgefeiltere Interaktion einzuführen, die das Verhalten der Benutzeroberfläche, den Datenfluss und die Validierung umfasst. Dabei handelt es sich nicht um Änderungen an einer einzigen Datei. Es handelt sich um Änderungen, bei denen ein klar beschriebenes Problem, explizite Akzeptanzkriterien und ein Bearbeiter von Vorteil sind, der diese Arbeit übernehmen, einen Zweig anlegen und einen vorläufigen Pull-Request zur Überprüfung durch den Entwickler erstellen kann.

Der Entwickler fragt nicht mehr: „Kann GitHub Copilot mir beim Schreiben dieses Codes helfen?“, sondern: „Kann GitHub Copilot mir dabei helfen, diese Funktion bis zu ihrer ersten sinnvollen Entwicklungsstufe voranzubringen?“

Das ist eine bessere Frage. Dabei wird GitHub Copilot weniger als Schreibassistent, sondern vielmehr als Teamkollege betrachtet, der die Verantwortung für eine klar abgegrenzte Aufgabe übernehmen kann. Das Ziel legt weiterhin der Entwickler fest. Der Entwickler entscheidet nach wie vor, wie das Ergebnis aussehen soll. Doch anstatt jede Datei und jeden Schritt manuell vorzubereiten, erteilt er GitHub Copilot einen klaren Auftrag und überprüft das Ergebnis gezielt.

Klarheit ist hier von großer Bedeutung. Wenn Sie umfangreichere Aufgaben delegieren, führt eine vage Spezifikation zu einem höheren Nacharbeitsaufwand. Eine gut formulierte Aufgabenstellung gibt GitHub Copilot ein klares Ziel, klare Grenzen und eine klare Definition dessen, was als „erledigt“ gilt. Dies hilft dem System, sicherer vorzugehen, und bietet dem Entwickler einen besseren Ausgangspunkt, wenn der Entwurf des Pull-Requests eintrifft.

„Movie Explorer“ liefert hierfür ein gutes Beispiel, da das Gesamtprojekt nicht als Zauberei, sondern als strukturierte Technik dargestellt wird. Das Problem gibt die Richtung vor, der Entwickler folgt diesem Weg, und es wird ein Zweig erstellt. Die Änderungen werden in der gesamten Anwendung sichtbar. Ein Entwurf für einen Pull-Request erscheint. Anschließend kehrt der Entwickler zur Mitte der Story zurück, nicht zu deren Ende. Er lädt den Zweig weiterhin lokal herunter, untersucht die Implementierung im Browser, führt Tests durch und entscheidet, was angepasst werden muss, bevor etwas zusammengeführt wird.

Bei „Coding Agent“ geht es nicht darum, die Kontrolle abzugeben, sondern darum, den Schwerpunkt der Arbeit zu verlagern.

Anstatt die erste Zeiteinheit damit zu verbringen, die anfängliche Implementierung aufzubauen und zu verknüpfen, kann der Entwickler diese Energie darauf verwenden, die Struktur der Arbeit zu überprüfen, festzustellen, ob die Akzeptanzkriterien tatsächlich erfüllt wurden, das Ergebnis im Browser zu validieren und alle Entscheidungen zu treffen, die der Agent nicht treffen konnte. Dies ist eine bessere Nutzung der Zeit eines erfahrenen Entwicklers.

Der Movie Explorer trägt dazu bei, dies in die Praxis umzusetzen, da die Beispiele naturgemäß mehrere Dateien und Verhaltensweisen umfassen. Ein umfangreicheres Anliegen in der App konzentriert sich auf die Verbesserung der Benutzererfahrung über die gesamte Benutzeroberfläche hinweg, wobei bestehende Funktionen wie Favoriten, Suche, Paginierung und die Beibehaltung des Designs erhalten bleiben sollen. Ein weiterer Schwerpunkt liegt auf der Einführung einer Beobachtungslisten-Funktion. In beiden Fällen ist die Idee dieselbe: Der Arbeitsumfang ist groß genug, um von einer umfassenden Übergabe an GitHub Copilot zu profitieren, aber dennoch so begrenzt, dass der Entwickler die Ergebnisse sinnvoll überprüfen kann, wenn sie zurückkommen.

Genau in dieser Balance liegt die größte Stärke von Coding Agent – nicht bei jeder Aufgabe und nicht bei vagen Zielen, sondern bei konkreten Aufgaben, die bereits so weit konkretisiert sind, dass sie delegiert werden können.

Hinter all dem verbirgt sich eine praktische Regel: Führen Sie kleine, zügig durchzuführende Reparaturen vor Ort durch. Überlassen Sie größere, klar abgegrenzte Funktionsarbeiten dem Coding Agent. Dies verbessert nicht nur den Arbeitsablauf, sondern auch die Entscheidungsfindung.

Wenn Entwickler GitHub Copilot auf diese Weise nutzen, zwingen sie nicht mehr jede Aufgabe in dieselbe Form. Sie wählen den Arbeitsstil, der zur jeweiligen Aufgabe passt. Manche Aufgaben erfordern eine enge Zusammenarbeit im Editor. Andere Aufgaben profitieren von einer eher asynchronen Übergabe. Es geht nicht darum, den Assistenten überall einzusetzen. Es geht darum, ihn dort einzusetzen, wo er am meisten hilft.

Genau das sorgt dafür, dass sich GitHub Copilot eher wie ein Teamkollege anfühlt als wie eine bloße Spielerei. Ein Teamkollege muss nicht alles erledigen. Ein Teamkollege hilft dabei, die richtigen Aufgaben auf die richtige Weise voranzubringen.

Sobald diese umfangreichere Funktion als Entwurf eines Pull-Requests vorliegt, kehrt der Entwickler zu denselben Standards zurück, die zuvor bereits galten. Überprüfen Sie die Arbeit. Führen Sie sie aus. Testen Sie sie. Vergewissern Sie sich, dass sie zur App passt. Vergewissern Sie sich, dass die Qualität stimmt. Entscheiden Sie dann, ob sie bereit ist.

Die endgültige Entscheidung liegt nach wie vor beim Entwickler, und das ist auch gut so.

Denn die beste Variante dieses Arbeitsablaufs besteht nicht darin, dass die KI die Ingenieursdisziplin ersetzt. Vielmehr verleiht die KI dieser Disziplin neuen Schwung.

Bewährte Vorgehensweisen: KI als Teamkollege einsetzen

An dieser Stelle der Geschichte ist das Muster bereits deutlich erkennbar. GitHub Copilot ist am nützlichsten, wenn man es wie einen Teamkollegen behandelt und nicht als Abkürzung betrachtet.

Das klingt einfach, verändert jedoch die Arbeitsweise eines Entwicklers. Eine Abkürzung nutzt man, wenn man sich Mühe ersparen möchte. Ein Teamkollege ist jemand, mit dem man zusammenarbeitet, wenn man bessere Ergebnisse erzielen möchte. Das ist nicht dasselbe.

Beginnen Sie mit einer klar definierten Aufgabe.

GitHub Copilot liefert bessere Ergebnisse, wenn der Entwickler ihm eine klar abgegrenzte Aufgabe mit Kontext, Einschränkungen und einer sichtbaren Definition des Erfolgs vorgibt. Das könnte bedeuten, dass man das Tool bittet, die Struktur von „Movie Explorer“ zu verstehen, bevor es sich an den Code macht. Es könnte bedeuten, das Programm zu beauftragen, ein bestimmtes Verhalten zu beheben und eine Playwright-Abdeckung hinzuzufügen, die belegt, dass die Korrektur funktioniert. Es könnte bedeuten, eine Feature-Anforderung mit klaren Akzeptanzkriterien zu verfassen, bevor man sie an den Coding Agent übergibt. In jedem Fall verbessert Klarheit das Ergebnis. Außerdem werden dadurch unnötige Hin- und Her-Prozesse reduziert, was weniger Zeitverschwendung und einen geringeren Verbrauch an Premium-Anfragen bedeutet.

Wählen Sie die Arbeitsweise, die zur jeweiligen Aufgabe passt.

Bestimmte Arbeiten sollten im Editor im GitHub Copilot-Agent-Modus durchgeführt werden. Dies ist in der Regel der richtige Ort für die Erkennung von Problemen, die Diagnose, gezielte Korrekturen und enge Feedbackschleifen, wobei der Browser und der Testrunner in unmittelbarer Nähe zur Verfügung stehen. Andere Arbeiten eignen sich besser für den Coding Agent, insbesondere wenn die Aufgabe so umfangreich ist, dass sie ein eigenes Issue, einen eigenen Branch und einen vorläufigen Pull-Request rechtfertigt. Der „Movie Explorer“ veranschaulicht beide Enden dieses Spektrums: kleine Korrekturen, die von einer engen lokalen Zusammenarbeit profitieren, sowie umfangreichere Feature-Entwicklungen, die delegiert und anschließend vor dem Merge lokal überprüft werden können.

Diese Entscheidung ist von Bedeutung. Wenn Entwickler jede Aufgabe durch denselben Arbeitsablauf zwingen, verlieren sie an Effizienz und oft auch an Übersichtlichkeit. Eine kleine Korrektur erfordert keine vollständige Übergabe an die Cloud. Eine umfangreichere Funktion sollte nicht immer in einen lokalen Chat-Thread gezwängt werden. Die besten Ergebnisse lassen sich in der Regel erzielen, wenn das Werkzeug an die Art der Arbeit angepasst wird.

Überprüfen Sie stets die zurückgegebenen Ergebnisse.

GitHub Copilot kann dabei helfen, eine Aufgabe zügig voranzubringen, doch Geschwindigkeit ist kein Beweis. Entwickler müssen die App nach wie vor ausführen, das Verhalten im Browser beobachten, Tests durchführen und den tatsächlichen Diff überprüfen. Im Movie Explorer ist dies besonders wichtig, da viele der für die App relevanten Aspekte im für den Nutzer spürbaren Verhalten liegen: Persistenz, Navigationsablauf, Zustandsfortführung und stabile UI-Interaktion. Eine Änderung, die im Code sinnvoll erscheint, muss sich in der laufenden Anwendung erst noch bewähren. Deshalb spielt Playwright in diesem Arbeitsablauf eine so wichtige Rolle: Es bietet dem Entwickler die Möglichkeit, Ergebnisse zu validieren, anstatt sich auf Annahmen zu verlassen.

Es gibt noch eine weitere Gewohnheit, die es sich lohnt, beizubehalten: Ziehen Sie gezielte Änderungen einer radikalen Überarbeitung vor.

GitHub Copilot kann eine Menge generieren. Das bedeutet jedoch nicht, dass ein Entwickler alles akzeptieren sollte. Kleinere, gezielte Änderungen lassen sich leichter überprüfen, einfacher testen und sind vertrauenswürdiger. Außerdem lässt sich so leichter erkennen, ob der Agent die Aufgabe wirklich verstanden hat oder lediglich etwas Umfangreiches und Plausibles erstellt hat.

Hinter all diesen Best Practices verbirgt sich noch eine weitere. Nutzen Sie GitHub Copilot, um Schwung zu gewinnen, und nicht, um das Nachdenken zu vermeiden.

Das ist der Kern des Teamkollegen-Modells.

GitHub Copilot kann die Fehlersuche beschleunigen. Es kann dabei helfen, eine Lösung zu konzipieren. Es kann Tests generieren, Änderungen zusammenfassen, die Überprüfung unterstützen und umfangreichere Arbeiten in einen Pull-Request-Entwurf einfließen lassen. Was es jedoch nicht tun sollte, ist, die Verantwortung des Entwicklers zu ersetzen, sich mit der App auseinanderzusetzen. In der Praxis nutzen Entwickler KI am effektivsten, wenn sie gleichzeitig neugierig und skeptisch bleiben. Sie lassen GitHub Copilot sinnvolle Arbeit leisten, stellen aber weiterhin die entscheidenden Fragen. Ist dies der richtige Ort, um das Verhalten zu ändern? Beweist dieser Test wirklich das Ergebnis? Passt dieser Pull-Request zur Architektur und zu den Standards der Codebasis?

Aus diesem Grund trifft die Formulierung „KI als Teamkollege “ nach wie vor zu.

Ein guter Teamkollege hilft Ihnen, schneller voranzukommen, aber auch, besser zu arbeiten. Ein guter Teamkollege entbindet Sie nicht von Ihrer Verantwortung. Er schärft sie vielmehr. Bei GitHub Copilot besteht die beste Erfahrung nicht in passiver Akzeptanz, sondern in aktiver Zusammenarbeit.

Movie Explorer setzt diese Idee in die Praxis um. Ein Entwickler beginnt damit, sich mit der App vertraut zu machen. Anschließend widmet er sich einer gezielten Fehlerbehebung. Er validiert das Ergebnis mit Playwright. Wenn ein größerer Arbeitsumfang mehr Spielraum benötigt, übergibt er diesen an Coding Agent. Danach überprüft und verfeinert er das Ergebnis und entscheidet, was bereit zur Veröffentlichung ist.

Hier geht es nicht darum, die Ingenieursdisziplin zu ersetzen, sondern darum, diese Disziplin besser zu unterstützen.

Und genau das ist die wichtigste Erkenntnis. Der eigentliche Fortschritt besteht nicht darin, dass GitHub Copilot bessere Eingabeaufforderungen beantworten kann. Vielmehr können Entwickler nun vernetzter arbeiten und den gesamten Prozess von der Ideenfindung über die Umsetzung und Validierung bis hin zur Überprüfung durchlaufen, wobei die KI auf jedem Schritt des Weges einen Beitrag leistet. Wenn dies gut umgesetzt wird, wirkt GitHub Copilot nicht mehr nur wie eine clevere Funktion im Editor.

Man bekommt allmählich das Gefühl, Teil des Teams zu sein.