Autonome Coding-Agenten (vom Issue zum Pull Request)

Backlogs sind voll von kleinen, klar beschriebenen Tickets (Fehlerbehebungen, Aktualisierungen von Abhängigkeiten, Testlücken, kleine Funktionen), für die niemand Zeit hat. Coding-Agenten übernehmen ein solches Ticket, arbeiten asynchron in einer isolierten Cloud- oder Container-Sandbox, lesen das Repository, bearbeiten den Code, führen Build und Tests aus und öffnen einen Pull Request. Menschen prüfen und führen zusammen. Der Nutzen liegt im Durchsatz bei Routinearbeit, nicht im Ersatz von Ingenieuren.

Problem & Nutzen

• Heute: Entwickler wechseln für kleine Tickets den Kontext; Routineaufgaben und technische Schulden häufen sich an. IDE-Assistenten (CODE-001) helfen, solange eine Person tippt, brauchen aber weiterhin eine Person am Steuer.
• KI-Nutzen: Arbeit wird delegiert und läuft parallel und im Hintergrund (auch über Nacht); die Entwicklerin bzw. der Entwickler prüft einen fertigen PR, statt ihn zu schreiben. Am besten geeignet für Aufgaben mit klaren Abnahmekriterien und guten Tests.
• Belege: Anbieter dokumentieren den Ablauf (Issue zuweisen, Agent pusht in einen Entwurfs-PR, fordert Review an) [1][2]. Die SWE-bench-Familie misst, wie oft Agenten reale GitHub-Issues lösen; die Werte hängen stark von Harness und Modell ab, Verified gilt als zunehmend ausgereizt, und inzwischen werden schwierigere Varianten (z. B. SWE-bench Pro) genutzt [3]. Benchmark-Erfolg ist nicht gleich Praxis-ROI; messen Sie am eigenen Backlog.

Varianten

• Cloud-Agent in der Code-Plattform: Das Issue wird einem Agenten innerhalb von GitHub/GitLab zugewiesen und läuft in einer CI-ähnlichen Sandbox.
• Terminal-/CLI-Agent ohne Oberfläche (headless): wird aus CI, Cron oder Chat ausgelöst (z. B. nächtliche Routineaufgaben, Reparatur instabiler Tests).
• Wartungs-Bots: schmale Agenten für Upgrades von Abhängigkeiten, Behebung von Schwachstellen, Migrationen (CODE-021, CODE-014).
• Großunternehmen / regulierte Branchen: selbst betriebene Agentenplattform in der eigenen VPC mit Prüfpfad und Richtlinien-Schranken.
• Privat / Open Source: Maintainer nutzen Agenten, um kleine Issues zu sichten und zu beheben; Mitwirkende legen die KI-Nutzung offen.

So funktioniert es

1. ticket / issue (+ instruction files, MCP tools)
2. task planning (read code, search, locate relevant files)
3. sandbox (container/VM, restricted network, scoped token)
4. edit
5. build
6. run tests/linters
7. self-correct loop
8. commit to branch, open DRAFT pull request with summary
9. CI + automated review (CODE-003) + human review
10. reviewer comments
11. agent pushes follow-up commits
12. human merge

• Agentenschleife: Ein Reasoning-Codemodell ruft wiederholt Werkzeuge auf (Shell, Dateibearbeitung, Suche, Browser, MCP-Server), bis die Tests bestehen oder es aufgibt; Kontextverwaltung und Repository-Karten sind ebenso wichtig wie das Modell.
• Anweisungsdateien: AGENTS.md und ähnliche Dateien teilen dem Agenten Build-Befehle, Konventionen und Tabubereiche mit.
• Mensch-in-der-Schleife (Human-in-the-Loop): Auswahl der Tickets (was delegiert werden darf), PR-Review und Merge; Zugriff auf Geheimnisse und Produktivsysteme wird nie gewährt. Branch-Schutz stellt sicher, dass der Agent seinen eigenen PR nicht zusammenführen kann.

Datenaufbereitung

Agenten arbeiten mit dem Issue-Text, dem Repository, dem CI-Setup und der Testsuite. Diese liegen im Git-Hosting, im Ticketwerkzeug (Jira, GitLab, GitHub Issues) und im CI-System. Typische Lücken entscheiden mehr über den Erfolg als das Modell: vage oder unvollständige Tickets, keine oder instabile Tests, Builds, die nur auf einem Entwicklerrechner laufen, fehlende Einrichtungsdokumentation, undokumentierte Konventionen, Geheimnisse im Repository und zu weit gefasste Zugriffstoken.

