Wenn Sie im vergangenen Jahr Entwicklern zugesehen haben, die mit Claude Code oder Cursor arbeiten, haben Sie etwas wirklich Neues gesehen: nicht KI als Autovervollständigung, sondern KI als Mitarbeiter, der in engen, iterativen Schleifen arbeitet. Das Werkzeug nimmt ein Problem, sammelt Kontext, führt Änderungen an der Codebasis aus, prüft seine Arbeit und iteriert, bis etwas kompiliert und die Tests besteht.
Die Frage liegt nahe: Funktioniert diese Architektur auch im Projektmanagement? Das endlose Konsolidieren von Statusmeldungen, die Stakeholder-Kommunikation und das ständige Nachziehen der Dokumentation wirken wie ein offensichtlicher Kandidat. Wenn eine agentische Schleife Code schreiben und debuggen kann, dann kann sie doch wohl auch einen Statusbericht entwerfen oder auf einen wackelnden Termin hinweisen. Die Antwort ist ja, aber mit einer entscheidenden Einschränkung. Projektmanagement zerfällt sauber in zwei Arten von Arbeit: mechanische Schleifen, die KI in Maschinengeschwindigkeit abarbeiten kann, und urteilslastige äußere Schleifen, die menschliche Präsenz, Beziehungen und politisches Gespür verlangen. Die Architektur funktioniert nur, wenn wir diese Grenze akzeptieren.
Parallelen
Die Struktur lässt sich sauber übertragen. Coding-Schleifen nehmen einen Input (ein Problem), sammeln Kontext (Codebasis, Abhängigkeiten, Tests), nutzen Werkzeuge (Dateioperationen, Terminal, git) und iterieren, bis der Code funktioniert. Projektmanagement hat dasselbe Gerüst: Ziele als Input, Projektstatus als Kontext, E-Mail, Jira und Slack als Werkzeuge und den vertrauten Rhythmus aus Planen, Ausführen, Überwachen und Anpassen. Die Parallele ist echt, aber sie ist unvollständig, und zwar an den Stellen, auf die es ankommt.
Grenzen
Code tut, was Sie ihm sagen. Tests bestehen oder scheitern, objektiv und endgültig. Menschen haben einen eigenen Willen, politische Interessen und Emotionen. Das Gegenstück zum „bestandenen Test“ im Projektmanagement, die Freigabe durch Stakeholder, ist subjektiv und widerrufbar. Ein Sponsor, der am Dienstag zugestimmt hat, kann es sich nach einem Gespräch am Gang am Donnerstag anders überlegen. Claude Code kann die Datei tatsächlich schreiben und den Test ausführen. Ein KI-Assistent fürs Projektmanagement kann die Eskalations-E-Mail entwerfen, aber er kann den Stakeholder nicht dazu bringen, zu antworten, und wer im falschen Moment an die falsche Person eskaliert, kann alles schlimmer machen, selbst wenn die Risikobewertung fachlich stimmt.
Die Ausführung endet an der menschlichen Schnittstelle.
Dazu kommt ein brutales Missverhältnis bei der Latenz. Coding-Schleifen iterieren in Sekunden bis Minuten. PM-Schleifen laufen über Tage und Wochen. In Maschinengeschwindigkeit können Sie nicht iterieren, wenn Ihre „Werkzeuge“ Menschen sind, die drei Tage brauchen, um auf eine E-Mail zu antworten.
Die Persistenz des Zustands ist das nächste Problem. Code hat git: explizit, versioniert, wiederherstellbar. Der Zustand eines Projekts verteilt sich auf E-Mail-Threads, Gespräche am Gang und eine Beziehungsgeschichte, die nie jemand dokumentiert. Das Kontextfenster-Problem ist im PM um Größenordnungen schwieriger.
Und die Erfolgskriterien unterscheiden sich grundlegend. Im Code bestehen die Tests und die Builds laufen. Im PM ist Erfolg mehrdimensional, politisch und wird oft im Nachhinein neu definiert. Das Feedback-Signal ist verrauscht, verzögert und durch eine Organisationsdynamik gefiltert, die die KI nicht sehen kann.
Die verschachtelte Schleife
Nehmen wir ein konkretes Beispiel: den wöchentlichen Statusbericht.
Heute verbringt ein Projektmanager Stunden damit, Jira nach dem Stand der Aufgaben abzufragen, Slack nach beiläufig erwähnten Blockern zu durchsuchen, E-Mails auf Bedenken von Stakeholdern zu prüfen, Terminkonflikte aufzulösen und das alles zu einer stimmigen Erzählung zusammenzuführen. Das ist eine innere Schleife (mechanische Ausführung): repetitiv und gut automatisierbar.
Aber zu entscheiden, was in diesem Bericht betont wird? Zu wissen, dass sich der CFO für die Burn Rate interessiert, der Produkt-Sponsor dagegen für die Vollständigkeit der Features? Zu verstehen, dass die Erwähnung der Infrastrukturverzögerung eine politische Kettenreaktion auslöst? Das ist die äußere Schleife (menschliches Urteil): langsam, kontextabhängig und nur von Menschen zu leisten.
Die Architektur, die funktioniert, besteht aus verschachtelten Schleifen. Die äußere Schleife läuft im Tempo der Menschen und gehört ihnen: der Projektlebenszyklus aus Initiieren, Planen, Ausführen, Überwachen und Abschließen. An jedem Übergang steht ein Entscheidungspunkt. Beziehungen, Politik, Gespür für die Lage. Das lässt sich nicht automatisieren.
Darin liegen mehrere innere Schleifen, die in Maschinengeschwindigkeit laufen können:
- Statuskonsolidierung: Quellen abfragen → zusammenführen → formatieren → ausliefern
- Entwürfe für die Kommunikation: Input analysieren → entwerfen → verfeinern → zur Prüfung einreihen
- Risikoüberwachung: Daten scannen → Muster erkennen → alarmieren → dokumentieren
- Modellierung von Änderungsfolgen: Anfrage analysieren → Auswirkung auf Zeitplan/Budget modellieren → Optionen vorlegen
Die KI betreibt die inneren Schleifen und liefert Erkenntnisse nach oben an den Menschen. Der Mensch fällt die Urteile und schickt Entscheidungen nach unten zur Ausführung. Das entspricht der tatsächlichen Arbeit mit Claude Code: Niemand lässt es ganze Anwendungen autonom schreiben. Entwickler erledigen damit abgegrenzte Aufgaben in engen Schleifen. Eine PM-Engine würde es genauso machen.
Wie das konkret aussieht
In der Praxis ist das eine aufgebohrte Kombination aus Notion, Linear und einem E-Mail-Agenten:
Die Deliverable-Schleife: Ein Termin rückt näher. Das System fragt den Status im Tracker ab, durchsucht zugehörige E-Mail-Threads und prüft den Kalender auf Blocker. Es liefert eine Risikobewertung mit Optionen. Der Mensch prüft und entscheidet: eskalieren, Plan anpassen oder übersteuern. Das System verschickt die Nachrichten und aktualisiert die Tracker. Danach beobachtet es, ob Antworten eintreffen.
Die Change-Request-Schleife: Eine E-Mail eines Stakeholders mit einer Scope-Änderung trifft ein. Das System analysiert die Auswirkung auf Zeitplan und Budget und fragt ähnliche frühere Änderungen sowie die aktuelle Ressourcenauslastung ab. Es liefert eine Bewertung mit Optionen: annehmen, ablehnen, verhandeln. Der Mensch entscheidet. Das System dokumentiert und kommuniziert.
Diese inneren Schleifen haben klare Abbruchbedingungen. Der Bericht ist erstellt. Die E-Mail ist entworfen. Das Risiko ist gemeldet. Der Erfolg ist auf Ebene der Schleife messbar, auch wenn der Erfolg auf Projektebene unklar bleibt.
Die Zielkonflikte sind aber real. Latenz gegen Aktualität: Wie oft soll das System die Quellen neu abfragen? Überautomatisierung gegen Vertrauensverlust: Wenn Menschen Entwürfe nicht mehr sorgfältig lesen, rutschen Fehler durch. Kontexttiefe gegen Datenschutz: Die Stimmung in E-Mails und Antwortmuster auszuwerten liefert einem PM starke Erkenntnisse und ist, wenn die Governance schwach ist, gefährlich nah an Leistungsüberwachung.
Wo das scheitert
Das Problem mit dem Feedback-Signal verfolgt den ganzen Ansatz. Beim Coding bestehen Tests oder sie scheitern. Woher soll das System im PM wissen, ob der Statusbericht etwas bewirkt hat? Ob die Botschaft an die Stakeholder angekommen ist? Feedback kommt verzögert, verrauscht und oft nur implizit. Sie können innere Schleifen nach ihren eigenen Maßstäben optimieren (Bericht erstellt, E-Mail verschickt), aber ob sie dem Projekt genützt haben, lässt sich nicht so leicht messen.
Das Durchwink-Problem ist heimtückisch. KI entwirft, der Mensch gibt frei. Aber die Freigabe wird zum Automatismus, wenn Menschen zu sehr vertrauen. Fehler der KI kommen in perfekter Selbstsicherheit verpackt daher. Die Architektur muss eine echte Prüfung erzwingen und darf nicht bloß Checkpoints schaffen, die zu reflexhaften Klicks werden.
Was passiert, wenn die KI auf sichtbare Kennzahlen optimiert? Die Sprint Velocity sieht großartig aus, während sich unsichtbar technische Schulden anhäufen. Statusberichte halten jeden Termin ein, während das Team ausbrennt. Innere Schleifen lassen sich austricksen, oder sie tricksen sich unbeabsichtigt selbst aus, indem sie messbare Ersatzgrößen anstreben statt echte Ergebnisse.
Und es gibt Kontext, den die KI nie haben wird. Das Gespräch am Gang, in dem der Sponsor seine wahre Sorge erwähnt hat. Die Beziehungsgeschichte, die erklärt, warum „dringend“ bei diesem Kunden etwas anderes bedeutet. Die politische Dynamik im Lenkungsausschuss. Innere Schleifen arbeiten mit dokumentierten, abfragbaren Informationen. Das Urteil der äußeren Schleife braucht Kontext, der in keinem System landet.
Was heute schon funktioniert
Die Architektur ist keine Theorie. Die Bausteine gibt es heute: MCP-Konnektoren verbinden KI mit Gmail, Calendar, Slack, Jira und Drive. Claude und GPT übernehmen Synthese und Entwürfe. Die Herausforderung ist die Integration: diese Komponenten zu Schleifen zu verdrahten, die tatsächlich dazu passen, wie Projektteams arbeiten. Die Organisationen, die heute einen Nutzen daraus ziehen, warten nicht auf ein fertiges „KI-PM“-Produkt. Sie bauen gezielt innere Schleifen: einen Statuskonsolidierungs-Agenten, der drei Systeme abfragt und einen Wochenbericht entwirft. Einen Change-Request-Analysator, der die Auswirkung auf den Zeitplan modelliert, bevor der PM die E-Mail überhaupt öffnet. Einen Risikomonitor, der in Sprint-Daten Muster meldet, die Menschen übersehen würden.
Jede Schleife ist eng zugeschnitten, testbar und mit einem menschlichen Checkpoint verbunden. Die Disziplin besteht darin zu wissen, wo man aufhört: die mechanische Arbeit automatisieren, ohne so zu tun, als verstünde die KI, warum die Bedenken des CFO in diesem Quartal mehr zählen als im letzten.
Das Muster entspricht dem, was sich in der Entwicklung bewährt hat. Claude Code war nicht erfolgreich, weil es versprach, Programmierer zu ersetzen. Es war erfolgreich, weil es die lästigen Teile übernahm (Boilerplate, Refactoring, Testgenerierung), damit sich Entwickler auf Architektur und Designentscheidungen konzentrieren konnten. Dasselbe gilt fürs Projektmanagement: die Synthese der Informationen automatisieren, das menschliche Urteil bewahren.
Solche Systeme zu bauen verlangt, sowohl die Fähigkeiten der KI als auch die PM-Abläufe zu verstehen, die sie unterstützen sollen. An der Lücke zwischen „technisch möglich“ und „tatsächlich nützlich“ scheitern die meisten Umsetzungen. Richtig wird es, wenn man bei einem konkreten Schmerzpunkt anfängt, eine minimale Schleife baut und erst erweitert, wenn die erste ihren Wert bewiesen hat.
Falls eine KI jemals behauptet, Ihr Projekt von Anfang bis Ende zu managen, lügt sie, oder Ihr Projekt war nie besonders komplex. Die interessante Arbeit liegt dazwischen: innere Schleifen, die schnell genug sind, um etwas zu bewirken, äußere Schleifen, die menschlich genug sind, um zu gelingen.
Aus dem Englischen übersetzt: zum Originalbeitrag