Zum Inhalt springen

root / tags / pair-programming

#pair programming

3 Fiches

KI-Coding-Agenten & Skills Automatisch geprüfte Übersetzung

Maybe We Shouldn't Be Reviewing All This Code

Beitrag von **Rachel Laycock**, CTO von **Thoughtworks**, veröffentlicht am **2. September 2026** in *Rachel's Ramblings*, der von ihr geleiteten martinfowler.com-Rubrik, mit rund **8.000 Zeichen**. Der Text ist eine **bewusste Antwort** auf [[houck-dx-what-are-code-reviews-for-2026-08-05]], nach einer öffentlichen Kontroverse zwischen den beiden Autoren auf einem **Code Remix**-Panel, veranstaltet von **Moderne**. Laycock akzeptiert Houcks quantifizierte Diagnose (+**106%** Zeilen pro Diff bei **Meta**, +**64%** mediane PR-Größe auf der DX-Seite) sowie die Liste der nicht-fehlererkennenden Funktionen des Reviews, verschiebt dann aber die Frage: *« warum warten wir bis zum Code-Review, um all das zu tun? »* (A) Das Leitprinzip ist die bei Thoughtworks erlernte Verkürzung von Feedback-Schleifen — wenn Feedback einen Wert hat, entferne es nicht, sondern rücke es näher an die Entscheidung heran, die es informiert. Jede dem Review zugeschriebene Funktion wird vorverlagert: das Erkunden von Alternativen vor der Implementierung, Wissenstransfer durch **pair programming**, kollektive Verantwortung durch **mob programming** und Team-Design-Sessions, architektonische Abstimmung durch gemeinsames Design, gefolgt von **fitness functions**, und Automatisierung von allem Deterministischen — *« Wir sollten 2026 wirklich nicht mehr über Whitespace streiten. »* (B) Ausnahmebasiertes Review ersetzt systematisches Review: eine fundamentale architektonische Änderung, eine sensible Sicherheitsgrenze, ein großer Blast Radius, ein unbekannter Bereich eines kritischen Systems, oder schlicht das erklärte mangelnde Vertrauen eines Teams. (1) Die Automatisierung des Reviews durch einen Agenten, der den menschlichen Reviewer nachbildet, wird verworfen als *« Automatisierung der Zeremonie, statt zu hinterfragen, warum die Zeremonie existiert »*. (2) Houcks kognitive Schuld wird als real anerkannt, doch der verpflichtende PR wird als schwache Verteidigung eingestuft: *« Wir brauchen Engineers, die Systeme verstehen, nicht Diffs. »*

#Code Review#ausnahmebasiertes Review#Pull Request

Rachel Laycock · CTO de Thoughtworks · sur *Rachel's Ramblings* (martinfowler.com).

Transformation & Adoption Automatisch geprüfte Übersetzung

Steps of AI Adoption (tableau/artifact + post LinkedIn « I talk to engineers at other companies every day… »)

**Boris Cherny** (Creator & Head of Claude Code @Anthropic) veröffentlicht auf LinkedIn eine Framework-Tabelle, **« Steps of AI Adoption »**, die die Einführung agentischer KI durch ein Engineering-Team über **5 Stufen (0→4)** abbildet, jede charakterisiert durch eine **Größenordnung der gesteuerten Agenten** und eine **Transformation der Rolle des Engineers**: **0 Gated** (0 Agenten, abgeschotteter Zugang), **1 Assisted** (~1 Agent — „du + ein Agent“, betreutes Pair Programming), **2 Parallel** (~10 Agenten — **Orchestrator**), **3 Supervised autonomy** (~100 Agenten — **Manager of Managers**, ein Org-Baum), **4 AI-native** (~1.000+ Agenten — **VP Steering by Intent**). Die Tabelle kreuzt fünf Spalten: Anzahl der Agenten, *wie es aussieht*, *der Engpass*, *die hilfreichen Produkte*, *die Guardrails*. **Zentrale These**: mehr Tokens zu verbrauchen bringt keinen Stufenaufstieg — der Aufstieg zur nächsten Stufe erfordert, **den nächsten Engpass zu identifizieren und aufzulösen** UND **den nächsten Satz an Guardrails aufzubauen**. Konkret: Claude eine verlässliche **Self-Verification-Loop** geben (Tests + Build + Lint + E2E in einer echten Umgebung), **Auto mode** aktivieren (um blockierende Berechtigungsabfragen zu vermeiden), **Code-Review und Security-Review zum Standard machen**, Multi-Agenten-Oberflächen einführen (Agent View CLI, Desktop, iOS/Android-Apps, Tag), dann `/loop`, `/batch`, `/goal`, **dynamische Workflows** und **worktree isolation** für Subagenten. Zum Thema Steuerung: Nutzung (Dashboard) misst **Aktivität, nicht Ertrag**; die richtige Frage lautet *„hätten wir hierfür ohnehin Engineering-Aufwand investiert? Wenn ja, wie viele manuelle Engineer-Stunden hätte es gekostet?“* — das ist der ROI. Der eigentliche Gewinn stellt sich ein, wenn **Fixes und Wartung im Hintergrund ablaufen** und Teams sich auf das *Bauen* konzentrieren. Anthropic befindet sich auf **Stufe 3, auf dem Weg zu 4**; Boris Cherny erklärt, persönlich **Stufe 4** erreicht zu haben.

#Boris Cherny#Claude Code#Anthropic

Boris Cherny (Creator & Head of Claude Code @Anthropic)

Transformation & Adoption Automatisch geprüfte Übersetzung

Fragments: February 13

Thoughtworks-Retreat zur Zukunft der Softwareentwicklung mit LLMs — Überlegungen zu organisatorischen Auswirkungen, kognitiver Schuld und beaufsichtigter Programmierung

#LLM#Softwareentwicklung#KI-Agenten

Martin Fowler