Nunebot: KI-Agent öffnet 269 Pull Requests in zwölf Tagen

Auf 20 Repositories hat der Entwickler John Nunemaker zwischen dem 18. und 29. Oktober 269 Pull Requests von einem KI-Agenten anlegen lassen, 250 davon sind bereits übernommen. Die mittlere Änderung umfasst 43 Zeilen, freigegeben hat jede Nunemaker selbst. Wie der Agent klein bleibt, regelt ein Prompt von 229 Zeilen.

Nunemaker hat am 29. Oktober beschrieben, wie sein KI-Agent Nunebot seine Anwendungen wartet.^[1] Pro Repository liefert der Agent genau eine kleine, belegte Verbesserung, die Nunemaker prüft und übernimmt.

Wie bleiben die Änderungen des Agenten klein?

Der Agent wählt pro Repository eine eindeutige Verbesserung, baut sie in einem eigenen Git-Worktree, prüft sie mehrfach und öffnet einen Pull Request mit Beleg. Findet er nichts Lohnendes, überspringt er das Repository.

Nunebot sammelt Kontext aus Fehlerberichten, Performance-Daten, Support-Gesprächen und Backlog und wählt dann eine Änderung, bei der Nunemaker nach eigener Aussage ohne Zögern zustimmen würde.^[1] Opus 5.5 schreibt dazu einen Test, der auf dem Hauptzweig fehlschlägt.^[1]

Danach laufen Claude Codes eingebauter Befehl /simplify, ein /qa-Durchlauf und ein Codex-Review. Der wichtigste Kniff: Codex prüft nur noch die Korrekturen, höchstens drei Runden lang. Vorher führten wiederholte Gesamtprüfungen zu Pull Requests von rund 3.000 Zeilen.^[1] Die Größenbremse steckt also in der Prüfschleife und nicht nur im Prompt. Nunemakers Leitsatz dazu: „No PR beats a weak PR.“^[1]

Was haben 269 Pull Requests tatsächlich gebracht?

Von 269 Pull Requests sind 250 übernommen, 16 offen und 3 ohne Merge geschlossen. Median: 43 Zeilen und 2,7 Stunden bis zur Übernahme. 46 Änderungen entfernten mehr Code, als sie hinzufügten.

Ein Beispiel ist die Seite PreachIndex: Alle Bibelstellen-Seiten teilten sich dieselbe Meta-Description, ein Helfer von 27 Zeilen erzeugt jetzt spezifische Texte.^[1]

Die GitHub-Beiträge pro Tag stiegen von 31,2 in der ersten Oktoberhälfte auf 117,3 im Nunebot-Zeitraum.^[1] Nunemaker bezeichnet die Zahl selbst als wenig aussagekräftig, weil der Agent bei jedem Schritt committet und ein Pull Request mehrfach zählt.^[1]

Was können Agenturen und Inhouse-Teams in der DACH-Region daraus mitnehmen?

Nachbauen lässt sich das Prinzip, nicht die Zahlen: kleine Änderungen, Beleg im Pull Request, begrenzte Rechte. Mit Kundendaten sollten Sie vorher Datenschutz und Zuständigkeit für Freigaben klären.

Das Fünf-Pull-Requests-Limit pro Repository übernimmt Nunemaker nach eigener Aussage von Dependabot.^[1] Bei dessen Versionsupdates liegt die Grenze standardmäßig bei fünf offenen Pull Requests.^[2] Der Unterschied: Dependabot hebt Abhängigkeiten an, Nunebot schlägt inhaltliche Änderungen vor, und genau dort entscheidet die Prüfung über die Qualität. Wie verbreitet solche Agenten sind, zeigen die Conductor-Übernahme durch Meta und die KI-gestützten Kernel-Patches von Linus Torvalds.

Nunebot liest laut Nunemaker Fehlerberichte und Support-Gespräche in Crisp, Help Scout und Jelly, schreibt aber nicht zurück.^[1] In Support-Verläufen stehen oft Namen und E-Mail-Adressen. Setzen Sie Ähnliches in der EU ein, brauchen Sie mit dem KI-Anbieter einen Auftragsverarbeitungsvertrag nach Artikel 28 DSGVO. Der Agent sollte nur lesen dürfen. Das ist eine redaktionelle Einordnung, keine Rechtsberatung. Zur Frage, wo die Autonomie eines Agenten enden muss, passt der Beitrag Stopp-Knopf für KI-Agenten.

Für den Einstieg genügt ein Repository mit Tests und grüner CI. Verlangen Sie in der Vorlage für Pull Requests Begründung, Beleg und Rückfallplan und sammeln Sie jede Ablehnung als Regel. Alle Zahlen stammen von Nunemaker selbst, unabhängig geprüft sind sie nicht.

Quellen

Mehr Newshunger?

• Anthropic: Claude pflegt sein Gedächtnis im Leerlauf
• Goldman Sachs entzieht Tradern und Bankern Claude Code
• WordPress Studio baut Websites jetzt per Chat mit KI-Agent
• Automattic startet Spacefast: Hosting für Apps aus dem KI-Chat
• Petdex: Animierte Begleiter für Coding-Agenten
• Alle Beiträge zum Thema KI