Wenn die Community den Code nicht mehr schreibt

Am 19. August 2026 hat Fabien Potencier auf dem Symfony-Blog beschrieben, was er im neuen Repository Symfony Language Tools ausprobiert. Der Tab für Pull Requests ist abgeschaltet. GitHub erlaubt diese Einstellung seit kurzem auch für öffentliche Repositories.

Offen bleiben die Issues: Fehlermeldungen, Feature-Wünsche, Untersuchungen. Wer etwas beitragen will, beschreibt das Problem. Der Maintainer sichtet, aus dem Issue wird der Auftrag für einen Coding-Agenten, der Implementierung, Tests und Dokumentation schreibt. Geprüft und freigegeben wird jede Änderung weiterhin von einem Menschen.

Das Ganze gilt für dieses eine Repository. Am Framework selbst ändert sich nichts, dort sind Pull Requests weiter willkommen. Potencier hat das Projekt von der ersten Zeile an mit Coding-Agenten gebaut, und dabei hat sich verschoben, was ihm an einem Beitrag am meisten wert ist.

Was für das Modell spricht

Der Kontext liegt beim Melder. Wer einen Fehler erlebt, kennt den Editor, die Version, die Konfiguration, den Aufbau des Projekts und die Datei, die offen war, als es krachte. Potencier nennt diesen Kontext kostbar, und er hat recht: Ein fertiger Patch zeigt eine Lösung und verschweigt die Situation, aus der sie entstanden ist. Ein guter Fehlerbericht macht es umgekehrt.

Die Rechnung beim Review geht auf. Einen Pull Request zu prüfen heißt, die Absicht zu verstehen, die Änderung gegen die Architektur zu halten, die Tests zu lesen und Kompatibilität, Datenschutz und Performance abzuwägen. In einem jungen Projekt, dessen Architektur sich noch bewegt, ist der Weg über ein gutes Issue oft der kürzere. Wir haben an anderer Stelle beschrieben, warum Review inzwischen der Flaschenhals ist und nicht das Schreiben.

Die Hürde sinkt. Ein Beitrag verlangt jetzt eine gute Beschreibung. Wer die Sprache des Projekts nicht schreibt, den Fehler aber jeden Tag sieht, kann trotzdem etwas liefern. KI-Hilfe beim Verfassen ist ausdrücklich erwünscht: Ein Agent, der Zugriff auf das betroffene Projekt hat, liest Abhängigkeiten, Editor-Einstellungen, Quelldateien und Logs zusammen und schreibt daraus einen Bericht, für den ein Mensch eine Stunde gebraucht hätte.

Und es entstehen keine Karteileichen. Pull Requests, die ein halbes Jahr offen liegen, kosten beide Seiten Nerven. Den einen die Arbeit, die niemand anfasst, den anderen das schlechte Gewissen bei jedem Blick in die Liste.

Was es kostet

Die Leiter verschwindet. Der übliche Weg in ein Projekt führte über Code. Erst ein Tippfehler in der Doku, dann ein kleiner Bugfix, irgendwann ein Feature, und nach ein paar Jahren hat jemand Schreibrechte und trägt das Projekt mit. Jede Sprosse dieser Leiter war ein Pull Request. Ohne sie stellt sich die Frage, wer ein Projekt in fünf Jahren übernimmt, wenn der Gründer keine Lust mehr hat.

Bindung entsteht durch Arbeit. Wer eine Woche an einem Patch sitzt, bleibt dem Projekt verbunden, auch wenn der Patch abgelehnt wird. Ein Issue schreibt man in zwanzig Minuten. Dazu kommt der praktische Teil: Der Nachweis dessen, was jemand kann, steht bisher in der Historie fremder Repositories. Ein gemeldetes Problem taucht dort nicht auf.

Ein Patch ist ein Argument, das laufen kann. Wer widerspricht, wie ein Maintainer ein Problem sieht, konnte bisher eine funktionierende Alternative zeigen. Diese Form der Auseinandersetzung fällt weg, wenn nur noch beschrieben wird. Die Entscheidung über Umfang und Umsetzung liegt vollständig bei dem, der die Agenten laufen lässt.

Die fremden Augen fehlen in eine Richtung. Beim Review eines Beitrags las bisher auch der Beitragende den Code des Projekts, oft gründlicher als jeder andere von außen. Diese Kontrolle war ein Nebenprodukt, das im Issue-Modell entfällt.

Der Engpass wandert. Wenn niemand mehr Code beisteuert, hängt jede Umsetzung an einem Menschen mit einem Agenten-Abo. Beitragende waren immer auch Kapazität. Wie sich das anfühlt, wenn ein Projekt schneller wächst, als eine Person es verantworten kann, haben wir hier beschrieben.

Ein Versuch mit Rückfahrkarte

Potencier hält beide Ausgänge offen: Funktioniert das Modell, behält er es oder passt es an. Funktioniert es nicht, macht er die Pull Requests wieder auf. Er will messen, wie gut die Issues werden, wie lange es bis zur Umsetzung dauert, wie sich das für die Melder anfühlt und was ohne Pull Requests verloren geht.

Der Versuch läuft auf einem kleinen, jungen Repository, das von Anfang an für diese Arbeitsweise gebaut wurde. Was er über ein fünfzehn Jahre altes Framework mit tausenden Beitragenden aussagt, weiß im Moment niemand.

Wir arbeiten jeden Tag mit Software, die es ohne freiwillig geschriebenen Code nicht gäbe, und wir geben selbst Code zurück. Deshalb bleibt eine Frage hängen, auf die wir keine Antwort haben:

Was hält eine Community zusammen, wenn alle beschreiben, was fehlt, und niemand mehr dieselbe Datei anfasst?