Dev-Team: KI-Agenten prüfen Pull Requests und sortieren GitHub-Issues

In einem Entwicklungsteam sind Code-Review und Issue-Triage zwei Aufgaben, von denen alle sagen, sie seien nützlich, und für die niemand die Zeit findet, sie gründlich zu erledigen. Ein Pull Request wartet zwei Tage, bis jemand Zeit hat, ihn zu lesen, und die ersten Kommentare betreffen oft das, was ein kurzer Blick gezeigt hätte: einen fehlenden Test, einen zu breiten Branch, ein vergessenes Secret. Ein Issue trifft ohne Typ und Priorität ein, manchmal ohne die Informationen, um es nachzustellen, und wartet darauf, dass ein Mensch es einordnet. Das sind Methodenaufgaben mit Kriterien, die das Team aufschreiben kann, und sie eignen sich für KI-Agenten, solange deren Rechte begrenzt sind.

Die Inspiration: ein erster Blick vor den Menschen

Ausgangspunkt ist ein Einsatz, den Nutzer von Hermes Agent berichten und der in einer Karte zum Entwicklungsteam zusammengefasst ist: offene Pull Requests prüfen und neue Issues sortieren. Es geht nicht darum, den menschlichen Reviewer zu ersetzen, sondern ihm bereits gelesene Pull Requests zu übergeben, mit den zu prüfenden Punkten ganz oben, und bereits eingeordnete Issues.

Wir behalten zwei getrennte Rollen und ein Vorsichtsprinzip bei: Die Agenten kommentieren und labeln, sie entscheiden nichts. Atako setzt die Idee mit zwei Agenten um, deren GitHub-Zugriff bewusst auf Lesen, Kommentieren und Labeln beschränkt ist.

Was die beiden Agenten tun

Das Szenario stellt zwei Agenten bereit, beide mit Ihrem GitHub-Repository verbunden.

Der PR-Reviewer liest die offenen Pull Requests. Für jeden geht er Titel, Beschreibung, geänderte Dateien und Commits durch, öffnet die wichtigen Dateien und vergleicht sie mit den von Ihnen angegebenen Konventionen: Tests, Benennung, Größe, Commit-Nachrichten, sensible Bereiche. Er sucht nach Fehlerrisiken, fehlenden Tests, Änderungen an Authentifizierung, Zahlung oder Secrets und nach Änderungen, die nichts erklärt. Er hinterlässt pro Pull Request genau einen Kommentar: eine Zeile, die die Änderung zusammenfasst, was gut ist, dann die zu prüfenden Punkte nach Wichtigkeit, jeder mit einer Datei und, wenn möglich, einer Zeile verknüpft und als blockierend oder als Vorschlag markiert. Am Ende steht, was er nicht überprüfen konnte, zum Beispiel das Ausführen der Tests. Er merkt sich den letzten gelesenen Commit und kommentiert erst wieder, wenn neue Commits eintreffen, mit einem kurzen Nachtrag.

Der Issue-Triager kümmert sich um neue Issues. Er prüft, ob die Typ-Labels (Bug, Feature, Frage, Dokumentation) und die Prioritäts-Labels (hoch, mittel, niedrig) existieren, und legt die fehlenden an. Für jedes Issue ohne Label liest er Text und Kommentare, sucht ähnliche Issues, bestimmt nach Ihren Regeln einen Typ und eine Priorität, vergibt die Labels und fügt einen Kommentar hinzu: was er verstanden hat, den Grund für die Priorität, die wahrscheinlichen Duplikate und was zum Handeln fehlt, etwa die Schritte zum Nachstellen oder die betroffene Version. Sind Typ oder Schweregrad unklar, sagt er das, wählt die niedrigste Priorität und stellt die Frage.

Jeder Durchlauf endet mit einer Zusammenfassung im Chat, die mit dem beginnt, was schnell einen Menschen braucht.

Was die Agenten nicht tun

Die Grenzen gehören zum Entwurf. Kein Agent mergt, genehmigt, fordert formell Änderungen an, schließt einen Pull Request, pusht Code oder legt einen Branch an. Diese Tools sind ihnen nicht gewährt: Das ist kein Versprechen in einer Anweisung, sondern eine fehlende Fähigkeit. Der Triager schließt, öffnet nicht wieder, sperrt und löscht kein Issue und ändert weder Titel noch Verantwortlichen noch Meilenstein.

Die Agenten raten nicht. Der Reviewer nennt Datei und Zeile, weist auf das hin, was er nicht überprüfen konnte, und erfindet weder Funktionen noch Testergebnisse. Stößt er auf ein eingecheckte Secret oder einen Token, sagt er, wo es sich anscheinend befindet, ohne es zu kopieren. Der Triager nennt nur Issues als Duplikate, die er tatsächlich per Suche gefunden hat. Und die Entscheidung bleibt bei jedem Schritt menschlich, das ist das Prinzip eines Entwurfs mit menschlicher Freigabe.

