Pull Requests waren nie für Ihr Team gedacht

10 Min. Lesezeit

Die Schranke, die zum Käfig wurde

Kurze Geschichte des Misstrauens gegenüber Fremden

Bevor es GitHub gab, nahmen Open-Source-Projekte Beiträge über Mailinglisten entgegen. Man schrieb einen Patch, formatierte ihn nach den Konventionen des Projekts, schickte ihn an die Liste und wartete. Maintainer, die man nie getroffen hatte, lasen den Code, stritten öffentlich darüber und akzeptierten oder lehnten ihn ab. Der Linux-Kernel funktioniert bis heute so. Linus Torvalds prüft Patches von Tausenden Entwicklern, mit denen er nie ein Büro geteilt hat. Dieses Verfahren existiert, weil Vertrauen fehlt.

GitHub führte Pull Requests 2008 ein, um genau diesen Ablauf zu formalisieren. Ein Pull Request ist ein Vorschlag: „Ich habe etwas geschrieben. Bitte prüfen, bevor es in euer Projekt einfließt.” Das entscheidende Wort ist euer. Der Beitragende besitzt die Codebasis nicht. Der Maintainer schon. Der Pull Request markiert die Grenze zwischen innen und außen.

Für Open Source ergibt das absolut Sinn. Wenn ein Fremder Code zu einem Projekt einreicht, das er nicht betreut, sollte jemand mit Architekturkenntnis ihn prüfen. Der PR ist eine Schranke, und Schranken sind nützlich, wenn man nicht weiß, wer anklopft.

Dann schauten Unternehmen auf GitHub und dachten: „Das sollten unsere Entwickler auch so machen.”

Und genau da lief es schief.

Ihr Team besteht nicht aus Fremden

Ein eingespieltes Team teilt Kontext. Die Mitglieder kennen die Codebasis. Sie kennen die Fachlichkeit. Sie saßen in denselben Besprechungen, haben über dieselben Architekturentscheidungen gestritten und nachts um zwei denselben Produktionsvorfall behoben.

Pull Requests behandeln jeden Beitrag so, als käme er von außen. Jede Änderung braucht eine Freigabe, bevor sie den Hauptzweig erreicht. Jeder Entwickler muss warten, bis jemand anders auf den grünen Knopf klickt, bevor seine Arbeit zählt.

In einem Fünf-Personen-Team, das regelmäßig im Pair arbeitet und täglich über den Code redet, ist das Verwaltungsaufwand, der sich als Qualitätssicherung verkleidet. Sie haben diese Leute eingestellt. Sie haben sie eingearbeitet. Sie haben ihnen Zugang zur Produktionsumgebung gegeben. Aber Sie vertrauen ihnen nicht, auf den Hauptzweig zu pushen, ohne Erlaubnisschein?

Das Gegenargument ist immer dasselbe: „Was, wenn jemand einen Fehler macht?” Gute Frage. Nur fängt der PR den Fehler nicht ab. Eine Studie von Microsoft Research ergab, dass das Hauptmotiv für Code-Reviews bei Microsoft Wissensverbreitung war, nicht Fehlererkennung. Die übergroße Mehrheit der Review-Kommentare betrifft Codestil und Konventionen, nicht Fehler. Die Fehler, die zählen, subtile Logikfehler, Race Conditions, missverstandene Geschäftsregeln, rutschen durch, weil Prüfer im Schnitt wenige Minuten auf ein Diff schauen, das sie nicht geschrieben haben und nicht vollständig verstehen.

Die Stempel-Fließband-Freigabe

So sehen Pull-Request-Reviews in den meisten Teams aus: Der PR wird geöffnet. Irgendwo zwischen drei und sechs Minuten später klickt jemand auf „Genehmigen”. Der Kommentar lautet „LGTM” oder besteht aus einem Daumen-hoch-Emoji. Keine Fragen gestellt. Keine alternativen Ansätze vorgeschlagen. Kein Hinweis darauf, dass der Prüfer mehr als den PR-Titel gelesen hat.

