GitHub und AI-Agenten
In GitHub steht alles, was getan wurde — und nichts davon ist für die Person geschrieben, die nach dem Termin fragt. Der Agent liest das Repository und übersetzt es in Sätze, die Sie einem Kunden oder der Geschäftsführung sagen können: was fertig ist, was hängt und wonach man Sie zuerst fragen wird.
Was ein Agent in GitHub tut
- Stellt zusammen, was diese Woche wirklich fertig geworden ist: gemergte Pull Requests, geschlossene Issues, gesetzte Release-Tags.
- Zeigt die Pull Requests, die länger ohne Review liegen als die Frist, die Sie gesetzt haben.
- Hält die Verbindung zwischen der Frage des Kunden und dem Issue dahinter: wo es steht und was zuletzt passiert ist.
- Schreibt einen Entwurf der Release Notes aus den echten Commits und Tags — getrennt nach dem, was Nutzer merken, und dem, was nur das Team merkt.
- Bringt Ihnen die Issues, die Leute von außerhalb des Teams eröffnen, statt sie ungelesen liegen zu lassen.
Abläufe, die von selbst starten
Ein Playbook ist kein Knopf, sondern ein Ablauf mit einer Bedingung, die ihn startet. In GitHub kommt diese Bedingung meist aus dem Repository selbst: ein Pull Request ohne Review, ein gesetztes Release-Tag, ein Issue von jemandem außerhalb des Teams.
Ein Pull Request bleibt ohne Review liegen
Ein Pull Request ist länger offen als die Frist, die Sie gesetzt haben, und hat immer noch kein Review
- Echtes Warten von Entwürfen und von Fällen ohne benannten Reviewer trennen
- In einem Absatz ohne Code beschreiben, was sich ändert und wen es betrifft
- Den benannten Reviewer dort erinnern, wo er seine Nachrichten wirklich liest
- Ihnen den vorlegen, der die Auslieferung am längsten aufhält
Ein Release, in Worten erzählt
Im Repository wird ein Release-Tag gesetzt
- Die Commits und geschlossenen Issues zwischen dem letzten Tag und diesem sammeln
- Trennen, was Kunden merken, und was nur das Team merkt
- Ihnen den Entwurf der Release Notes vorlegen — Formulierung und Zusagen bleiben bei Ihnen
- Die Punkte markieren, für die es die Antwort eines Entwicklers braucht und keine Vermutung
Es kommt etwas von außen
Ein Issue wird von jemandem eröffnet, der nicht zu Ihrem Team gehört
- Prüfen, ob es etwas doppelt, das bereits offen ist
- Eine kurze Karte zusammenstellen: wer schreibt, was er will, was das betrifft
- Es Ihnen vorlegen — er benennt keinen Zuständigen und sagt keinen Termin zu
Wo der Agent aufhört
- Er schreibt, prüft und merged keinen Code: das ist die Entscheidung der Entwicklung und deren Verantwortung.
- Er berichtet, was das Repository zeigt, und liest aus der Zahl der Commits weder Qualität noch Einsatz ab.
- Zugänge, Secrets und Branch Protection rührt er nicht an — davon wird nichts im Gespräch eingerichtet.
- Wann etwas fertig ist, sagen die Leute, die es bauen, und nicht ein Agent, der es aus dem Commit-Verlauf hochrechnet.
FAQ
Muss ich Code lesen können, um dem zu folgen?
Nein. Der Agent beschreibt Änderungen über ihr Ergebnis: was jetzt funktioniert, was behoben wurde, wen es betrifft. Der Link auf den ursprünglichen Pull Request oder das Issue steht daneben — für den Fall, dass Sie ihn einem Entwickler vorlegen wollen.
Ändert der Agent etwas im Repository?
Standardmäßig liest er nur. Wenn Sie es erlauben, schreibt er einen Kommentar oder setzt ein Label — nie Code, Branches oder Historie. Review und Merge bleiben beim Team.
Wird daraus nicht eine Überwachung der Entwickler?
Auswertungen nach dem Muster „wer hat wie viel committet“ bauen wir bewusst nicht: die Zahl sagt nichts über die Arbeit, und jedes Team lernt binnen eines Monats, sie zu füttern. Der Agent zeigt den Stand der Arbeit, keine Rangliste von Personen.
Was braucht es, um ein privates Repository anzubinden?
Den Lesezugriff vergibt die Eigentümerin des Repositorys oder ein Administrator der Organisation — deren Entscheidung, nicht unsere. Danach läuft die Einrichtung im Gespräch: Sie nennen die Repositorys und die Fristen, ab denen etwas als liegengeblieben gilt.
Wo das vorkommt
Durchgänge, in denen es dazugehört zu sehen, was die Entwicklung gerade tut.