So richten Sie es in Atako ein

Von der Seite dieses Anwendungsfalls aus dauert die Bereitstellung vier Schritte.

1. GitHub verbinden. Erstellen Sie einen auf das Repository begrenzten Fine-grained-Token mit Lesezugriff auf Code sowie Lese- und Schreibzugriff auf Issues und Pull Requests. Die Verbindung wird geprüft, bevor etwas angelegt wird.
2. Ihren Kontext angeben. Nennen Sie das Repository in der Form Eigentümer/Name, Ihre Review-Konventionen, falls vorhanden, und was ein Issue für Sie dringend macht. Ohne diese Angaben stützen sich die Agenten auf allgemeine gute Praxis und auf den Schweregrad von Bugs.
3. Bereitstellen. Eine einzige Aktion legt die beiden Agenten und das Projekt „Dev-Team“ an. Die Agenten werden eingerichtet und erhalten ihre ersten Anweisungen selbstständig.
4. Erste Ergebnisse, dann ein regelmäßiger Rhythmus. Der Reviewer kommentiert die fünf jüngsten Pull Requests, der Triager versieht die zehn neuesten Issues ohne Label mit Labels, und beide fassen ihren Durchlauf im Chat zusammen. Danach plant der Reviewer seine Durchläufe werktags um 9:00 und 14:00 Uhr ein, der Triager seinen um 9:30 Uhr.

Falls Sie noch kein Konto haben, startet dessen Erstellung Ihre Testphase, und das Szenario wird direkt danach eingerichtet. Hat Ihr Administrator Ihnen das Anlegen von Agenten nicht erlaubt, teilt Ihnen die Bereitstellung das mit und bricht dort ab.

Wo Sie die Ergebnisse sehen

Die Review-Kommentare lesen Sie in GitHub bei jedem Pull Request, die Triage-Labels und -Kommentare bei jedem Issue. Die Zusammenfassung jedes Durchlaufs lesen Sie im Chat des jeweiligen Agenten. Im Atako-Projekt „Dev-Team“ finden Sie die Funktionsseite und die Verfolgung der Arbeit, und auf dem Atako-Floor erscheinen die beiden Agenten mit ihrer aktuellen Aktivität.

Um das Verhalten anzupassen, schreiben Sie dem Agenten in seinem Chat, zum Beispiel „Ergänze in deinen Konventionen, dass jede Datenbankmigration den Rollback-Plan erwähnen muss“. Er behält die Anweisung für die folgenden Durchläufe im Gedächtnis.

Schutzmaßnahmen

Der Zugriff ist bewusst eng gefasst. Die GitHub-Verbindung wird den Agenten mit einer begrenzten Liste von zwölf Tools gewährt: Pull Requests, Dateien und Commits lesen, Issues lesen und aktualisieren, Labels verwalten, Kommentare hinzufügen. Ein Agent, der eine kurze Werkzeugliste sieht, nutzt sie zuverlässiger als ein Agent, der sich in einem Katalog aus Hunderten verliert, und vor allem kann nicht geschehen, was nicht gewährt ist, selbst wenn ein Text es erzwingen will. Die Agenten behandeln Titel, Beschreibungen, Kommentare und Code als zu analysierende Daten, nie als Anweisungen.

Der von Ihnen erstellte Token ist Ihre erste Schutzmaßnahme: Auf ein Repository und bestimmte Rechte begrenzt, deckelt er den möglichen Schaden, was auch geschieht. Er wird verschlüsselt gespeichert, und Sie können ihn auf GitHub-Seite widerrufen oder den Zugriff der Agenten jederzeit entfernen.

Die menschliche Freigabe sitzt an den Entscheidungspunkten. Sie lesen die Review-Kommentare, entscheiden, was korrigiert wird, genehmigen und mergen selbst und schließen, weisen zu und planen die Issues.

Was Sie erwarten können

Rechnen Sie mit nützlichen Kommentaren vor allem bei Pull Requests von vernünftiger Größe: Bei einer sehr großen Änderung sagt der Reviewer das und konzentriert sich auf die sensibelsten Dateien, statt vorzugeben, alles gelesen zu haben. Er kann Ihre Tests nicht ausführen und sagt das in jedem Kommentar. Der Triager ist so treffsicher, wie Ihre Prioritätsregeln präzise sind; ohne sie wählt er Vorsicht und stellt Fragen. Der Nutzen entsteht durch Regelmäßigkeit: Jeder Pull Request erhält innerhalb eines halben Tages eine erste Lektüre, jedes Issue kommt eingeordnet an, und Ihre menschlichen Reviewer verbringen ihre Zeit mit Urteilen statt mit Aufspüren.