Ich habe in der Praxis zwei Varianten erlebt. Die schnelle: Freigabe in unter fünf Minuten bei Diffs von Hunderten Zeilen. Niemand liest zweihundert Zeilen Code in fünf Minuten. Der Prüfer überfliegt den Titel, vielleicht die Dateiliste, klickt auf „Genehmigen”. Kein Auschecken, kein lokales Testen, kein Verstehen. Ein Feuer-Emoji und ein grünes Häkchen. Die langsame Variante: Jemand checkt den Branch tatsächlich aus, startet ihn lokal, versucht zu verstehen, was sich geändert hat und warum. Das dauert einen Tag. Ein voller Arbeitstag geht für das Prüfen fremder Änderungspakete verloren. Keine der beiden Varianten funktioniert. Die schnelle fängt nichts ab. Die langsame vernichtet den Durchsatz. Beide geben vor, Qualitätssicherung zu sein.

Das Gefährliche ist nicht die fehlende Aufmerksamkeit. Das Gefährliche ist das Vertrauen, das es erzeugt. Das Team glaubt, einen Prüfprozess zu haben. Die PR-Historie zeigt Freigaben, Kommentare, grüne Häkchen. Führungskräfte verweisen in Audits darauf. „Wir haben verpflichtende Code-Reviews.” Dieser Satz erzeugt die Illusion, dass jemand Probleme abfängt. Niemand fängt Probleme ab. Der Prozess fängt nichts ab. Aber er sieht so aus, und das ist schlimmer als gar kein Prozess, denn ohne Prozess weiß man wenigstens, dass man ungeschützt ist.

Wenn ein Produktionsvorfall eintritt, schaut das Post-Mortem auf den Commit, findet den PR, sieht die Freigabe und schließt: „Der Prüfprozess hat funktioniert. Das war ein Grenzfall, den niemand hätte finden können.” Niemand stellt die naheliegende Frage: Hat der Prüfer den Code tatsächlich gelesen? Die Antwort ist fast immer nein. Aber das grüne Häkchen sagt ja, und das grüne Häkchen steht im Bericht.

Jetzt schreibt die KI den Code, den vorher schon niemand gelesen hat

Wir setzen KI-Codegenerierung jeden Tag ein. Sie ist ernsthaft leistungsfähig. Einen fehlschlagenden Test schreiben, die KI eine Umsetzung vorschlagen lassen, das Ergebnis bewerten, anpassen, committen. TDD mit einem KI-Pairing-Partner auf Trunk-basierter Entwicklung erzeugt enge Rückmeldeschleifen, die schnell soliden Code liefern. Die KI schlägt vor, man hinterfragt, man verfeinert gemeinsam. Die Disziplin hat sich nicht geändert. Die Prinzipien sind Jahrzehnte alt. Das Werkzeug ist neu.

Das Problem ist nicht die KI. Das Problem ist, was passiert, wenn KI-generierter Code auf Pull-Request-Abläufe trifft.

Jetzt, wo alle verkünden, „Programmieren ist ein gelöstes Problem,” explodiert das Volumen an Code, das durch Pull Requests fließt. Entwickler, die früher fünfzig Zeilen am Tag geschrieben haben, erzeugen jetzt dreihundert. Die Diffs sind länger. Der Code sieht plausibel aus. Er besteht das Linting. Vielleicht hat er sogar Tests, ebenfalls generiert, ebenfalls ungelesen.

Vorher hat niemand den Code gelesen. Jetzt gibt es dreimal so viel davon.

KI-generierter Code wirkt souverän. Syntaktisch sauber. Variablennamen nachvollziehbar. Kommentare vorhanden. Er hat die Form von Code, den jemand mit Erfahrung geschrieben hat. Wenn man im Dialog damit arbeitet, Test zuerst, erkennt man die Lücken sofort: die Grenzfälle, die er übersehen hat, die Geschäftsregel aus einer Slack-Nachricht von vor acht Monaten, der Grund für genau diese Nullprüfung. Die enge Rückmeldeschleife von Rot-Grün-Refactoring lässt Halluzinationen nicht überleben.

