On the Loop - KI zu führen ist ein Empowerment-Problem

Kief Morris hat Anfang März auf Martin Fowlers Seite ein Stück veröffentlicht mit dem Titel Humans and Agents in Software Engineering Loops. Es ist das beste kurze Framework, das ich dazu gelesen habe, wo der Mensch stehen sollte, wenn Agenten die Arbeit machen. Wenn du jemals versucht hast, einem skeptischen CTO zu erklären, warum “Ich reviewe immer noch jede Zeile” in achtzehn Monaten keine haltbare Position mehr ist, dann ist das der Text, den du ihm in die Hand drücken solltest.

Was mir beim zweiten Lesen auffiel, ist nicht, dass das Framework neu wäre. Sondern dass es fast identisch mit dem ist, was Marty Cagan und Reed Hastings Produkt-Leadern seit zwanzig Jahren predigen. Die richtige Art, einen KI-Agenten zu führen, entpuppt sich als die richtige Art, einen Senior Engineer zu führen. Die hart erkämpften Lektionen von Empowered Product Teams, Netflix’ context not control und Daniel Pinks Drive lassen sich alle direkt übertragen. Wenn du sie hast, ist KI-Führung ein Medienwechsel, keine neue Disziplin. Wenn du sie nicht hast, wird die KI-Ära das schneller aufdecken als jede Reorganisation.

Das ist der Text, mit dem mein Vibe-Coding-in-Prod-Artikel von Anfang dieser Woche hätte gepaart werden sollen. Eric Schluntz hat uns den Engineering-Individual-Contributor-Frame gegeben: sei Claudes PM. Morris gibt uns den Team- und Org-Frame: sei on the loop, nicht in it. Zusammen beschreiben sie einen einzigen Shift - vom Macher zum Empowerer - der auf jeder Ebene der Organisation gilt.

Morris’ fünf Positionen

Morris’ Kernzug ist, die Binärität abzulehnen. Die Debatte wird in den meisten Teams als “lassen wir Agenten Code shippen, oder reviewen wir jeden Diff?” geframt. Dieser Frame ist eine Falle. Er legt fünf verschiedene Positionen menschlicher Involvierung aus, von denen heute nur eine tatsächlich produktiv ist:

Position	Was der Mensch tut	Wie es sich anfühlt
Outside the loop	Setzt die Produktrichtung, lässt Agenten alles Nachgelagerte machen	Pures Vibe Coding; funktioniert nur für Wegwerfarbeit oder eingegrenzte Arbeit
In the loop	Inspiziert jedes Artefakt, das der Agent produziert	Micromanagement; Menschen werden zum Bottleneck
On the loop	Baut und pflegt das Harness - Specs, Quality Checks, Workflow-Regeln	Die produktive Zone heute
Agents manage the harness	Menschen dirigieren Agenten, die das Harness selbst verbessern	Aufstrebende Frontier
The agentic flywheel	Agenten analysieren Loop-Performance gegen reichere Signale (Metriken, User Journeys, kommerzielle Outcomes) und schlagen Verbesserungen vor, einige automatisch genehmigt	Selbstverbesserndes System, weiterhin engineered

Die zwei Positionen, in die jeder per Default fällt - in the loop und outside the loop - sind die zwei, die nicht funktionieren. In the loop stellt den ursprünglichen Bottleneck wieder her: Der Agent kann in einer Stunde eine Woche Code produzieren, und der Mensch, der so tut, als würde er das reviewen, lügt entweder oder hält alles auf. Outside the loop ist der YOLO-Failure-Modus: Du verlierst interne Qualität, und die stellt sich genau deshalb als wichtig heraus, weil sie sich zu externen Outcomes aufsummiert. Morris’ Zeile ist scharf: “clean codebases help agents work faster; spiralling on messy code wastes time and resources.”

Die produktive Zone ist on the loop. Hör auf, einzelne Artefakte zu fixen. Fang an, das System zu verbessern, das sie produziert. Das ist reines Shift-Left-Denken, angewandt auf Agenten: Statt jeden PR zu inspizieren, investierst du in Spezifikationen, Evaluationskriterien, architektonische Regeln und Review Gates, die Probleme an der Quelle abfangen. Das Harness wird zum Hebelpunkt.

Warum sich das genau wie EMPOWERED liest