Vorbereitungsschritte: (1) Abnahmekriterien mithilfe einer Vorlage in die Tickets schreiben (Ziel, betroffener Bereich, Definition of Done); (2) einen reproduzierbaren Build und eine schnelle Testsuite in der CI zum Laufen bringen, instabile Tests reparieren oder isolieren; (3) einen Devcontainer oder ein Setup-Skript bereitstellen, damit die Sandbox Abhängigkeiten installieren kann; (4) AGENTS.md oder CLAUDE.md mit Befehlen, Architektur und Tabubereichen schreiben; (5) auf Geheimnisse prüfen und dem Agenten ein Token mit minimalen Rechten ohne Zugriff auf Produktivsysteme geben. Eine Sammlung von 10 bis 20 früheren, gelösten Tickets als Evaluierungsaufgaben anlegen, siehe PREP-018; diese aus geschlossenen Issues und zusammengeführten PRs gewinnen (PREP-020). Rückmeldungen der Prüfenden zum Agenten aufbewahren, siehe PREP-021.

Aufwandsanteil: mittel, etwa 20 bis 30 Prozent, überwiegend Hygiene bei Tests und Build, die sich auch für menschliche Entwickler auszahlt.

Umsetzungswege

Welcher Weg für wen

• KMU: A - gehostete Agenten etablierter Anbieter (Copilot Coding Agent, Claude Code, Devin, Jules) laufen in verwalteten Sandboxes, sodass keine eigene Agenten-Infrastruktur nötig ist.
• Großunternehmen: B - ein eigener Agenten-Harness auf Cloud-APIs in EU-Regionen gibt Kontrolle über Sandbox, ausgehenden Netzwerkverkehr, Berechtigungen, Prüfpfad und Kosten und bindet interne Tracker und CI an.
• Entwickler: B - offene Agenten-Frameworks und BYOK-CLIs erlauben es, Modelle je Aufgabe zu wählen und die Token-Ausgaben direkt zu steuern.

Weg A — Kaufen (Standardsoftware) (für die meisten KMU empfohlen)

• In die Code-Plattform integriert: GitHub Copilot Cloud/Coding Agent [1][2], GitLab Duo Agent Platform, Atlassian Rovo Dev, Integrationen für Azure DevOps und Jira.
• Spezialisierte Agenten: Anthropic Claude Code (auch GitHub Actions / Web), OpenAI Codex (Cloud und CLI), Google Jules, Cursor Background Agents, Devin (Cognition), Factory, Amp (im Dezember 2025 aus Sourcegraph ausgegliedert), Augment.
• EU-Optionen: JetBrains Junie (JetBrains, Tschechien), Mistral Code / Devstral-basierte Werkzeuge (Frankreich), Tabnine (Optionen für Betrieb in der EU); prüfen Sie das regionale Hosting der Sandbox, nicht nur des Modells.
• A wählen, wenn: der Code bereits auf GitHub/GitLab liegt, Tests existieren und Sie Ergebnisse in Wochen wollen.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Modelle: führende Code-/Reasoning-Modelle über Anthropic, OpenAI, Google (EU-Regionen über AWS Bedrock Frankfurt, Azure EU, Vertex EU) oder Mistral (EU-Anbieter).
• Frameworks: Claude Agent SDK, OpenAI Agents SDK, LangGraph, OpenHands SDK [4]; MCP für den Werkzeugzugriff [5].
• Sandboxes: kurzlebige Container über GitHub-Actions-Runner, E2B, Daytona, Modal oder eigenes Kubernetes mit gVisor/Firecracker.
• B wählen, wenn: Sie eigene Auslöser (Ticket-Labels, ChatOps), eigene Richtlinien-Schranken oder andere Plattformen als GitHub benötigen.

Weg C — Selbst betreiben (Open Source)

• Agenten: OpenHands [4], SWE-agent / mini-SWE-agent [3], Aider, Cline/Roo Code, Goose, OpenCode.
• Modelle mit offenen Gewichten: Devstral (Mistral), Qwen3-Coder, GLM, Kimi K2, Coder-Modelle der DeepSeek-Klasse, bereitgestellt über vLLM oder SGLang.
• Hardware: kleine Modelle (~24–32B, Klasse Devstral Small) laufen auf HW2/HW3, sind aber bei langen Aufgaben schwächer; große offene Coder-Modelle benötigen HW4 (Multi-GPU-Knoten). Sandboxes brauchen CPU und RAM je paralleler Aufgabe.
• C wählen, wenn: der Quellcode die eigenen Räumlichkeiten nicht verlassen darf (Rüstungszulieferer, Banken) und ein Plattformteam existiert.

Weg D — Eigenes Training