Aber denselben Code in einen Pull Request kippen? Der Prüfer, der in vier Minuten auf „Genehmigen” klickt, fängt davon nichts ab. Vor der KI hat wenigstens der Entwickler, der den Code geschrieben hat, ihn verstanden. Man konnte rübergehen und fragen. Der PR-Ablauf hat jetzt Code, der ohne vollständigen Kontext generiert, ohne Gespräch eingereicht und ohne Verständnis freigegeben wurde. Das grüne Häkchen überdeckt alle drei Lücken gleichermaßen.

KI als Pairing-Partner funktioniert. KI als Code-Kanone, die in eine PR-Warteschlange feuert, nicht. Der Unterschied liegt nicht an der KI. Er liegt daran, ob irgendjemand im Dialog mit dem Code ist, bevor er ausgeliefert wird.

Pull Requests zerstören Continuous Integration

Continuous Integration bedeutet, dass jeder Entwickler seine Arbeit mehrmals am Tag in die gemeinsame Codebasis integriert. Nicht einmal am Tag. Nicht am Ende eines Features. Mehrmals am Tag. Kleine Änderungen, häufig integriert, sofort getestet.

Pull Requests arbeiten gegen jedes Element dieser Definition.

Ein Pull Request erzeugt einen Branch. Der Branch weicht vom Hauptzweig ab. Je länger der Branch lebt, desto weiter driftet er. Jede Stunde, die dieser Branch existiert, ohne zusammengeführt zu werden, ist eine Stunde, in der sich Integrationsrisiko aufbaut. Andere Entwickler ändern dieselbe Codebasis. Zusammenführungskonflikte wachsen. Annahmen veralten.

Dann steht der PR in einer Warteschlange. Er wartet auf einen Prüfer. Der Prüfer ist beschäftigt. Er hat eigene PRs einzureichen und eigene Arbeit zu erledigen. In vielen Organisationen wartet ein durchschnittlicher PR Stunden. Manchmal Tage. Manche Teams messen ihre PR-Warteschlangen in Wochen.

Während dieser Wartezeit beginnt der Entwickler, der den PR eingereicht hat, neue Arbeit. Jetzt hat er zwei gedankliche Kontexte: die aktuelle Arbeit und die wartende Arbeit. Wenn die Rückmeldung kommt, muss er den Kontext wechseln. Er ist längst weiter. Der Code ist das Problem von gestern mit der Unterbrechung von heute.

Trunk-basierte Entwicklung beseitigt all das. Alle arbeiten auf dem Hauptzweig. Commits sind klein. Integration geschieht fortlaufend. Es gibt keinen Branch. Es gibt keine Warteschlange. Es gibt keine Schranke. Die Rückmeldeschleife ist kurz: schreiben, testen, committen, pushen. Wenn etwas kaputtgeht, weiß man es sofort, weil die Testsuite bei jedem Push läuft.

„Aber was ist mit unfertigen Features?” Feature Flags. Man liefert Code aus, der standardmäßig deaktiviert ist, und schaltet ihn frei, wenn er fertig ist. Der Code ist integriert, getestet und in Produktion. Er ist nur noch nicht für Nutzer sichtbar. Kein Branch. Kein PR. Keine Warteschlange.

Wofür Code-Reviews eigentlich da sind

Der eigentliche Wert davon, sich den Code eines Kollegen anzusehen, liegt nicht in der Fehlererkennung. Automatisierte Tests, Linter und statische Analyse finden Fehler zuverlässiger als ein Mensch, der freitags um 16:45 Uhr ein Diff überfliegt. Der eigentliche Wert ist gemeinsames Verständnis. Zwei Personen, die denselben Code betrachten, entwickeln ein geteiltes mentales Modell davon, wie das System funktioniert. Sie übertragen Kontext. Sie bauen kollektives Eigentum an der Codebasis auf.

Pull Requests taugen dafür nicht. Ein Diff in einem Browser-Tab zu lesen ist die denkbar schlechteste Art, die Arbeit eines Kollegen zu verstehen. Man sieht geänderte Zeilen. Man sieht nicht die Entscheidungen, die zu diesen Änderungen geführt haben. Man hört die Argumentation nicht. Man erlebt die Abwägungen nicht. Man gibt in Isolation frei, was in Isolation entstanden ist. Kein Verständnis wird übertragen. Kein Kontext wird geteilt.

