Kernaussagen insgesamt
- Es geht nicht um ein „Todesurteil für das PR-System an sich“, sondern um die Realität, dass PRs im KI-Zeitalter nicht mehr als „Mittel zur Vermittlung von Verständnis“ funktionieren.
- Das Kernproblem liegt noch vor der Codequalität: Immer häufiger werden Kontext, Absicht und Abwägungen, die den Code begleiten müssten, über PRs nicht mehr vermittelt.
- Das Fazit lautet: Das Wesen von PRs ist weiterhin gültig, aber ohne Änderungen an der Betriebsweise (den Gate-Kriterien) können sie ihre Rolle als Verteidigungslinie nicht mehr erfüllen.
1. Problemaufriss: Warum geraten PRs ins Wanken?
- Wer die Ursache des PR-Versagens darin sieht, dass „Reviewer faul geworden sind“, betrachtet das Problem falsch.
- Die eigentliche Ursache ist die zunehmende Häufung des Phänomens, dass PR-Reviews kein Verständnis mehr vermitteln. Mit anderen Worten: Reviewer (Entwickler) verstehen die Absicht und den Kontext eines PRs nicht mehr.
- KI senkt die Kosten zur Erstellung von PRs drastisch, verstärkt dabei aber die bestehende Asymmetrie (Erstellung ist schnell, Prüfung ist langsam).
2. Die ursprüngliche Rolle von PRs: kein Code-Freigabeprozess, sondern ein Vertrag zur Verantwortungsübergabe
- Ein PR war nie nur ein Verfahren, bei dem man Syntax des Codes oder das Bestehen von Tests prüft.
- Die Struktur enthielt implizit das Versprechen des Autors: „Ich kann erklären, warum ich es so gebaut habe.“
- Reviewer prüfen nicht nur den Code selbst, sondern auch die dahinterstehenden Abwägungen und die Designabsicht.
- Der Merge-Button war also nicht bloß ein Button zur Codefreigabe, sondern eine soziale Vereinbarung des Teams, gemeinsam die Verantwortung für diese Änderung zu übernehmen.
3. Das Gate war schon bisher verwundbar
- Open Source war schon immer das Umfeld, in dem die Schwachstellen der PR-Struktur besonders sichtbar wurden.
- Mentale und körperliche Erschöpfung von Maintainer:innen, Kontextunterschiede und die Vielfalt der Beitragenden führten leicht dazu, dass PRs in formale Freigaben abrutschten.
- Der Backdoor-Vorfall bei xz Utils zeigte weniger ein Versagen der Automatisierung als vielmehr, wie ausgebrannte menschliche Gates selbst zur Angriffsfläche werden.
Schon vor KI waren PR-Gates also fragile, und die Warnsignale ihrer Grenzen hatten sich bereits aufgestaut.
- Backdoor-Vorfall bei xz Utils: ein Open-Source-Supply-Chain-Angriff, bei dem ein Contributor, der über mehr als zwei Jahre Vertrauen aufgebaut hatte, über PRs eine Backdoor einschleuste.
4. Die von KI ausgelöste Veränderung: PR-Flut und explodierende Review-Asymmetrie
- Durch KI-Coding-Tools steigen Geschwindigkeit und Menge der PR-Erstellung sprunghaft an.
- Reviews hängen dagegen weiterhin von menschlicher Zeit, Konzentration und Kontextverständnis ab.
- Das Ergebnis ist ein Muster aus mehr Code, größeren PRs, längerer Review-Zeit und mehr Incidents.
- Das ist keine Absage an „mehr Produktivität“ an sich, sondern eine Warnung: Beschleunigung ohne Governance kann sich als Gift erweisen.
5. Das tiefere Problem: Code, der funktioniert, aber den niemand erklären kann
- Das Risiko von KI-Code besteht nicht nur in „Code, der sofort kaputtgeht“.
- Das größere Problem ist die Anhäufung von Code, der Tests besteht und kompiliert, bei dem aber keine Erklärung existiert, warum er so geschrieben wurde.
- Wenn später ein Ausfall auftritt, korrigiert das Team nicht einfach etwas, sondern interpretiert Code ohne erkennbare Absicht anhand von Vermutungen.
- Im Unterschied zu gewöhnlichen Bugs ist das gefährlicher, weil Spuren von Designentscheidungen und ein verantwortlicher Urheber fehlen.
6. Der verborgene Schlüsselbegriff: KI füllt Informationslücken plausibel auf
- KI neigt eher dazu, Unwissen nicht offenzulegen, sondern Lücken mit plausibel wirkendem Code zu füllen.
- Das Problem ist, dass diese Lücken (verborgene Annahmen, unbestätigte Einschränkungen) in der PR-Phase oft nicht sichtbar sind.
- Deshalb können „Der Code läuft / die Dokumentation klingt plausibel / die Checks sind grün“ allein keine Sicherheit mehr garantieren.
- Was im PR-Gate geprüft werden muss, ist letztlich nicht die Frage, ob der Code kompiliert, sondern ob für diese Änderung ein nachvollziehbares reasoning (warum / was / unter welchen Einschränkungen) vorhanden ist.
7. Was der Fall OpenClaw zeigt: ein Umfang und ein Tempo, die PRs nicht mehr tragen können
- Der Text nennt OpenClaw als repräsentativen Fall, in dem sich der Kollaps von PRs komprimiert gezeigt habe.
- OpenClaw (ursprünglich Clawdbot) war ein experimentelles Playground-Projekt mit persönlichem Charakter, das Peter Steinberger etwa im November 2025 startete.
- Innerhalb kurzer Zeit (rund 10 Wochen) wuchs es explosionsartig und zog viele Nutzer, Beiträge und externe Aufmerksamkeit an.
- Dabei kamen Sicherheitsprobleme, bösartige Skills/Beiträge und eine wachsende Review-Last zusammen, sodass ein persönliches bzw. kleines Maintainer-Setup an seine Grenzen stieß.
- Später (im Februar 2026) veröffentlichte er eine Rückschau zum Projekt und erwähnte, dass für mehr Sicherheit mehr Struktur, Ressourcen und Zugang zu aktueller Forschung nötig seien.
- Anschließend übergab er das Projekt und wechselte zu OpenAI.
- Der Text versteht diesen Punkt nicht als persönliche Kritik, sondern als Beispiel für die Lücke zwischen „erfolgreichem Prototyping“ und dem sicheren Betrieb allgemeiner Infrastruktur.
- Entscheidend sei zudem weniger ein einzelner Implementierungsfehler als vielmehr eine Struktur, in der Umfang, Tempo und Vielfalt der Absichten von Beiträgen die menschliche Review-Fähigkeit überstiegen.
- Selbst wenn Maintainer Sicherheitsverbesserungen weiter vorantrieben, liefen Expositionsgeschwindigkeit und Behebungsgeschwindigkeit nicht im selben Rennen.
- Die Ursache des Scheiterns war also nicht, dass es „schlecht gebaut“ war, sondern dass ein Gate, das ursprünglich für ein persönliches/lokales Vertrauensmodell entworfen wurde, globalem Maßstab nicht standhielt.
8. Die Bedeutung der GitHub-Einstellungsänderung: keine neue Funktion, sondern ein Warnsignal
- GitHub kündigte am 13. Februar 2026 offiziell eine Option zum Deaktivieren von PRs an.
- Der Autor versteht das jedoch nicht nur als komfortable Zusatzfunktion, sondern als stilles Eingeständnis, dass PRs in manchen Repositories selbst zu einem Betriebsrisiko geworden sind.
- Das sollte als Signal gelesen werden, dass selbst Plattformen die Annahme „PRs sind immer gut“ nicht mehr problemlos aufrechterhalten können.
9. Das praktische Fazit des Textes: PRs nicht abschaffen, sondern das Gate neu definieren
- Es ist kein Plädoyer dafür, die Entwicklung von KI-Code-Tools einzustellen.
- Die eigentliche Frage lautet vielmehr nicht „Ob man KI nutzt“, sondern „ob man sie ohne ein funktionierendes Gate nutzt“.
- Benötigt werden weniger bloße Regellisten als vielmehr Betriebsprinzipien wie Erklärbarkeit, vorgelagerte Architektur/Designarbeit, das Offenlegen unbestätigter Punkte, das Recht von Maintainer:innen zur Ablehnung und gesicherte Nachverfolgbarkeit.
- Ein PR, dessen Gründe sich nicht nachvollziehen lassen, ist kein geistiges Eigentum, das ein Team besitzt, sondern eine Schuld, die das Team beherrschen wird.
10. Ein-Satz-Zusammenfassung
- Der Zweck von PRs ist nicht das bloße Durchwinken von Code, sondern die gemeinsame Übergabe von Verständnis und Verantwortung.
- Die Schlüsselfrage im KI-Zeitalter lautet nicht „Läuft der Code?“, sondern „Kann dieser Code erklärt werden?“
- Diese Frage ist kein Hindernis für Produktivität, sondern die Mindestbedingung, um die letzte Verteidigungslinie von Software zu schützen.
2 Kommentare
Die reviewte Person klickt nur einmal, während sich nur die reviewende Person den Kopf zerbricht – es ist zu einem Mittel geworden, nicht nur Verantwortung abzuwälzen, sondern die Arbeit gleich komplett auf andere abzuschieben.
Ein sehr nachvollziehbarer Artikel.
Ich habe in den letzten Monaten sehr darunter gelitten, zu sehen, wie von KI erzeugter Code als PRs von Teammitgliedern eingereicht wurde, und habe viele Methoden eingeführt, um das zu verbessern.
Zusätzlich dazu, den Umfang von PRs einzugrenzen, wie es im Haupttext behandelt wird, denke ich auch darüber nach, was überhaupt reviewt werden soll.
Ich denke über Code Reviews nach, bei denen nicht der Code selbst, sondern die Absicht dahinter reviewt wird.