Next.js hatte im August 2026 noch 2.244 offene GitHub-Issues. Im Januar 2025 waren es zeitweise sogar 3.109 gewesen. Gleichzeitig kommen laut Next.js im Schnitt etwa 36 neue Reports pro Woche dazu.
Das klingt erst einmal nach einem normalen Problem eines großen Open-Source-Projekts. In so einem Backlog liegen aber nicht nur aktuelle Bugs. Dazwischen stecken Duplikate, Probleme mit alten Versionen, längst behobene Fehler und Reports, die heute niemand mehr reproduzieren kann.
Next.js hatte dafür schon klassische Stale-Regeln eingesetzt. Nach langer Inaktivität wurden Issues markiert und später geschlossen. Das räumt auf, kann aber auch echte Bugs erwischen, nur weil längere Zeit niemand mehr kommentiert hat.
Deshalb hat das Team einen Agenten gebaut, der genau diese Recherche übernimmt.
1.462 geschlossene Issues – aber nicht einfach durch einen Bot
Bis zum 4. September wurden 1.462 Issues im Repository geschlossen. Gleichzeitig kamen 218 neue Reports dazu, trotzdem sank der offene Bestand auf 995.
Die Zahl braucht etwas Kontext: Die 1.462 Schließungen umfassen laut Next.js auch Issues, die Maintainer außerhalb dieser Agenten-Review geschlossen haben. Es wäre also falsch zu schreiben, ein Bot habe allein 1.462 Tickets automatisch weggeklickt.
Der Agent hat alte Reports untersucht, Reproduktionen geprüft, ähnliche Issues gesucht und relevante Pull Requests oder Commits zusammengetragen. Die Ergebnisse landeten anschließend in einer Queue für Maintainer.
Gerade bei alten Bugs steckt dort viel Arbeit. Ein Report aus dem Vorjahr kann heute längst durch einen anderen Commit behoben sein. Um das sauber festzustellen, muss jemand die Historie lesen, eine Reproduktion starten und im Zweifel mehrere Versionen testen.
Bei zehn Issues geht das nebenbei. Bei zweitausend nicht mehr.
Der Agent heißt closability
Next.js hat dafür auf Vercels Open-Source-Agentenframework eve einen spezialisierten Agenten namens closability gebaut. Laut dem Team lief der große Backlog-Durchlauf mit GPT-5.6 Luna und maximalem Reasoning-Aufwand.
Eine Untersuchung dauerte im Durchschnitt ungefähr 30 Minuten. Weil die Fälle weitgehend unabhängig voneinander waren, wurde die Parallelität nach und nach auf bis zu 200 gleichzeitig laufende Sessions erhöht.
Das ist für mich ein sinnvolleres Bild von Agentenarbeit als die übliche Demo, in der ein einzelner Agent möglichst lange autonom durch ein Repository läuft. Hier sind die Aufgaben kleiner und klarer begrenzt: einen konkreten Report verstehen, Belege sammeln und eine Empfehlung liefern.
Die Entscheidung lag beim großen Backlog-Durchlauf weiterhin beim Maintainer.
Die Arbeit steckt vor dem Klick auf „Close“
Die Verteilung der geschlossenen Reports zeigt ziemlich gut, wofür die Zeit draufgeht.
543 Issues, also rund 37 Prozent, betrafen Probleme, die bereits behoben waren. 278 waren Duplikate. 237 beschrieben erwartetes Verhalten. 89 ließen sich nicht mehr reproduzieren und 66 bezogen sich auf nicht mehr unterstützte oder inzwischen obsolete Versionen.
Ein „already fixed“-Label klingt banal. Jemand muss aber erst beweisen, dass der Fehler wirklich weg ist und nicht nur auf einem anderen Setup weiterhin auftaucht.
Genau da sehe ich den stärkeren Einsatz für Coding-Agenten. Nicht jede sinnvolle Automatisierung muss am Ende einen Pull Request produzieren. In größeren Repositories kostet technische Recherche oft genauso viel Zeit wie die eigentliche Änderung: alte Discussions lesen, Regressionen eingrenzen, Commits vergleichen, Versionen testen.
Wenn ein Agent diese Vorarbeit zuverlässig erledigt und die Quellen direkt mitliefert, kann ein Maintainer sehr viel schneller entscheiden. Wenn er dagegen nur eine Einschätzung ohne nachvollziehbare Belege ausspuckt, verschiebt sich die Arbeit lediglich.
Ein weiterer Punkt aus dem Next.js-Bericht passt dazu: Coding-Agenten machen es inzwischen leichter, sehr ausführliche Bugreports zu erstellen. Das hilft bei guten Reproduktionen, erhöht aber auch das Volumen im Tracker. Die Kosten für das Schreiben eines Reports sinken; die Kosten für das Lesen und Prüfen verschwinden dadurch nicht.
Der Issue-Tracker wird für Agenten zu untrusted input
closability liest Texte und Repository-Inhalte, die von beliebigen Nutzern stammen können. Next.js hat den Agenten deshalb ausdrücklich so konfiguriert, dass er Anweisungen aus Issue-Texten oder Repository-Inhalten ignorieren soll.
Das ist ein Detail, das bei solchen Workflows schnell wichtiger wird als das eigentliche Modell.
Für einen Menschen ist ein GitHub-Issue offensichtlich Inhalt. Für einen Agenten ist es zunächst einfach Text, während er gleichzeitig Tools benutzen und Code ausführen kann. Sobald öffentliche Issues, Pull Requests oder Dokumentationen Teil eines Agenten-Workflows werden, muss dieser Input wie nicht vertrauenswürdige externe Daten behandelt werden.
Der DseWiki-Fall, über den wir hier im Blog bereits geschrieben haben, war ein deutlich extremeres Beispiel für dasselbe Grundproblem: Agenten bekommen Fähigkeiten und externe Informationen, und die Grenzen zwischen Lesen, Interpretieren und Handeln müssen technisch sauber gesetzt sein.
Next.js automatisiert inzwischen vorsichtig weiter
Nach dem großen Backlog-Durchlauf ist Next.js einen Schritt weitergegangen.
closability untersucht inzwischen regelmäßig ältere offene Issues. Bei besonders eindeutigen Fällen darf ein zweiter Agent gezielt nach Gründen suchen, warum das Ticket offen bleiben sollte. Erst wenn beide Bewertungen für eine Schließung sprechen, kann eine separate GitHub Action den Kommentar posten und das Issue schließen.
Next.js startet dabei mit maximal 25 automatischen Schließungen pro Woche.
Das gefällt mir deutlich besser als ein Agent, der seine eigene Einschätzung erzeugt, bestätigt und anschließend selbst ausführt. Die zweite Prüfung ist absichtlich gegen die erste Empfehlung gerichtet. Dazu kommt ein Reopen-Mechanismus: Beteiligte Nutzer können eine falsche Schließung innerhalb eines Zeitfensters wieder anstoßen.
Fehler werden dadurch nicht ausgeschlossen. Sie werden aber billiger zu korrigieren.
Codeänderungen bleiben laut Next.js weiterhin im menschlichen Review, bevor sie in das Framework gemergt werden.
Was wir davon bei Quavon mitnehmen würden
Wir arbeiten selbst viel mit Next.js und haben ebenfalls Issues, technische Tasks und ältere Entscheidungen, bei denen der größte Aufwand oft vor der eigentlichen Änderung liegt.
Für so etwas würde ich einen Agenten eher einsetzen als für möglichst viel Autonomie im Repository.
Ein brauchbarer Workflow wäre zum Beispiel: Ticket lesen, aktuellen Code prüfen, verwandte Commits und Issues suchen, Problem reproduzieren und anschließend eine kurze Einschätzung mit Belegen zurückgeben. Danach entscheidet jemand aus dem Team, was daraus wird.
Für die Bewertung wäre mir die Zahl der automatisch geschlossenen Tickets ziemlich egal. Interessanter wären die Fälle, in denen ein Maintainer widerspricht, die Zahl später wieder geöffneter Issues und die tatsächlich gesparte Recherchezeit.
Wenn wir die komplette Untersuchung nach dem Agenten noch einmal selbst machen müssen, ist wenig gewonnen.
Die 1.462 geschlossenen Issues machen eine gute Überschrift. Spannender finde ich aber, dass selbst ein aktiv gepflegtes Projekt wie Next.js zeitweise mehr als zweitausend offene Reports vor sich herschiebt.
Open-Source-Maintenance skaliert schlecht. Agenten können dabei wahrscheinlich helfen – besonders an den Stellen, an denen viel gelesen, geprüft und verglichen werden muss, bevor überhaupt jemand Code anfasst.
Quellen
Next.js Blog, 4. September 2026: „How we closed 1,500 GitHub issues in one month“ https://nextjs.org/blog/how-we-closed-1500-github-issues
Next.js Blog, 12. Februar 2026: „Building Next.js for an agentic future“ https://nextjs.org/blog/agentic-future
Next.js Agent Evals: Benchmarks für AI Coding Agents auf realen Next.js-Aufgaben https://nextjs.org/evals