Ein Fehlerbericht liegt meist tagelang im Tracker, bevor irgendwer die Datei öffnet, in der er steckt. Die eigentliche Korrektur ist dann oft das kürzeste Kapitel der ganzen Geschichte. Was den Kalender auffrisst, ist alles drumherum: Branch anlegen, eine Commit-Nachricht schreiben, die erklärt, warum die Änderung überhaupt existiert, hochschieben, einen Pull Request öffnen, den Diff so beschreiben, dass die Gegenleserin nicht deine Absicht rekonstruieren muss, warten, dann die Kommentare abarbeiten und erneut hochschieben. Kein einzelner Schritt ist schwer. In Serie zerlegen sie einen Arbeitstag in Fetzen, die zu klein zum Denken sind.

Genau auf dieses zerfetzte Mittelstück zielt der Coding-Agent in GitHub Copilot. Die offizielle Beschreibung sollte man wörtlich nehmen, weil sie die Erwartung an die richtige Stelle setzt: Das ist nicht das Eingabefeld im Editor, das auf die nächste Frage wartet, sondern eine Rolle, die eine Aufgabe übernimmt und sie im Hintergrund selbst zu Ende bringt, während du dich um etwas anderes kümmerst.

Ein Issue abgeben, einen Pull Request zurückbekommen

Die Mechanik ist unspektakulär. Ein Issue Copilot zuweisen oder auf einer beliebigen Seite eine Aufgabe im Agent-Panel starten. Es beginnt mit Titel, Text und den bereits vorhandenen Kommentaren, erkundet das Repository in einer eigenen, temporären Umgebung, entwirft einen Plan, ändert den Code und öffnet einen Pull Request. Danach trägt es dich als Reviewenden ein und löst eine Benachrichtigung aus, damit die Übergabe dort landet, wo du sie tatsächlich siehst.

Diese Umgebung wird von der Continuous-Integration-Schicht betrieben. Tests und statische Prüfungen des Projekts laufen also, bevor du das Ergebnis überhaupt anschaust, und der Arbeitsbereich lässt sich vorab mit den Vorbereitungsschritten aufbauen, die im Repository ohnehin dokumentiert sind. Wenn ein Test nur mit laufender Datenbank und zwei Hintergrunddiensten grün wird, bleibt das kein Ratespiel.

Ein Detail stolpert viele, sobald sich die Anforderung verschiebt: Kommentare, die nach der Zuweisung am Issue ergänzt werden, nimmt der Agent nicht wahr. Nachträgliche Wünsche gehören in den Pull Request, den er geöffnet hat. Dort eine Notiz hinterlassen, und er startet eine frische Sitzung dafür; weil der Kontext früherer Sitzungen am selben Pull Request erhalten bleibt, sitzt der zweite Wunsch meist schneller und mit weniger Fehldeutungen als der erste. Derselbe Kanal funktioniert, wenn ein CI-Lauf scheitert: Fehler hinüberreichen, untersuchen lassen, Reparatur nachschieben.

Erst das eigene Werk lesen, dann alle anderen

Das Anstrengende beim Gegenlesen maschinell erzeugter Änderungen ist nicht, dass sie offensichtlich kaputt sind. Es ist, dass sie so aussehen, als würden sie laufen, während niemand im Team sie je so geschrieben hätte. Die offizielle Konstruktion beantwortet das, indem der Agent seinen eigenen Patch noch vor dem Öffnen des Pull Requests mit der Codereview-Fähigkeit durchgeht und anschließend auf das erhaltene Feedback nachbessert. Wenn du als Reviewender eingetragen wirst, hat bereits eine Runde stattgefunden.

Derselbe Ablauf startet Codescan, Secret-Scan und die Prüfung auf bekannte Schwachstellen in Abhängigkeiten. Eine Abhängigkeit mit offenem Problem oder eine Zeichenkette im Diff, die nach versehentlich committeten Zugangsdaten aussieht, wird markiert, bevor der Pull Request sichtbar wird, und nicht erst, wenn jemand darüber stolpert.

Die Gewohnheiten des Teams in eine Konfigurationsdatei schreiben

Ein kurzer Prompt lässt viel Platz für Entscheidungen aus dem Bauch, und Entscheidungen aus dem Bauch decken sich nicht immer mit der Art, wie das Team tatsächlich arbeitet. Dafür gibt es eigene Agenten. Eine Konfigurationsdatei im Repository legt fest, in welcher Reihenfolge eine Klasse von Aufgaben abgearbeitet wird. Ein Agent für Performance misst zum Beispiel zuerst, ändert dann den Code, misst erneut, um zu belegen, dass die Änderung etwas bewirkt hat, und öffnet erst danach den Pull Request. Dieselbe Konfiguration lässt sich organisationsweit teilen, sodass getrennte Teams einem Verfahren folgen statt mehreren privaten Varianten.

Auf dem Desktop liegen die Sitzungen nebeneinander

Sobald mehrere Aufgaben gleichzeitig laufen, wandert die Schwierigkeit dorthin, sie auseinanderzuhalten. Die Desktop-App startet Arbeit aus einem Issue, einem Pull Request, einem Satz oder einer früheren Sitzung und kann mehrere Agent-Sitzungen parallel laufen lassen. Jede bekommt einen eigenen Arbeitsbaum und Branch, damit Dateien, Gesprächsverlauf und Aufgabenstatus isoliert bleiben statt ineinanderzulaufen. Builds gibt es für Windows, macOS und Linux, Änderungen lassen sich im integrierten Terminal und im Browser prüfen, und die erzeugten Pull Requests laufen weiter durch die Regeln für Review, Checks und Merge, die im Team ohnehin gelten.

Coding-Agent übernimmt eine Aufgabe im Hintergrund und bringt sie über Branch, Commit und Pull Request hinweg zum Abschluss, ohne Schritt für Schritt geschoben zu werden.

Selbstprüfung vor der Übergabe verbessert erst per Codereview und lässt dann die Scans für Code, Secrets und Abhängigkeiten laufen.

Parallele Sitzungen geben jeder Desktop-Sitzung eigenen Arbeitsbaum und Branch, sodass sie nie gleichzeitig dieselben Dateien anfassen.

Was es kostet

Die Einzeltarife rechnen seit Juni 2026 nach Verbrauch ab, und die Reihe reicht von einer kostenlosen Stufe über Pro und Pro+ bis Max. Die kostenlose Stufe enthält ein begrenztes Kontingent für Vervollständigungen sowie begrenzte Nutzung von Chat und Agent, und sie bringt das Kommandozeilenwerkzeug und den Agent-Modus mit, sodass ein Testlauf erst einmal nichts kostet. In den bezahlten Stufen entspricht das Grundkontingent dem Abopreis, darüber liegt ein flexibles Kontingent, das sich mit den Kosten bewegt; Vervollständigungen und Vorschläge für die nächste Bearbeitung sind dort unbegrenzt und zehren nicht am Kontingent. Für die genauen Stufen und Zahlen ist die offizielle Preisseite die einzige belastbare Quelle.

Den Code zu schreiben ist die eine Hälfte. Die andere ist, die Änderung durch Review, Checks und Merge zu bringen, und diese Einrichtung übernimmt auch diese Hälfte, sodass Menschen nur dort auftauchen, wo wirklich geurteilt werden muss.