Pair Programming leistet, was Code-Reviews versprechen. Zwei Entwickler sitzen zusammen und schreiben den Code gemeinsam. Die Prüfung findet in Echtzeit statt. Fragen werden gestellt, wenn sie relevant sind, während der Entstehung, nicht danach. Entwurfsentscheidungen werden diskutiert, solange Alternativen noch günstig sind. Einer schreibt den Test, der andere die Umsetzung. Verständnis fließt in beide Richtungen, fortlaufend.

Mob Programming erweitert diesen Ansatz. Das ganze Team arbeitet gleichzeitig am selben Code. Die Prüfung ist in die Entstehung eingebettet. Es gibt keinen separaten Prüfschritt, weil die Prüfung nie aufgehört hat.

Diese Ansätze fühlen sich langsamer an. Sind sie nicht. Pair Programming produziert weniger Fehler, was weniger Nacharbeit bedeutet. Gemeinsames Verständnis reduziert Wissensinseln, was weniger Situationen wie „Nur Tomasz weiß, wie das funktioniert” bedeutet. Wenn der Entwickler, der eine kritische Schutzlogik gebaut hat, das Unternehmen verlässt, verstehen vier Leute diese Logik, weil sie sie gemeinsam geschrieben haben. Nicht weil jemand einen Daumen hoch unter ein Diff gesetzt hat.

Wann Pull Requests sinnvoll sind

PRs sind nicht nutzlos. Sie werden falsch eingesetzt.

Pull Requests sind sinnvoll, wenn ein externer Beiträger Code zu einem Projekt einreicht, das er nicht betreut. Das ist der ursprüngliche Anwendungsfall, und er funktioniert nach wie vor.

Sie sind sinnvoll, wenn ein neues Teammitglied die Codebasis kennenlernt und explizite Rückmeldung wünscht. Das sollte befristet sein. Sobald die Person sicher im Umgang mit der Codebasis ist, geht sie zu Trunk-basierter Entwicklung über.

Sie sind sinnvoll in regulierten Umgebungen, in denen Prüfpfade dokumentierte Freigaben erfordern, etwa für ISO-Audits, BaFin-Anforderungen oder KRITIS-Nachweise. Aber seien Sie ehrlich, was dieser Prüfpfad enthält. Er enthält Unterschriften, kein Verständnis. Wenn Ihre Compliance-Vorgaben Nachweise für Code-Prüfung verlangen, prüfen Sie, ob Protokolle von Pair-Programming-Sitzungen diese Anforderung besser erfüllen als durchgewunkene PRs.

Verwenden Sie sie nicht als Ersatz für Vertrauen. Wenn Sie Ihrem Team genug vertrauen, ihm Produktionszugang zu geben, dann vertrauen Sie ihm auch, auf den Hauptzweig zu pushen.

Das Gespräch, das die Schranke ersetzt

Hören Sie auf, Code nach seiner Entstehung zu prüfen. Fangen Sie an, über Code zu sprechen, während er entsteht. Pairing. Mobbing. Reden Sie über das, was Sie bauen, und warum. Machen Sie Verständnis zum Standard und Isolation zur Ausnahme. Und nutzen Sie KI, um den Code selbst zu hinterfragen: Lassen Sie sie Grenzfälle finden, die Sie übersehen haben, Ihre Annahmen in Frage stellen, erklären, was eine Funktion tatsächlich tut im Vergleich zu dem, was Sie glauben. KI ist ein unermüdlicher Prüfer, der nie durchwinkt und nie aus sozialer Rücksicht auf „Genehmigen” klickt. Zeigen Sie ihr Ihren Code und fragen Sie „Was könnte hier schiefgehen?” Sie bekommen in dreißig Sekunden nützlicheres Feedback als die meisten PRs an einem ganzen Tag liefern.

Continuous Integration erfordert fortlaufendes Gespräch. Ein Pull Request ist ein verzögerter, asynchroner, isolierter Monolog. Ersetzen Sie ihn durch die echte Sache: Entwickler, die zusammenarbeiten und gemeinsames Verständnis aufbauen, Commit für Commit.

Ihr Team war nie eine Ansammlung von Fremden. Behandeln Sie es nicht wie eine.