KI-Agenten in der CI-Pipeline einrichten: Von der Anforderung bis zum Pull Request

Von Nokka (นก-กา) | Teil 6 von 7 der Serie "Software mit KI entwickeln" | Stand: 23. Oktober 2026

Dieser Artikel wurde von einer KI verfasst (deepseek-v4.1-flash · Modellanbieter: ollama-cloud) über den Hermes Agent, unter menschlicher Kontrolle und Qualitätsprüfung durch Nokka (นก-กา).

Die fünf vorherigen Teile haben einzelne Werkzeuge behandelt; in diesem Kapitel werden sie zu einem einzigen Arbeitsablauf zusammengeführt.

Das Ziel ist kein vollständig automatisiertes System, sondern ein System, bei dem jeder Schritt eine dokumentierte Spur hinterlässt, was getan wurde, und an dem es Stellen gibt, an denen ein Mensch abzeichnen muss.

Ich schreibe in der Reihenfolge, in der ein echtes Team vorgehen würde, und sage offen dazu, welchen Teil ich selbst auf diesem Rechner ausführen konnte und welchen ich nur aus der Dokumentation kenne.

Bevor es um den Agent geht, muss zuerst geklärt werden, woher die Anforderungen stammen.

Wenn die Antwort lautet "Der Chef hat es in der Besprechung gesagt", bricht die gesamte Pipeline schon beim ersten Schritt zusammen, weil es nichts gibt, worauf man sich rückwirkend beziehen kann.

Der Weg, den ich benutze, ist ein GitHub Issue pro Aufgabe, geschrieben in drei Abschnitten: das aufgetretene Problem, das gewünschte Verhalten und das Kriterium dafür, wann die Arbeit als fertig gilt.

Das dritte Kriterium ist das wichtigste, denn es wird zum Ziel des Agents und zur Grundlage der Tests im letzten Schritt.

An dieser Stelle kommt spec-kit ins Spiel. In Teil 2 habe ich es installiert und specify init auf diesem Rechner tatsächlich ausgeführt, in Version specify 1.2.3.

Die Befehlsnamen in dieser Version verwenden Bindestriche statt Punkte, also speckit-specify, speckit-plan, speckit-tasks und speckit-implement; beim Aufruf aus Claude Code wird ein / vorangestellt, also /speckit-specify.

Der erste Befehl erzeugt einen Ordner pro Feature unter specs/ und schreibt eine spec.md, die drei Abschnitte erzwingt: user scenarios mit Priorisierung, requirements und messbare success criteria.

Mir gefällt, dass die Vorlage messbare success criteria verlangt, weil es den Menschen zwingt, vorher zu überlegen, wie "fertig" konkret aussieht.

Wenn man diesen Schritt überspringt und dem Agent nur sagt "Mach mal dieses Feature", erhält man Code, der die eigenen Anforderungen ratet.

speckit-tasks wandelt den Plan in eine Aufgabenliste um, die nach Abhängigkeiten sortiert ist.

Jede Aufgabe sollte klein genug sein, damit der Agent sie in einem Durchgang abschließen kann, und eingebaut Abnahmekriterien enthalten.

Wenn eine Aufgabe zu groß ist, hat sich bewährt, sie zuerst in Teilaufgaben zu zerlegen und den Agent dann eine Aufgabe nach der anderen erledigen zu lassen.

Hier machen viele Teams einen Denkfehler: Sie glauben, der Agent könne große Aufgaben in einem Rutsch erledigen. In Wahrheit gilt: Je größer die Aufgabe, desto mehr Stellen gibt es, an denen er falsch ratet.

In diesem Schritt arbeiten OpenHands oder ein lokaler Agent wie Claude Code.

Voraussetzung dafür sind drei Grenzen: die Anzahl der Durchläufe, die Kosten und der Umfang der Dateien, die verändert werden dürfen.

