- Beschreibt die Struktur, in der die Bearbeitungsgeschwindigkeit exponentiell sinkt, je mehr Freigabe- und Review-Stufen es in einer Organisation gibt, und führt als Beispiel an, dass jede Freigabestufe in der Praxis etwa eine 10-fache Verzögerung verursacht
- Selbst wenn AI-Coding-Tools das Schreiben von Code drastisch beschleunigen, verkürzt sich die Wartezeit (Latency) in der nachgelagerten Review-Pipeline nicht, sodass der Gesamteffekt auf die Geschwindigkeit gering bleibt
- Überträgt die Qualitätsphilosophie der Fertigungsindustrie von W. E. Deming auf Software und weist darauf hin, dass das Hinzufügen von QA-Stufen sowohl Qualität als auch Geschwindigkeit verschlechtert
- Reviews sollten reduziert und zugleich durch Modularisierung und eine vertrauensbasierte Qualitätskultur ersetzt werden; entscheidend sind strukturelle Verbesserungen, die Reviews selbst überflüssig machen
- Kleine Teams sind im AI-Zeitalter im Vorteil, und Organisationen sowie Systeme müssen so neu gestaltet werden, dass sie kleine, schöne Komponenten kombinieren
Das Gesetz, nach dem Review-Stufen 10-fache Verzögerungen erzeugen
- Wie beim Gesetz der Netzwerkeffekte entsteht mit wachsender Teamgröße Koordinations-Overhead; verdoppelt man ein Team, verdoppelt sich die Geschwindigkeit nicht
- Eine seit Jahrzehnten bekannte Faustregel: Jede zusätzliche Review-Stufe macht den Prozess 10-mal langsamer
- Es gibt dafür keine theoretische Begründung, aber in der Praxis wird dieses Phänomen immer wieder beobachtet
- Gemessen wird hier nicht der Aufwand (effort), sondern die Wall-Clock-Zeit, und der Großteil der zusätzlichen Zeit ist Wartezeit
- Konkrete Beispiele:
- Code für einen einfachen Bugfix schreiben: 30 Minuten
- Code-Review durch den Kollegen am Nebentisch: 300 Minuten (ca. 5 Stunden, ein halber Tag)
- Freigabe eines Designdokuments durch das Architektenteam: 50 Stunden (ca. 1 Woche)
- In den Zeitplan eines anderen Teams aufgenommen werden (z. B. für einen Kunden-Feature-Request): 500 Stunden (12 Wochen, 1 Geschäftsquartal)
- Auch die nächste Stufe mit 10 Quartalen (ca. 2,5 Jahren) ist nicht unrealistisch; selbst in einer vergleichsweise kleinen Firma wie Tailscale treten bei einem Wechsel der Produktrichtung Verzögerungen in dieser Größenordnung auf
AI kann dieses Problem nicht lösen
- Selbst wenn Claude 30 Minuten Coding in 3 Minuten erledigt, spart man 27 Minuten nur, um entweder direkt in Iterationen mit der AI Reviews zu machen oder ungeprüften Code an den Reviewer weiterzureichen
- Der Reviewer braucht weiterhin 5 Stunden, und wenn man Code weitergibt, den man selbst nicht gelesen hat, ärgert das den Reviewer
- Der wahre Wert von agentischem Coding soll darin liegen, große Ein-Wochen-Projekte in wenigen Stunden zu erledigen, doch das Ergebnis ist zu groß, als dass ein Reviewer es auf einmal prüfen könnte
- Es muss in kleine Einheiten zerlegt werden, und für jede entsteht ein 5-stündiger Review-Zyklus
- Ohne Designdokument gibt es auch keine absichtliche Architektur, also endet es am Ende doch in Design-Review-Meetings
- Das Ergebnis: Ein in 2 Stunden fertiggestelltes Projekt wird wieder zu einer Woche Arbeit
Der einzige Weg ist, Reviews zu reduzieren
- Die Voraussetzung der Singularitäts-Theorie: Ein System baut immer intelligentere Systeme, und wenn die für jede Verbesserung benötigte Zeit gegen null geht, entsteht explosives Wachstum
- Warum diese Theorie hier nicht überzeugt: Der größte Teil der Zeit, die zur Fertigstellung von etwas nötig ist, ist nicht eigentliche Arbeitszeit, sondern Wall-Clock-Zeit, also Warten und Verzögerung
- Latenz lässt sich nicht mit brute force überwinden
Kann man Reviews denn einfach weglassen?
- Viele erkennen inzwischen das Symptom: Die erste Pipeline-Stufe (AI-generierter Code) ist schneller geworden, doch die nachfolgenden Review-Stufen sind der Flaschenhals
- Die intuitive Lösung: Reviews stoppen → selbst wenn das Ergebnis grob ist, gilt die Logik, dass man bei 100-fach geringeren Kosten schon mit 1 % des Werts den Break-even erreicht
- Dieser Logik liegt jedoch eine ziemlich törichte Annahme zugrunde
- AI Developer's Descent Into Madness:
- Ein Prototyp wird überraschend schnell gebaut → fühlt sich wie eine Superkraft an
- Im Prototyp tauchen Bugs auf → die AI soll sie beheben
- Mit jeder Änderung entstehen genauso viele neue Bugs, wie behoben werden
- Der Irrglaube, ein AI-Agent finde seine eigenen Bugs, wenn er selbst Code-Reviews macht
- Man ertappt sich dabei, Daten direkt zwischen Agenten zu übergeben
- Man erkennt den Bedarf an einem Agent-Framework
- Man schreibt das Agent-Framework mit Agenten
- Rückkehr zu Schritt 1
- Claude Code ist erst seit einigen Monaten wirklich brauchbar, daher hat dieser Kreislauf erst vor Kurzem begonnen, und viele Kollegen sowie angesehene Personen stecken bereits in diesem Zyklus fest
Warum gibt es Reviews überhaupt?
- Wenn ein Unternehmen wächst, nehmen Zusammenarbeit, Reviews und Management-Stufen zu → sie sollen Fehler verhindern, weil mit größerem Maßstab auch die Kosten von Fehlern steigen
- Es kommt ein Punkt, an dem der durchschnittliche Zusatznutzen neuer Features kleiner wird als der durchschnittliche Schaden durch neue Bugs
- Da sich der Wert eines Features nicht einfach erhöhen lässt, bewegt man sich in Richtung Schadensbegrenzung
- Mehr Prüfungen und mehr Kontrolle verlangsamen zwar die Geschwindigkeit, aber die Qualität scheint monoton zu steigen → das wirkt wie eine Basis für kontinuierliche Verbesserung
- Doch „mehr Prüfungen und mehr Kontrolle“ ist nicht der einzige Weg, Qualität zu erhöhen, und zudem ein gefährlicher
„Qualitätssicherung (QA)“ senkt am Ende die Qualität
- Verweist auf die Qualitätsphilosophie von W. E. Deming, die in der japanischen Automobilindustrie populär wurde
- Problem der QA-Stufe in einer Fabrik: Widget herstellen → Inspektion/QA → Ausschuss entfernen → um Lücken zu vermeiden, eine zweite QA-Stufe hinzufügen
- In einem einfachen mathematischen Modell wirkt das vernünftig (wenn jede QA-Stufe 90 % der Defekte findet, führt eine zweite Stufe zu einer 100-fachen Reduktion)
- In einer Umgebung mit autonomen menschlichen Akteuren (agentic humans) werden jedoch die Anreize verzerrt:
- Das zweite QA-Team bewertet faktisch das erste QA-Team → es hat keinen Anreiz, eifrig Ergebnisse zu suchen, die zur Entlassung von Kollegen führen könnten
- Das erste QA-Team erwartet, dass das zweite Team schon etwas finden wird, und reduziert seinen Einsatz
- Auch das Widget-Team wird bei der Eigenprüfung nachlässig, weil es ja ein QA-Team gibt → 10 % Ausschuss wirken attraktiver als 20 % langsameres Arbeiten
- Eine vollständige technische Neugestaltung zur Qualitätssteigerung wird wegen zu hoher Kosten gemieden
- Das Toyota Production System schaffte QA-Stufen vollständig ab und gab allen Mitarbeitenden einen „Linie-anhalten“-Knopf
- US-Autohersteller installierten denselben Knopf, aber niemand drückte ihn → aus Angst vor Kündigung
Vertrauen (Trust)
- Der Unterschied zwischen dem Erfolg des japanischen Systems und dem Scheitern des amerikanischen Systems ist Vertrauen
- Vertrauen zwischen Einzelnen: die Gewissheit, dass der Vorgesetzte wirklich von allen Defekten erfahren will und dass man bei deren Entdeckung die Linie anhalten soll
- Vertrauen zwischen Managern: die Gewissheit, dass das Management Qualität ernst meint
- Vertrauen des Managements in Mitarbeitende: die Gewissheit, dass Menschen mit den richtigen Systemen und Anreizen hochwertige Arbeit leisten und eigene Fehler selbst erkennen
- Zusätzliche Bedingung: Vertrauen, dass das System tatsächlich funktioniert → dafür braucht man zuerst ein funktionierendes System
Fehlbarkeit (Fallibility)
- AI-Coder schreiben oft schlechten Code, und darin sind sie menschlichen Programmierern gleich
- Im Ansatz von Deming gibt es keine magische Lösung → Engineers müssen Qualität bottom-up in das gesamte System hinein entwerfen
- Bei jedem Problem sollte gefragt werden: „Wie konnte das passieren?“; mit Postmortems und den Five Whys wird die eigentliche Ursache gesucht und behoben
- „Der Coder hat einen Fehler gemacht“ ist keine Grundursache, sondern ein Symptom → gesucht werden muss der strukturelle Grund, der diesen Fehler möglich gemacht hat
- Die wahre Aufgabe eines Code-Reviewers ist nicht das Code-Review selbst, sondern die eigenen Review-Kommentare überflüssig zu machen
- Das System so verbessern, dass diese Art von Kommentar in Zukunft nicht mehr nötig ist
- Das Ziel sollte ein Zustand sein, in dem Reviews nicht mehr erforderlich sind
- Beispiel: die Entwickler von
go fmt → sie haben Review-Kommentare zu Whitespace dauerhaft eliminiert → das ist echtes Engineering
- Wenn ein Review einen Fehler entdeckt, ist der Fehler bereits passiert → die eigentliche Ursache liegt bereits in der Vergangenheit
Modularität (Modularity)
- Review-Pipelines (QA-Stufen) funktionieren nicht; sie verlangsamen alles und verdecken die eigentlichen Ursachen → dadurch wird deren Behebung noch schwieriger
- Der Reiz von AI-Coding: Die erste Stufe der Pipeline ist überwältigend schnell → es fühlt sich wie eine Superkraft an
- Möglicherweise gibt es jetzt genug Anreiz, die über 20 Jahre gewachsenen Probleme der Code-Review-Kultur anzugehen und sie durch eine echte Qualitätskultur zu ersetzen
- Die Optimisten haben zur Hälfte recht: Review-Stufen müssen reduziert werden, aber ohne Ersatz endet das bei einem Ford Pinto oder jüngsten Boeing-Flugzeugen
- Wie Deming es in die Fertigung brachte, braucht es einen vollständigen Paketwechsel (table flip) → ein System des „Total Quality“ lässt sich nicht halb einführen
- Reviews müssen abgeschafft und gleichzeitig überflüssig gemacht werden
- Es ist möglich, neue Systeme in kleinen Einheiten vollständig zu übernehmen:
- Vergleichbar mit alten US-Autoherstellern, die hochwertige Bauteile von japanischen Zulieferern einkaufen
- Sind die Teile gut gemacht, lassen sich QA-Stufen anderswo abschaffen → die Komplexität der „Montage von Teilen“ sinkt drastisch
- Aus kleinen, schönen Dingen lassen sich große, schöne Dinge zusammensetzen
- Kleine Teams, die einander vertrauen, bauen einzelne Komponenten und wissen, was Qualität für sie bedeutet
- Das Kundenteam formuliert klar, was Qualität für es bedeutet → Qualität breitet sich bottom-up aus
Kleine Teams und Organisationsdesign im AI-Zeitalter
- Kleine Startups könnten in der neuen Welt im Vorteil sein, weil es bei wenigen Menschen von Haus aus weniger Review-Stufen gibt
- Manche Startups finden einen Weg, schnell hochwertige Komponenten zu produzieren, andere scheitern → Qualität durch natürliche Selektion
- Große Unternehmen haben oft ein zähes, langsames Review-System; wird es entfernt, kann völliges Chaos entstehen
- Unabhängig von der Unternehmensgröße können Engineering-Teams kleiner werden und die Schnittstellen zwischen Teams klarer definieren
- Innerhalb eines Unternehmens ist auch ein Modell denkbar, in dem mehrere Teams dieselbe Komponente konkurrierend entwickeln
- Jedes Team besteht aus wenigen Menschen und Coding-Bots
- Es werden 100 Ansätze ausprobiert und der beste ausgewählt → Qualität durch Evolution
- Code ist billig, aber gute Ideen sind weiterhin teuer → neue Ideen lassen sich dennoch schneller als früher ausprobieren
- Auf dem Monolith-Microservices-Kontinuum könnte ein neuer optimaler Punkt entstehen
- Microservices haben einen schlechten Ruf bekommen, weil sie oft zu klein sind, aber im ursprünglichen Begriff war ein „Micro“-Service eine Größe, die ein „Two-Pizza-Team“ bauen und betreiben kann
- Im AI-Zeitalter ist das eher „eine Pizza und ein paar Tokens“
- Mit dem neuen schnellen Coding lassen sich die Modulgrenzen selbst schneller erproben
- Features bleiben schwierig, aber Refactoring und automatisierte Integrationstests sind Bereiche, in denen AI stark ist
- Man kann Module trennen, die man früher aus Angst nicht getrennt hätte → die Zahl der Codezeilen steigt zwar, ist aber billig im Vergleich zum Koordinations-Overhead, wenn große Teams beide Seiten pflegen
- Jedes Team hat einen Monolithen, der zu groß ist, und zu viele Review-Stufen
- Auch wenn die Singularität ausbleibt, können wir eine deutlich bessere Welt konstruieren → das Problem ist lösbar
- Der Kern ist Vertrauen
2 Kommentare
Ich, als ich
go fmtzum ersten Mal sah: Warum kann ich das Format denn nicht nach meinem Geschmack festlegen ..!Jetzt: Wozu braucht man beim Formatieren überhaupt Geschmack?
Hacker-News-Kommentare
Man könnte Reviews auch ganz weglassen
Wenn man Reviews nach links verlagert und daraus Code-Design-Sessions macht, Probleme im Daily anspricht und schwierige Teile mit Pair Programming löst, entfällt der Großteil des Zwecks von Reviews
Die verbleibenden 10 % wie Variablennamen, Leerzeichen oder Patterns lassen sich mit einem Linter automatisieren
Am Ende geht es darum, eine vertrauensbasierte Teamkultur aufzubauen, in der das Team den gemeinsam vereinbarten Code vertrauensvoll schreiben kann
Viele Probleme erkennt man erst bei der tatsächlichen Implementierung
Fast nie läuft alles exakt nach Plan. Am Ende braucht man wiederholte Architektur-Meetings, aber die versinken dann schnell im Sumpf wöchentlicher Besprechungen
Wenn sie nicht einmal den Code reviewen, den sie selbst erstellt haben, zerbricht das aufgebaute Vertrauen in kürzester Zeit
Wie beim Toyota Production System braucht man, um QA-Phasen abzuschaffen, das Vertrauen, dass jedes Teammitglied beim Entdecken eines Fehlers sofort stoppen kann
Review-Pipelines verbergen Probleme nur und verlangsamen alles
Dieser eine Satz klingt schon wie die Definition der Hölle
Das funktioniert erstaunlich gut. Die Leute schreiben von selbst Tests und prüfen zusätzlich manuell
Außerdem haben wir ein Sicherheitsnetz aufgebaut, mit dem sich fehlerhafte Deployments in 10 Minuten zurückrollen lassen
Code-Reviews sind ein Dilemma der Freiwilligenarbeit
Denn in Bewertungen zählt eher „viele Features ausgeliefert“ als „viele PRs reviewt“
Am Ende reviewt man engagiert meist nur dann, wenn es die eigene Arbeit direkt betrifft
Weil Code aber flexibel ist, können schnelles Mergen und nachträgliche Korrekturen sogar zu schnellerer Konvergenz führen
Gerade der Wunsch, Bugs früh zu finden und dadurch On-Call-Stress zu reduzieren, ist ein starker Anreiz
Selbst wenn man es nicht versteht, helfen hinterlassene Fragen enorm beim Lernen
Wer Führung übernehmen will, sollte viele Code- und Design-Dokument-Reviews machen
Dieser Artikel hat meine Intuition und Erfahrung klar auf den Punkt gebracht
Ich mochte das Produkt von Tailscale schon, aber jetzt werde ich wohl auch Fan des CEO
Danke an Avery für den Artikel, ich werde ihn breit weiterverbreiten
Valve ist eines der wenigen Unternehmen, das die Grenzen der Kommunikationsbandbreite versteht
Je größer eine Organisation wird, desto exponentiell größer wird die Kommunikationslast
Andere Unternehmen müssten das inzwischen eigentlich auch verstanden haben, aber oft ist das noch nicht so
Es überrascht mich, dass Reviews innerhalb von 5 Stunden erledigt werden
Meistens dauert es mehrere Tage
Aber wenn es eine Kultur gibt, in der jeder beim Entdecken eines Bugs sofort stoppen kann, sind Reviews womöglich gar nicht nötig
In der Realität sind individuelle Nachteile oft an das Verfehlen von Release-Zielen geknüpft
In meiner jetzigen Firma sind Reviews in Minuten erledigt, doch die technischen Schulden explodieren
Nach Ablauf einer bestimmten Zeit kam automatisch eine Nachricht mit „Wartet auf Review“
Alles wurde gemessen, und der Leistungsdruck war enorm
Solange die Teamgröße überschaubar bleibt, ist diese Gewohnheit erlernbar und übertragbar
Weder das Business noch die Entwickler interessieren sich besonders dafür
Das Verhältnis von Wert zu Aufwand bei Reviews wird oft ignoriert
Wenn Reviews die Qualität real nicht verbessern, ist die dafür aufgewendete Zeit verschwendet
Statt über Kleinigkeiten zu streiten, ist es effizienter, nur zu prüfen, ob es funktioniert, und dann schnell zu mergen
Verbesserungen kann man später in weiteren Commits nachreichen
Reviews sollten kurze Checkpoints sein, die nur die Richtung bestätigen
Ich stimme der Aussage „Die Aufgabe des Reviewers ist es, Reviews abzuschaffen“ voll zu
Der Artikel setzt einen serialisierten Prozess voraus, in der Realität läuft vieles aber parallel
Wenn mehrere Bugs gleichzeitig bearbeitet werden, sind Review-Verzögerungen kein großes Problem
Entscheidend ist, die Anzahl gleichzeitiger Arbeiten (N) zu steuern
Link
Je langsamer PR-Reviews sind, desto größer werden die Kosten des Kontextwechsels
Laut den Berechnungen steigt die Produktivität deutlich, wenn Reviews schneller werden
Ich kann der Aussage „Das Ziel des Reviewers ist es, Reviews überflüssig zu machen“ etwas abgewinnen,
aber wenn sich der Vertrauensbereich über das Unternehmen hinaus erweitert, sieht die Sache anders aus
Wenn zum Beispiel über
npm updateSchadcode ausgeliefert wird, ist eine Reaktion im Nachhinein zu spätAuch in einem vertrauensbasierten System gibt es manchmal Punkte, an denen menschliche Prüfung nötig ist
Manager betonen Produktivität und halten gleichzeitig Prozesse aufrecht, die das Tempo bremsen
Das ist ein komplexes Problem, über das man nicht einfach in gut oder schlecht urteilen kann
Betreiber müssen zugleich Produktivität und Sicherheit verantworten
Vor einem Unfall wird Produktivität betont, danach Sicherheit
Außenstehende verstehen dieses Gleichgewicht der Doppelrolle oft nicht gut
Passender Link