Für KMU selten lohnend. Große Organisationen nehmen Feintuning oder RL-Training auf eigenen Repositories und CI-Spuren (Verläufe erfolgreicher PRs) vor, um Kosten zu senken oder interne Frameworks zu lernen. Erfordert Tausende verifizierter Aufgaben mit ausführbaren Tests.

Stand der Technik (2026)

• Agenten bearbeiten Fehlerbehebungen über mehrere Dateien und kleine Funktionen autonom; führende Modelle erreichen auf SWE-bench Verified sehr hohe Werte, daher verlagerte sich die Aufmerksamkeit auf SWE-bench Pro sowie Benchmarks für lange Aufgabenhorizonte und mehrere Sprachen [3]. Gehen Sie mit veröffentlichten Zahlen vorsichtig um: Harness, Scaffold und Kontamination verändern die Ergebnisse erheblich.
• Trends: parallele Hintergrund-Agenten, Agenten, die aus Chat/Issue-Trackern gesteuert werden, MCP als Standardschnittstelle für Werkzeuge, Anweisungsdateien für Agenten als De-facto-Standard, automatisiertes PR-Review der Agentenergebnisse.
• Grenzen und Fehlerbilder: vage Tickets führen zu plausiblen, aber falschen Änderungen; Agenten umgehen oder schwächen Tests; schwach bei großen Architekturänderungen, mehrdeutigen Anforderungen und instabilen Umgebungen; Ermüdung der Prüfenden bei großen PRs; halluzinierte oder schädliche Pakete (Slopsquatting); Prompt Injection über Issue-Text, Webseiten oder Werkzeugausgaben.

Gemeinsame Bausteine & Kombinationen

• Gleicher Technologie-Stack (llm-code + llm-reasoning + agent-framework): CODE-001 IDE-Assistenten, CODE-014 Fehlerbehebung, CODE-021 Upgrades/Refactoring, CODE-005 Migration von Altsystemen, CODE-004 Testerzeugung.
• Kombinieren mit: CODE-003 (KI-Review der Agenten-PRs), CODE-004 (Tests als Rückmeldesignal des Agenten), CODE-006 (Aktualisierung der Dokumentation im selben PR), AGENT-003 (Computer-Use zur Prüfung der Oberfläche).
• Eine gemeinsame Sandbox-/CI-Plattform und ein Modell-Gateway können alle diese Anwendungsfälle bedienen.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage bis Wochen; pro Arbeitsplatz oder nutzungsabhängig (Premium-Anfragen, Rechenminuten des Agenten).
• Weg B: 1–3 Monate für Auslöser, Sandbox, Umgang mit Geheimnissen und Audit-Protokollierung.
• Weg C: 3–6 Monate plus GPU und Plattformbetrieb.
• Kostentreiber: Tokens je Aufgabe (lange Agentenschleifen), Rechenleistung der Sandbox, Zeit der Prüfenden. Fehlgeschlagene Läufe kosten ebenfalls.
• Kennzahlen: Akzeptanz-/Merge-Rate der PRs, Anteil ohne größere Nacharbeit zusammengeführter PRs, Review-Dauer je Agenten-PR, CI-Erfolgsquote, durchgerutschte Fehler, Kosten je zusammengeführtem PR, Durchlaufzeit delegierter Tickets, Sicherheitsbefunde in Agenten-PRs.

Menschen & Veränderung

Beziehen Sie die Geschäftsführung (Budget, Risikobereitschaft, KI-Richtlinie, GUIDE-007), die Entwicklungsleitung als Prozessverantwortliche, IT und Informationssicherheit früh ein, weil Agenten Code ausführen und Repository-Token halten (GUIDE-013), außerdem die oder den Datenschutzbeauftragte(n) für den AVV und alle personenbezogenen Daten in Repositories oder Tickets sowie die Rechtsabteilung für Fragen zu Lizenzen und Haftung. Entwicklerinnen und Entwickler brauchen ein Mitspracherecht, welche Aufgabentypen delegiert werden.

Betriebsrat: abhängig vom Einzelfall. Agenten protokollieren, wer welche Aufgabe mit welchem Ergebnis zugewiesen hat, wodurch individuelles Verhalten oder individuelle Leistung sichtbar werden können; das Bundesarbeitsgericht hält die objektive Eignung für die Mitbestimmung nach § 87 Abs. 1 Nr. 6 BetrVG für ausreichend. § 90 Abs. 1 Nr. 3 verlangt eine rechtzeitige Unterrichtung, weil sich Arbeitsabläufe ändern, und nach § 80 Abs. 3 kann der Betriebsrat einen KI-Sachverständigen hinzuziehen. Vereinbaren Sie, dass Kennzahlen zu Agenten je Team erhoben und nie für individuelle Beurteilungen verwendet werden (GUIDE-004). Öffentlicher Dienst: Personalrat.

KI-Kompetenz: Fördern Sie die KI-Kompetenz der Beschäftigten nach Art. 4 KI-Verordnung (AI Act) mit praxisnahen Schulungen zum Schreiben guter Tickets, zur kritischen Prüfung von Agenten-Pull-Requests und zum Erkennen typischer Fehler (GUIDE-006). Beginnen Sie mit einem Pilot für risikoarme Aufgaben (Aktualisierung von Abhängigkeiten, kleine Fehler, Tests) in einem Team und entscheiden Sie anhand der Kennzahlen über Go/No-go (GUIDE-009). Gehen Sie ehrlich mit der Angst vor Ersatz um: Agenten übernehmen Routinetickets, Menschen entscheiden über Architektur, Review und Merge. Erlauben Sie niemals ein automatisches Zusammenführen in die Produktion ohne menschliche Freigabe.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): in der Regel minimales Risiko (ein Entwicklerwerkzeug, keine Verwendung nach Anhang III). Die Pflicht zur KI-Kompetenz nach Art. 4 gilt für die Beschäftigten. Schreibt der Agent Code für ein Hochrisiko-System (z. B. Medizin, Fahrzeuge), gelten die Konformitätspflichten und die Dokumentation des Systems selbst für das Endprodukt, nicht für das Werkzeug. Wenn Sie ein Agentenprodukt Dritten bereitstellen, prüfen Sie die Pflichten für GPAI/Art. 50. Eine nach Art. 5 verbotene Praxis ist nicht betroffen.
• DSGVO: Repositories, Tickets und Logs können personenbezogene Daten enthalten (Namen, Kundendaten in Testdaten); der Anbieter erhält sie als Auftragsverarbeiter, daher sind ein AVV, eine EU-Region und No-Training-Zusagen nötig; halten Sie Produktivdaten aus den Sandboxes heraus.
• Sicherheit: Agenten mit Shell- und Netzwerkzugriff sind eine Angriffsfläche: Token mit minimalen Rechten, Positivlisten für ausgehenden Netzwerkverkehr, keine Geheimnisse in der Sandbox, geschützte Branches, verpflichtende menschliche Freigabe von CI-Workflow-Läufen, Positivlisten für Abhängigkeiten und Issue-Texte nicht vertrauenswürdiger Autoren als nicht vertrauenswürdige Eingabe behandeln.
• Geistiges Eigentum und Lizenzen: mögliche Wiedergabe lizenzierten Codes; nutzen Sie Lizenzprüfung (SCA) und dokumentieren Sie die KI-Urheberschaft. Auch die Pflichten des CRA (Cyber Resilience Act) zur sicheren Entwicklung bei Produkten mit digitalen Elementen bleiben beim Hersteller.
• Gegenmaßnahmen: nur Entwurfs-PRs, Review durch CODEOWNERS, Audit-Log der Prompts/Commits, SAST und Tests als Schranken, Positivliste für Aufgaben.

Erste Schritte

1. Ein Repository mit guten Tests und CI auswählen; eine AGENTS.md mit Build-/Testbefehlen und Konventionen schreiben.
2. 20 kleine, klar beschriebene Tickets (Routineaufgaben, kleine Fehler) als Pilotmenge auswählen.
3. Einen Agenten nach Weg A mit minimalen Zugriffsrechten, geschützten Branches und ohne Produktiv-Geheimnisse aktivieren.
4. Jeden PR prüfen, als stamme er von einem Nachwuchsentwickler; Merge-Rate, Nacharbeit und Kosten erfassen.
5. Auf weitere Ticket-Typen erst erweitern, wenn Merge-Rate und Fehlerdaten es rechtfertigen; KI-Review ergänzen (CODE-003).

Quellen

1. GitHub Docs — Asking GitHub Copilot to create a pull request — https://docs.github.com/copilot/how-tos/use-copilot-agents/coding-agent/assign-copilot-to-an-issue
2. GitHub Docs — Using Copilot cloud agent on GitHub — https://docs.github.com/en/copilot/how-tos/use-copilot-agents/cloud-agent/use-cloud-agent-on-github
3. SWE-bench project and leaderboards — https://www.swebench.com/
4. OpenHands (open-source coding agent platform) — https://github.com/All-Hands-AI/OpenHands
5. Model Context Protocol specification — https://modelcontextprotocol.io/
6. Claude Code documentation — https://docs.claude.com/en/docs/claude-code/overview
7. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
8. Regulation (EU) 2024/2847 (Cyber Resilience Act) — https://eur-lex.europa.eu/eli/reg/2024/2847/oj