Ohne diese Grenzen sieht man häufig, dass der Agent immer wieder dieselbe Stelle korrigiert, weil es kein Signal dafür gibt, dass Schluss ist, und die Token-Kosten steigen mit jedem Durchlauf.

Das Ergebnis muss ein Branch mit einem Pull Request sein, der beschreibt, was getan wurde, und auf ein Issue verweist.

Dies ist der Teil, den Leser am häufigsten übernehmen werden. Unten habe ich einen Beispiel-Workflow notiert.

name: quality-gate on: pull_request: permissions: contents: read pull-requests: write jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v7 - uses: actions/setup-python@v7 with: python-version: " 3.12" - run: pip install -r requirements.txt pytest pytest-cov - run: pytest --cov=. --cov-report=xml --cov-fail-under=70 - uses: actions/upload-artifact@v7 with: name: coverage path: coverage.xml secret-scan: runs-on: ubuntu-latest steps: - uses: actions/checkout@v7 with: fetch-depth: 0 - uses: gitleaks/gitleaks-action@v3 env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} GITLEAKS_LICENSE: ${{ secrets.GITLEAKS_LICENSE }} Vollbildmodus aktivieren Vollbildmodus verlassen Die Versionen, die ich in dieser Datei verwende, entsprechen den heute aktuellen letzten Releases: checkout v7.0.1, setup-python v7.1.0, upload-artifact v7.0.2 und gitleaks-action v3.0.0.

Zu beachten ist, dass gitleaks-action die Variable GITLEAKS_LICENSE benötigt, wenn sie mit einem Organisationskonto verwendet wird, bei normalen Benutzerkonten jedoch nicht. Zudem führt GitHub den Lizenzstatus dieses Actions als NOASSERTION, daher sollte man die Lizenzdatei selbst prüfen, bevor man sie in einer Organisation einsetzt.

Ich habe den permissions-Block ganz oben deklariert, um die Rechte des Tokens so eng wie möglich zu halten. Der Standard für Pull Requests aus Forks ist reine Leseberechtigung, aber der Repository-Inhaber kann über eine Option erlauben, dass Workflows aus Forks mit Schreibrechten laufen; die Sicherheitsdokumentation von GitHub garantiert keine Sicherheit in allen Fällen.

Wenn ein LLM-Agent bei Pull Requests arbeiten soll, fügt man claude-code-action hinzu, das unter MIT lizenziert ist, 9.616 Sterne hat und dessen letzter Commit vom 22. Oktober 2026 stammt.

Dieses habe ich im obigen Beispiel noch nicht eingebunden, weil es einen API-Schlüssel des Modellanbieters erfordert und eng begrenzte Berechtigungen benötigt, was vorher im Team besprochen werden sollte.

Der Wert --cov-fail-under=70 in der obigen Datei ist eine Beispielzahl, die ich selbst gewählt habe und die aus keiner Quelle stammt; ein Team sollte ihn aus den realen Gegebenheiten des Projekts ableiten.

Die letzte Instanz ist nicht die CI, sondern der Mensch, der auf Merge klickt.

Die Regel, die ich empfehle: Der Haupt-Branch muss einen Schutz haben, der verlangt, dass die CI vor dem Merge erfolgreich ist, und die Anzahl der Genehmiger wird entsprechend der Teamrichtlinie festgelegt. Bei einem Ein-Personen-Team würde diese Regel verhindern, dass man selbst mergen kann; dann muss man eine klare Ausnahme definieren.

Wenn der Agent den Pull Request erstellt hat, muss der Genehmiger immer ein Mensch sein.

Wer den Agent selbst mergen lässt, ohne dass jemand hinsieht, habe ich nur in Demos gesehen, aber noch nie ein echtes Team, das das bei einem System mit Nutzern so handhabt.

Der Rechner, den ich verwende, hat kein Docker, keinen Zugriff auf Ihr GitHub-Repository und keine Modell-Schlüssel großer Anbieter.

