In der modernen Softwareentwicklung bindet die Behebung von Routinefehlern und kleineren Wartungsaufgaben erhebliche Kapazitäten erfahrener Ingenieure. Null-Pointer-Prüfungen, Anpassungen an veraltete Bibliotheken, Regex-Korrekturen und das Nachreichen fehlender Unit-Tests bleiben häufig wochenlang im Backlog liegen, weil Senior-Entwickler mit geschäftskritischen Produktfeatures ausgelastet sind.
Sweep wurde konzipiert, um genau diese Lücke als autonomer KI-Entwickler (AI Junior Developer) zu schließen. Als GitHub App in ein Repository integriert, überwacht Sweep eingehende Issues, analysiert den Codebestand mithilfe von Vektor-Embeddings und AST-Parsing (Abstract Syntax Tree), erstellt Anpassungen über mehrere Dateien hinweg und öffnet strukturierte Pull Requests (PRs). Darüber hinaus schließt Sweep den Regelkreis, indem es Testfehler in GitHub Actions auswertet, um sich selbst zu korrigieren, und direkt auf Inline-Code-Reviews von menschlichen Entwicklern reagiert.
Dieser Leitfaden erläutert praxisnah, wie Entwicklungsteams Sweep einrichten, die Konfigurationsdatei sweep.yaml für Produktionsumgebungen anpassen, präzise Issue-Prompts formulieren und essenzielle Sicherheitsrichtlinien etablieren.
1. Der Workflow: Vom GitHub Issue zum Pull Request
Vor der Konfiguration muss das Team den Lebenszyklus eines von Sweep bearbeiteten Tickets verstehen:
- Auslösendes Ereignis: Ein Entwickler erstellt ein GitHub Issue mit dem Präfix
Sweep:(z. B.Sweep: Fix KeyError when user metadata payload is missing), weist dem Issue das Labelsweepzu oder erwähnt@sweepaiin einem Kommentar. - Kontextsuche im Repository: Die Webhook-Funktion von Sweep (
on_ticket) wird aufgerufen. Sie nutzt semantische Vektorsuche und AST-Chunking, um betroffene Dateien, Klassen, Funktionen und vorhandene Tests zu identifizieren. - Erstellung des Ausführungsplans: Sweep hinterlässt einen interaktiven Kommentar im Issue, der die beabsichtigte Vorgehensweise und die Liste der zu modifizierenden Dateien darlegt.
- Codegenerierung und Branching: Auf einem isolierten Branch (z. B.
sweep/fix-...) nimmt Sweep die Änderungen gemäß den Vorgaben des Projekts vor und pusht die Commits. - Erstellung des Pull Requests: Sweep öffnet einen regulären PR mit Verknüpfung zum gelösten Ticket (
Fixes #<id>), einer Zusammenfassung der Änderungen und einer Checkliste. - Kontinuierlicher Feedback-Loop:
- CI-Selbstkorrektur: Bei aktivierter GitHub Actions-Integration (
gha_enabled: true) liest Sweep bei fehlschlagenden Tests die Fehlermeldungen aus und pusht selbstständig Reparatur-Commits. - Menschliches Code-Review: Hinterlässt ein Entwickler Inline-Kommentare im Diff des PRs, analysiert Sweep das Feedback und aktualisiert den Code umgehend.
- CI-Selbstkorrektur: Bei aktivierter GitHub Actions-Integration (
2. Installation und Berechtigungen in GitHub
Um Sweep für ein Repository oder eine Organisation freizugeben:
- GitHub App installieren: Rufen Sie die Installationsseite der Sweep GitHub App auf und wählen Sie die gewünschten Repositories aus.
- Erforderliche Berechtigungen gewähren:
- Repository Contents (Lesen und Schreiben): Erforderlich zum Auslesen des Quellcodes und zum Erstellen von Branches und Commits.
- Issues (Lesen und Schreiben): Erforderlich zum Lesen von Fehlerbeschreibungen, Verwalten von Labels und Verfassen von Statuskommentaren.
- Pull Requests (Lesen und Schreiben): Erforderlich zum Eröffnen von PRs, Analysieren von Diffs und Verarbeiten von Review-Kommentaren.
- Actions / Checks (Lesen): Erforderlich zum Abrufen von CI-Protokollen bei fehlgeschlagenen Testläufen.
- Draft-Status einrichten: In der Einführungsphase empfiehlt es sich, PRs zunächst als Entwurf (
draft: true) erstellen zu lassen, um unnötige Benachrichtigungen in Team-Kanälen zu vermeiden, bis der Lösungsansatz geprüft wurde.
3. Repository-Regeln mit sweep.yaml steuern
Das Verhalten von Sweep wird maßgeblich über die Konfigurationsdatei sweep.yaml (oder .sweep/config.yaml) im Stammverzeichnis des Repositories bestimmt. Eine fundierte Konfiguration verhindert Halluzinationen bei Importen, erzwingt Teamstandards und schützt sensible Bereiche.
Vorlage für eine produktive sweep.yaml
# sweep.yaml - Konfiguration für die automatisierte Issue-Bearbeitung
# Ziel-Branch, von dem Sweep abzweigt und gegen den PRs geöffnet werden
branch: 'main'
# PRs als Entwurf öffnen (für neue Teams empfohlen)
draft: false
# Aktiviert das Auslesen von GitHub Actions-Fehlern zur automatischen Nachbesserung
gha_enabled: true
# Projektüberblick zur optimalen Orientierung der KI-Modelle
description: >
Backend-REST-API, entwickelt mit Python 3.10 und FastAPI.
Die Datenbankinteraktion basiert auf SQLAlchemy 2.0 und PostgreSQL.
Geschäftslogik liegt in services/, Modelle in models/ und Endpunkte in api/v1/.
Alle Modulimporte müssen absolut sein (z. B. `from services.auth import verify_token`).
# Verzeichnisse und Dateien, die Sweep NIEMALS lesen oder verändern darf
blocked_dirs:
- "deploy/"
- "terraform/"
- ".github/workflows/"
- "migrations/"
- "*.env*"
- "security/"
# Sandbox-Befehle, die vor der PR-Erstellung in einem isolierten Container laufen
sandbox:
install:
- "poetry install --no-root"
check:
- "poetry run ruff check {file_path}"
- "poetry run pytest tests/unit"
# Verbindliche Coding-Standards, die in den Agenten-Prompt injiziert werden
rules:
- "Jeder Bugfix muss entsprechende pytest-Unit-Tests in tests/ ergänzen oder aktualisieren."
- "Wildcard-Importe (`from module import *`) sind strikt untersagt."
- "Für Validierungen von API-Requests und -Responses sind Pydantic v2-Schemas zu verwenden."
- "Verwende loguru für Logging; in Exception-Blöcken muss logger.exception() für Tracebacks genutzt werden."
- "Ohne ausdrückliche Anweisung dürfen weder Datenbankschemata geändert noch alembic-Migrationen erstellt werden."
- "Alle neuen oder modifizierten Funktionssignaturen müssen vollständige Typ-Annotationen enthalten."
Die wichtigsten Direktiven im Detail
branch: Bestimmt den Basis-Branch für Entwicklungen. Falls Ihr Team mitdevelopoder Release-Branches arbeitet, tragen Sie diesen hier ein.blocked_dirs: Essenzielle Sicherheitsbarriere. Pfade, die diesen Mustern entsprechen, werden vor jeglichen Änderungen geschützt. Pflicht für CI/CD-Konfigurationen, Secrets, Infrastrukturcode und Datenbankmigrationen.gha_enabled: Wenn auftruegesetzt, reagiert Sweep auf Webhook-Ereignisse fehlschlagender GitHub Actions, liest die Fehlerursache aus und committed Korrekturen.rules: Vorgaben in natürlicher Sprache. Der Agent übernimmt diese Regeln in seinen Kontext, was Stilbrüche und unpassende Bibliotheksverwendungen verhindert.sandbox: Definiert Installations- (install) und Prüfbefehle (check), damit nur fehlerfreier und getesteter Code in den Pull Request einfließt.
4. Präzise Issue-Beschreibungen für fehlerfreie PRs verfassen
Die Qualität des von Sweep gelieferten Codes hängt direkt von der Vollständigkeit und Klarheit des GitHub Issues ab. Während Kollegen Rückfragen im Chat stellen können, stützt sich der KI-Agent ausschließlich auf den Text und den Codebestand.
Aufbau eines vorbildlichen Bug-Reports
Titel: Sweep: Fix 400 Bad Request on empty user metadata payload in /api/v1/profile
### Fehlerbeschreibung
Bei der Aktualisierung eines Benutzerprofils über `PUT /api/v1/profile` löst die Übergabe eines leeren Dictionarys `{}` in `metadata` einen ValidationError aus, anstatt die Standardwerte zu übernehmen.
### Schritte zur Reproduktion
1. Sende einen PUT-Request an `/api/v1/profile` mit dem Body `{"metadata": {}}`.
2. Die API antwortet mit HTTP 400 und der Meldung `Value error, metadata must contain required fields`.
### Erwartetes Verhalten
Ein leeres `metadata`-Objekt muss akzeptiert, mit den Default-Werten (`{"theme": "light", "notifications": true}`) initialisiert und gespeichert werden.
### Relevante Dateien und Funktionen
- `api/v1/profile.py`: Handler-Funktion `update_profile`.
- `schemas/profile.py`: Pydantic-Modell `UserProfileUpdate`.
- `services/profile_service.py`: Hilfsfunktion `save_profile_metadata`.
### Akzeptanzkriterien
- Validierung in `schemas/profile.py` so anpassen, dass leere Dictionaries mit Standardwerten durchlaufen.
- Einen Unit-Test in `tests/unit/test_profile_api.py` hinzufügen, der diesen Fall abdeckt.
- Sicherstellen, dass alle bestehenden Tests in `tests/unit/` erfolgreich durchlaufen.
Titelpräfixe zur Steuerung der Ausführung
Der Parser von Sweep (strip_sweep) unterstützt spezifische Präfixe zur Feinsteuerung:
Sweep: <Titel>: Standardmäßige automatische Bearbeitung.Sweep(sandbox): <Titel>: Erzwingt vor der PR-Erstellung eine vollständige Sandbox-Prüfung.Sweep(fast): <Titel>: Nutzt schnellere Inferenz für unkomplizierte Korrekturen.Sweep(slow): <Titel>: Räumt dem Agenten mehr Iterationsschritte bei komplexen Abhängigkeiten ein.Sweep(lint): <Titel>: Führt eine strikte Formatierungs- und Linting-Prüfung durch.Sweep(subissues): <Titel>: Teilt umfangreiche Tickets automatisch in Unteraufgaben auf.
5. Review-Schleife und interaktive Optimierung
Nachdem Sweep den Pull Request eröffnet hat, erfolgt die weitere Interaktion nahtlos in GitHub:
[GitHub Issue] ──> Sweep startet ──> PR erstellt ──> CI (GitHub Actions)
│
┌──────────────────────────────────┴─────┐
▼ ▼
CI schlägt fehl (gha_enabled) CI erfolgreich
│ │
▼ ▼
Sweep committet Korrektur Code-Review durch Entwickler
│ │
└─────────► PR aktualisiert ◄────────────┘
│
(Review-Kommentar:
"@sweepai nutze bitte die
existierende Helper-Funktion")
Inline-Kommentare im Diff
Entwickler müssen den Branch nicht lokal auschecken, um Anpassungen vorzunehmen. Ein einfacher Zeilenkommentar im GitHub PR genügt:
@sweepai Verwende hier bitte unsere Hilfsfunktion DateUtils.formatIso(), anstatt einen neuen Datumsformatierer zu schreiben.
Sweep fängt den Kommentar über Webhooks ab, analysiert den Kontext und pusht einen neuen Commit auf den bestehenden Branch.
Issue neu generieren
Sollte der ursprüngliche Lösungsansatz verworfen werden müssen, reicht es aus, den Titel oder die Beschreibung des ursprünglichen GitHub Issues zu aktualisieren. Sweep erkennt die Änderung, bereinigt den bisherigen Branch und generiert einen neuen PR.
6. Sicherheitsrichtlinien und Grenzen in der Praxis
Für den zuverlässigen Einsatz von autonomen Coding-Agenten im Teamalltag gelten folgende Grundsätze:
- Kein Auto-Merge: Aktivieren Sie niemals die automatische Verschmelzung für von Sweep erstellte PRs. Erzwingen Sie über Branch-Schutzregeln mindestens ein manuelles Review durch einen Senior-Entwickler und bestandene CI-Pipelines.
- Klare Abgrenzung kritischer Pfade: Schließen Sie über
blocked_dirsInfrastrukturdateien (terraform/,k8s/), CI-Workflows (.github/), Datenbankmigrationen und Konfigurationsdateien mit Umgebungsvariablen konsequent aus. - Fokus auf umrissene Aufgaben: Sweep erzielt die besten Ergebnisse bei klar abgegrenzten Bugfixes, Testnachweisen und isolierten Refactorings. Unspezifische Feature-Entwicklungen ohne klare Spezifikation sollten vermieden werden.
- Solide Testabdeckung: Die Selbstheilungsfunktion von Sweep steht und fällt mit der Qualität der Testmeldungen. Eine lückenlose Testsuite ist die beste Absicherung gegen unbeabsichtigte Regressionen.
Referenzen
- GitHub - sweepai/sweep: Sweep: AI coding assistant for JetBrains
- GitHub - sweepai/sweep: sweep.yaml configuration file
- GitHub - sweepai/sweep: sweepai/config/client.py
- GitHub - sweepai/sweep: sweepai/handlers/on_ticket.py
- GitHub - sweepai/sweep: sweepai/utils/str_utils.py
- sweepai · PyPI
- Launch YC: Sweep: JetBrains AI Coding Assistant | Y Combinator