Hier ist der Teil, bei dem ich aufhorchen musste. Ersetze Team für Agent und Manager für Mensch, und Morris’ Framework wird zu einer direkten Neuformulierung von Marty Cagans EMPOWERED.

Cagan sagt seit zwei Jahrzehnten, dass der Unterschied zwischen einem Feature Team und einem Empowered Team darin liegt, wo der Manager steht. Ein Feature-Team-Manager sitzt in the loop: reviewt jede Entscheidung, genehmigt jede Lösung, agiert als Bottleneck und, schlimmer noch, als Single Point of Creative Failure. Ein Empowered-Team-Manager steht on the loop: setzt den strategischen Kontext durch Vision, Strategie, Team-Objectives und architektonische Leitplanken, und geht dann aus dem Weg, während das Team herausfindet, wie das Problem zu lösen ist. Seine Formulierung dafür, die ich in jedem Leadership-Gespräch seit Jahren wiederhole, ist dieselbe, die Reed Hastings bei Netflix nutzt: lead with context, not control.

Die tiefe Parallele zu Morris’ Framework ist die folgende:

In the loop = Feature-Team-Management. Du bist der Bottleneck, du bist der Single Point of Failure, und du produzierst mittelmäßige Outcomes, weil du die am schlechtesten informierte Person im Raum über die tatsächliche Arbeit bist.
On the loop = Empowered-Team-Management. Du baust die Bedingungen, unter denen qualitativ hochwertige Arbeit passiert, ohne dass du im kritischen Pfad stehst. Du reviewst Outcomes, keine Artefakte. Du coachst und setzt den Kontext, du steuerst nicht.
The flywheel = eine reife Empowered-Organisation. Das Team führt nicht nur das Harness aus; es verbessert es. Sie bringen Daten zurück, schlagen Änderungen vor, und das System wird besser ohne die ständige Intervention des Managers. In menschlichen Begriffen ist das, was Hastings high talent density with candor and context nennt. In agentischen Begriffen ist es Morris’ Flywheel.

Die Mechanik ist identisch. Der schwierige Teil - für Manager, die Menschen führen, und für Engineers, die Agenten führen - ist derselbe, auf den Cagan immer wieder einhämmert. Du musst den Dopamin-Kick aufgeben, die klügste Person im Raum zu sein. Du musst dem System vertrauen, das du gebaut hast. Dieses Vertrauen skaliert. Deine persönlichen Review-Zyklen nicht.

No Rules Rules ist das Bedienungshandbuch

Reed Hastings’ No Rules Rules ist das Buch, das ich zufällig vor zwei Wochen gelesen und hier besprochen habe. Die Linie zwischen dieser Rezension und diesem Artikel ist peinlich kurz.

Hastings’ drei Hebel - Talent Density, Candor und Controls entfernen - sind genau die drei Hebel, die Morris’ On-the-Loop-Position funktionieren lassen. Mapping:

Talent Density → fähige Agenten. Netflix feuert adäquate Performer, weil ein adäquater Teammitstreiter das ganze Team nach unten zieht. Das KI-Pendant ist, dass fähige Modelle jede andere Leadership-Entscheidung einfacher machen. Einem Team auf Claude Sonnet 4.6 oder Opus 4.7 kann man größere Brocken der How-Schleife anvertrauen als einem Team auf letztjährigen Modellen. Niedrige Talent Density bei Menschen erzwingt Kontrolle; niedrige Capability bei Agenten erzwingt Micromanagement. Beides ist lösbar, und beides ist Voraussetzung, nicht Nice-to-have.
Candor → Evaluationssignale. Netflix’ Regel ist, dass es illoyal ist, Widerspruch zurückzuhalten. Das agentische Äquivalent ist, dass das Harness ehrliches, schnelles Signal haben muss: Unit Tests, Integration Tests, Evals, Produktionsmetriken, kommerzielle Outcomes. Wenn dein Evaluationssystem dem Agenten schmeichelt, bekommst du dasselbe Resultat wie in einem Team, in dem niemand sagt, was er wirklich denkt. Selbstbewusst aussehende Mittelmäßigkeit, die niemand hinterfragt.
Controls entfernen → die Inspektionsfläche verkleinern. Netflix hat Urlaubstracking, Spesengenehmigungen und Entscheidungsfreigaben abgeschafft, weil die Controls mehr kosteten, als sie einsparten. On the loop für Agenten sagt dasselbe: Hör auf, jeden Diff zu inspizieren, hör auf, jeden PR an einem menschlichen Durchlesen zu gaten. Ersetze Gates durch Guardrails. Ersetze Review durch Design.

Und dann das Prinzip, das alles verbindet: lead with context, not control. Hastings sagt es über Netflix. Cagan sagt es über Produktteams. Morris sagt es über Agenten, auch wenn er diese Formulierung nicht nutzt. Es ist dieselbe Regel.

Drive: Autonomie, Mastery, Purpose - angewandt auf Agenten

Daniel Pinks Drive ist der Pop-Psych-Klassiker in dieser Ecke des Leadership-Denkens. Seine drei intrinsischen Motivatoren - Autonomie, Mastery, Purpose - sind der Grund, warum Context-not-control bei Menschen funktioniert. Agenten haben keine Motivation in einem sinnvollen Sinn, aber das Framework beschreibt trotzdem, was ein gut designtes Harness ihnen gibt:

Autonomie mappt auf Scope und Latitude. Eine gut gescopete Aufgabe mit klaren Grenzen und expliziten Out-of-Scope-Linien lässt den Agenten echte Entscheidungen innerhalb eines definierten Raums treffen. Überspezifizierte Prompts sind die agentische Version davon, einen Senior Engineer durch Micromanagement in die Mittelmäßigkeit zu treiben.
Mastery mappt auf Progressive Disclosure und Skills. Agenten werden bei einer Aufgabe besser, wenn sie Zugang zum richtigen prozeduralen Wissen zum richtigen Zeitpunkt haben. Das ist, was das Skills Framework kodiert. Mastery für Menschen ist Karrierewachstum; Mastery für Agenten ist der richtige Skill, der zum richtigen Moment in den Kontext geladen wird.
Purpose mappt auf klare Outcomes und die Why-Schleife. Morris’ Zwei-Schleifen-Modell trennt die Why-Schleife (das Outcome, das du willst) explizit von der How-Schleife (die Artefakte, die es liefern). Purpose lebt in der Why-Schleife. Ein Agent, der weiß, dass er hier ist, um die Payment-Failure-Rate um 10% zu senken, verhält sich anders und macht bessere Trade-offs als ein Agent, dem gesagt wird “implementiere den Retry-Handler.”

Die menschliche Parallele ist wichtig, weil sie voraussagt, wo KI-Teams scheitern werden. Auf dieselbe Weise, wie menschliche Teams scheitern, wenn ihnen eine Aufgabe aber kein Purpose gegeben wird, scheitern Agenten, wenn ihnen ein Prompt aber kein Outcome gegeben wird. Auf dieselbe Weise, wie menschliche Teams unter einem Manager scheitern, der jeden Commit inspiziert, scheitern Agenten unter einem Operator, der nicht aufhören kann, jeden Diff zu lesen. Die Failure-Modi sind isomorph, und so auch die Lösungen.

Was das Harness tatsächlich ist

Morris nutzt Harness als abstrakten Begriff. Konkret ist das Harness eines empowered agentischen Teams ein Stack von Dingen, über die ich seit Monaten schreibe. Jede Schicht ist einer der Orte, in die der Mensch investiert, statt Code zu reviewen:

Harness-Schicht	Konkrete Artefakte	Hier beschrieben
Produkt-Purpose	Vision, Strategie, Zieloutcomes, OKRs, Problem Statements	Insights-driven product strategy, Set expectations right
Architektonischer Kontext	CLAUDE.md, Projekt-Docs, Conventions, Non-Negotiables	The perfect CLAUDE.md
Prozedurale Disziplin	Skills, Slash Commands, Phase Gates, Anti-Rationalisierung	The skills framework
Spezifikationen	Specs, Task-Breakdowns, Plan-Artefakte	PLAID in practice
Verifikation	Tests, Evals, Stresstests, Metrik-Dashboards, User Journeys	Implizit über den Stack hinweg
Workflow-Infra	Worktrees, Agent-Loops, Headless Runs, CI Gates	Agentic development patterns, The overnight agent factory

Beachte, dass genau keines dieser Dinge “lies den Diff des Agenten” ist. Das ist der Punkt. Das menschlich knappe Asset ist die Qualität des Harness, nicht die Quantität des Reviews. Jede Stunde, die in eine bessere CLAUDE.md, eine schärfere Spec, eine strengere Test-Suite oder eine ehrlichere Metrik investiert wird, zahlt sich über jeden Agent-Run danach hinweg aus. Jede Stunde, die mit dem Lesen eines Diffs verbracht wird, zahlt sich einmal aus, vielleicht.

Genau das ist die Botschaft “hör auf, Code anzufassen, fang an, das System zu bauen, das guten Code schreibt”, die Senior Engineering Leader seit dreißig Jahren zu verinnerlichen versuchen. Die KI-Ära macht die Kosten dafür, in the loop zu sein, einfach auf eine Weise sichtbar, wie sie es nie zuvor waren.

Das Flywheel sind OKRs für Agenten

Morris’ interessantester Zug kommt am Ende, wo er das agentische Flywheel beschreibt. Agenten analysieren die Performance der Schleife gegen immer reichere Signale - nicht nur Unit Tests, sondern Pipeline-Metriken, User Journeys, kommerzielle Outcomes - und schlagen Harness-Verbesserungen mit Risiko-, Kosten- und Nutzen-Scores vor. High-Confidence-Empfehlungen können automatisch genehmigt werden. Das System verbessert sich selbst und bleibt dabei engineered.

Entferne das KI-Vokabular, und das ist das Produkt-Operating-Modell, nach dem jedes Empowered Company zu operieren anstrebt. Du setzt Outcomes. Du instrumentierst das Produkt. Du reviewst die Daten. Du schlägst Änderungen vor, die nach erwartetem Impact bepunktet sind. Du shippst die High-Confidence-Änderungen, experimentierst mit den mittleren und diskutierst die riskanten in einem Raum mit den Leuten, die sie verantworten werden.

Was Morris beschreibt, sind OKRs für Agenten. Ein Schwungrad (Flywheel), bei dem sich das Harness aus Produktionssignal heraus entwickelt, so wie ein gutes Produktteam Strategie aus Insights entwickelt. Deshalb sollten die Führungskräfte, die sein Stück lesen, es nicht als KI-Infrastruktur-Stück auffassen. Sie sollten es als die Gelegenheit auffassen, endlich dieselbe Disziplin auf Code-Produktion anzuwenden, die wir seit zwei Jahrzehnten auf Produktentscheidungen anzuwenden versuchen.

Die Teams, die die nächsten zwei Jahre gewinnen werden, sind diejenigen, die auf der Produktseite bereits so operieren. Empowered Teams mit ehrlichen Metriken werden das agentische Flywheel nicht fremd finden. Sie werden es trivial finden, weil der Muskel bereits da ist.

Das CPTO-Mandat ändert sich, verschwindet nicht

Ich habe darüber gesessen, was das für meine eigene Rolle bedeutet, da ich kurz davor stehe, einem schnell wachsenden Londoner Startup als CPTO beizutreten. Die kurze Antwort ist, dass sich der Job in dieselbe Richtung ändert, in die jede gute CPTO-Rolle ohnehin hätte zeigen sollen. Weiter weg von den Artefakten, näher am System.

Konkret:

Deine Produktvision und -strategie zählen mehr, nicht weniger. Agenten mit schlechter Spec produzieren schlechten Code schneller, als Menschen es je konnten. Wenn du das Outcome nicht so artikulieren kannst, dass das Harness es an den Agenten übertragen kann, bist du kein Leader. Du bist ein Bottleneck.
Deine Engineering-Standards zählen mehr, nicht weniger. CLAUDE.md ist das neue Architekturdokument. Skills sind das neue Engineering-Handbuch. Evals sind das neue Code Review. Wenn diese schlampig sind, sind die Agenten schlampig. Wenn diese rigoros sind, sind die Agenten rigoros.
Die Talent Density deines Teams zählt mehr, nicht weniger. Nicht weil Agenten Engineers ersetzen, sondern weil das agentische Flywheel das Niveau an Geschmack und Rigorosität verstärkt, mit dem das Team startet. Hohe Talent Density mit Agenten ist ein Cheat Code. Niedrige Talent Density mit Agenten ist ein selbstbewusst klingendes Desaster mit dreifacher Geschwindigkeit.

Die CPTOs, die kämpfen werden, sind diejenigen, die versuchen, ihre bestehenden Micromanagement-Gewohnheiten in die KI-Ära zu migrieren. “Ich reviewe einfach jeden Agent-PR, so wie ich früher jeden Senior-Engineer-PR reviewt habe.” Das funktioniert einen Monat. Es fällt in dem Moment auseinander, in dem das Team über einen einzelnen Human-in-the-Loop hinausskaliert, was in einem agentischen Unternehmen nach etwa acht Wochen passiert.

Die CPTOs, die erblühen, sind diejenigen, die empowered schon vorher als Operating-Prinzip behandelt haben, nicht als Slogan. Für sie ist der Übergang mechanisch: Dasselbe Harness, das sie bereits für ihre Menschen gebaut haben, erstreckt sich jetzt auf die Agenten, die die Menschen orchestrieren.

Drei Moves, die ich morgen mache

Das Schreiben dieses Artikels hat drei Dinge in meiner eigenen Planung für das nächste Engagement geändert. Konkret, nicht abstrakt:

Investiere in das Harness, bevor das erste Feature kommt. Meine ersten zwei Wochen in der neuen Firma werden CLAUDE.md, Skills, Evals und architektonische Leitplanken sein, bevor irgendjemand ein Produktionsfeature mit Agenten schreibt. Das Harness zu bauen ist Day-Zero-Arbeit, so wie das Einstellen des ersten Senior Engineers früher Day-Zero-Arbeit war.
Behandle Evaluationen wie Metriken, nicht wie Tests. Bringe Eval-Daten in dieselben Dashboards wie Produktmetriken. Wenn das Team “Agent Success Rate bei Payment-Flow-Tasks” neben “Payment Failure Rate” sieht, werden sie natürlich in das erste investieren, weil es das zweite bewegt. Das ist das Flywheel.
Hör auf, Diffs zu lesen, wo ein Skill den Job erledigen würde. Jedes Mal, wenn ich mich dabei erwische, wie ich im Begriff bin, etwas zu reviewen, werde ich mich fragen: “Ist dieses Review als Regel, Test oder Skill reproduzierbar?” Wenn ja, kodiere ich es einmal und mache das Review nie wieder. Wenn nein, war es tatsächlich ein Judgment Call und verdient meine Aufmerksamkeit. Das Verhältnis des Ersten zum Zweiten ist zehn zu eins.

Das Fazit

Der Instinkt, dass KI-Führung eine neue Disziplin sei, ist falsch. Die Manager, die in der alten gut waren - Kontext setzen, Teams empowern, mit Outcomes führen, den eigenen Bottleneck aus dem kritischen Pfad entfernen - sind diejenigen, die in dieser neuen gut sein werden. Diejenigen, die sich hinter Artefakt-Review als ihrem Value-Add versteckt haben, werden bald herausfinden, dass sie nie den Wert beigetragen haben, den sie dachten.

Kief Morris’ Framework ist eine rigorose, engineering-spezifische Version des Empowerment-Playbooks, das Cagan, Hastings und Pink seit zwanzig Jahren schreiben. Dass es im März 2026 als “the agentic flywheel” ankommt statt als “empowered engineering teams” ist ein Branding-Zufall. Die Substanz ist dieselbe.

Lies Morris’ Stück. Lies dann EMPOWERED und No Rules Rules noch einmal mit Agenten im Kopf. Wenn du ein CPTO, VP Eng oder Gründer bist, der dieses Jahr Entscheidungen darüber trifft, wie dein Team KI nutzt, enthalten diese drei Quellen das meiste von dem, was du brauchst. Der Rest ist einfach Tun.

Referenzen

Humans and Agents in Software Engineering Loops - Kief Morris - Der Ausgangsartikel auf Martin Fowlers Seite
EMPOWERED - Marty Cagan (Buchnotizen) - Empowered Product Teams, Context-not-control, Coaching
No Rules Rules - Reed Hastings (Buchrezension) - Talent Density, Candor und das Bedienungshandbuch für High-Autonomy-Teams
Vibe Coding in Prod Is a Management Problem - Der Individual-Contributor-Frame, der mit diesem gepaart gehört
The Skills Framework - Die prozedurale Disziplin-Schicht innerhalb des Harness
The Perfect CLAUDE.md - Die architektonische Kontext-Schicht innerhalb des Harness
Agentic Development Patterns - Der tägliche Workflow, der obendrauf sitzt
The Overnight Agent Factory - Der Compounding-Mechanismus
Product Operating Model - Wie Empowered Teams aussehen, wenn das Operating-Modell stimmt