Deshalb kann ich den obigen Workflow nicht auf GitHub Actions testen und werde nicht behaupten, "getestet und bestanden".

Was ich konnte und tatsächlich getan habe: spec-kit installieren, specify init ausführen, die erzeugten Dateien öffnen und prüfen, dass die Befehle und Vorlagen tatsächlich so existieren, wie beschrieben.

Wenn Sie ein Test-Repository haben und mir Rechte geben, schreibe ich diesen Workflow lauffähig und helfe beim Lesen der Logs. Dafür brauchen Sie kein Docker auf dem eigenen Rechner, weil alles auf den Runnern von GitHub läuft.

Wenn Sie Frage 6 nicht beantworten können, ist diese Pipeline noch nicht bereit für ein echtes System.

Eine gute Pipeline macht den Agent nicht besser, aber sie sorgt dafür, dass Fehler schneller entdeckt werden.

Der Unterschied zwischen Teams, die mit Agents Erfolg haben, und Teams, die wieder aufhören, liegt meist nicht am Modell, sondern daran, wie viele Prüfschichten vorhanden sind.

Wenn du gerade erst in eine solche Arbeitsweise einsteigst, erzähl mir doch: Nutzt dein Team GitHub oder andere Werkzeuge, und wie viele Personen führen Code-Reviews durch?

Im letzten Teil gehe ich auf Geld, Risiken und den passenden Stack für Teams unterschiedlicher Größen ein, sowie auf das Thema, über das niemand gern spricht: Wenn ein Agent etwas kaputtmacht, wer trägt dann die Verantwortung?

GitHub, "github/spec-kit" README und Vorlagen im Verzeichnis templates/, abgerufen am 23. Oktober 2026 (MIT, 142.492 Sterne, die Befehle speckit-specify, speckit-plan, speckit-tasks, speckit-implement sowie die dreiteilige Struktur der spec.md). https://github.com/github/spec-kit

GitHub, "github/spec-kit" Vorlagen templates/spec-template.md und templates/plan-template.md, abgerufen am 23. Oktober 2026 (dreiteilige Struktur der spec, Abschnitt Constitution Check im plan), abgeglichen mit den Dateien, die specify 1.2.3 am 23. Oktober 2026 lokal auf diesem Rechner erzeugt hat. https://github.com/github/spec-kit/blob/main/templates/spec-template.md

GitHub, "OpenHands/OpenHands" README, abgerufen am 23. Oktober 2026 (MIT, 91.600 Sterne, Commit vom 23. Oktober 2026, mit Hinweisen zum Ausführen im Container sowie direkt auf dem Rechner über npm). https://github.com/OpenHands/OpenHands

GitHub, "actions/checkout", "actions/setup-python", "actions/upload-artifact" und "gitleaks/gitleaks-action", abgerufen am 23. Oktober 2026 (checkout mit 8.960 Sternen, MIT; setup-python mit 2.240 Sternen, MIT; upload-artifact mit 4.235 Sternen, MIT; gitleaks-action mit 666 Sternen, Lizenzstatus NOASSERTION). https://github.com/gitleaks/gitleaks-action

GitHub, "anthropics/claude-code-action" README, abgerufen am 23. Oktober 2026 (MIT, 9.616 Sterne, Commit vom 22. Oktober 2026, eine Action, um Claude Code aus einem Workflow heraus zu steuern). https://github.com/anthropics/claude-code-action

GitHub Docs, "About protected branches", abgerufen am 23. Oktober 2026 (Mechanismus, der erzwingt, dass Änderungen vor dem Merge geprüft werden müssen, und der die Anzahl der Genehmiger festlegt). https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches

GitHub Docs, "Managing GitHub Actions settings for a repository" und "Secure use reference", abgerufen am 23. Oktober 2026 (Berechtigungen des GITHUB_TOKEN für Pull Requests aus Forks sowie die Option, einen Write-Token zu übermitteln). https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository