Wenn du heute mit KI-Coding-Agenten arbeitest, kennst du den Ablauf: eine Sitzung starten, prüfen, die nächste starten und den Überblick selbst im Kopf behalten. Am 28. Oktober 2026 hat GitHub für die GitHub Copilot App eine Funktion angekündigt, die dir diese Koordinationsarbeit abnehmen soll. Sie heißt Projects und ist jetzt als Public Preview verfügbar.
Was Copilot Projects eigentlich sind
Ein Projekt gibt Copilot ein fortlaufendes Ziel statt einer einzelnen Aufgabe. Laut GitHubs Changelog bündelt ein Projekt Kontext, Agenten und Ergebnisse einer Arbeit an einem Ort. Du beschreibst das Ziel und fügst Kontext hinzu, etwa Repositories, Design-Entwürfe oder Slack-Threads. Copilot startet dann so viele Agenten, wie die Arbeit braucht, und liefert Ergebnisse zurück, zum Beispiel Pull Requests, die du prüfst. Ein Pull Request ist ein Paket vorgeschlagener Codeänderungen, das du vor dem Zusammenführen kontrollieren kannst.
Der Unterschied zur normalen Sitzung ist der Umfang. Eine Sitzung erledigt eine Aufgabe, meist in einem Repository, also dem Ort, an dem der Code eines Projekts liegt. Ein Projekt kann ein Repository umfassen, mehrere oder gar keins. GitHubs Dokumentation nennt Beispiele wie das Gruppieren von Kundenfeedback nach Themen, ganz ohne Codeänderungen. Für eine fokussierte Aufgabe in einem einzigen Repository empfiehlt GitHub weiterhin, die Sitzung direkt aus diesem Repository zu starten.
So richtest du ein Projekt ein
Die Einrichtung besteht laut Dokumentation aus fünf Schritten. Klicke in der Seitenleiste auf das Plus-Symbol neben Projects, um die Seite New project zu öffnen. Wähle optional die Repositories, die das Projekt nutzen soll, oder überspringe diesen Schritt. Beschreibe im Eingabefeld vier Dinge: den Zweck, die ersten Aufgaben, die erwarteten Ergebnisse und mögliche Einschränkungen, also die Regeln, an die sich Copilot halten muss. Füge optional Dateien oder Ordner im Tab Library hinzu. Dann sendest du den Prompt, und Copilot legt los.
GitHub rät außerdem, jedem Projekt ein einziges, klares Ziel zu geben, damit zusammengehörige Aufgaben und Ergebnisse beieinanderbleiben. Das klingt nach Ordnungsliebe, ist aber wichtig: Ein vages Ziel gibt den Agenten ein vages Ziel, und die Korrekturen zahlst du später.
Wie du viele Agenten im Blick behältst
Ein Projekt besteht aus vier Teilen: Sitzungen, also den Arbeitseinheiten, die Copilot startet; optionalen Repositories; Automationen; und einer Library. Die Library ist geteilt in Agent für Material, das Copilot erzeugt, und User für Material, das du hinzufügst. So erkennst du immer, was von wem stammt.
Der Tab Overview sortiert die gesamte Arbeit nach Status in vier Gruppen. Needs input sammelt Entscheidungen, Reviews und Berechtigungsanfragen, die auf dich warten. Open zeigt Arbeit mit offenem Pull Request, inklusive Sitzungsstatus und hinzugefügter und gelöschter Zeilen. Working listet laufende Sitzungen, Done die abgeschlossene Arbeit. Läuft eine Sitzung in die falsche Richtung, öffnest du sie aus Overview, prüfst Unterhaltung, Änderungen, Pull Request und Plan und gibst mit Steer this session neue Anweisungen. Du kannst auch eine Folgeaufgabe im Projekt senden oder später neues Material hinzufügen und Copilot bitten, es mit früheren Ergebnissen zu vergleichen.
Was Projekt-Automationen leisten
Automationen sind wiederkehrende Aufgaben innerhalb eines Projekts. Du beschreibst im Eingabefeld des Projekts die Aufgabe und wann sie laufen soll, und beantwortest Rückfragen von Copilot. Der Tab Automations zeigt danach den Zeitplan und den nächsten Lauf. Über das Optionsmenü kannst du eine Aufgabe pausieren, bis du sie fortsetzt, den Zeitplan bearbeiten oder sie löschen. Willst du ändern, was die Aufgabe tut, fragst du einfach Copilot in der Projektunterhaltung. GitHubs eigenes Beispiel: ein Promo-Video erstellen, sobald ein Feature fertig ist.
Unsere Einschätzung: Wer prüft eigentlich?
Die Fakten sind klar: GitHub entwickelt Copilot vom Ausführen einzelner Aufgaben hin zum Koordinieren eines Ziels. Spannend ist aus unserer Sicht nicht die Zahl der Agenten, sondern die Gruppe Needs input und die Trennung von Agent und User in der Library. Sie machen die menschlichen Kontrollpunkte sichtbar. Dort bleibt die eigentliche Arbeit bei dir, denn ein Pull Request von einem Agenten ist ein Vorschlag, kein Beweis, dass der Code tut, was du wolltest.
Grenzen wir zuerst die Änderung ein. Bevor du ein Ziel an mehrere Agenten gibst, schreib auf, was das fertige Ergebnis leisten muss und wie du es prüfst. Unsere Schlussfolgerung: Je mehr Agenten parallel laufen, desto eher wird dein Review zum Engpass. Ein präziser erster Prompt und die Gewohnheit, zuerst Needs input anzusehen, bringen mehr als jeder zusätzliche Agent.
Was noch offen ist
Projects ist eine Public Preview, und laut GitHubs Dokumentation kann sich die Funktion noch ändern. Changelog und Dokumentation nennen nicht, welche Tarife Projects enthalten, wie viele Repositories, Sitzungen oder Automationen ein Projekt haben darf und wie Projektarbeit auf Nutzung oder Abrechnung angerechnet wird. Wenn du es ausprobierst, starte mit einem kleinen Projekt mit einem einzigen Ziel und beobachte das Verhalten, bevor du skalierst.
