Das Lone-Wolf-Problem

Was mich an der Debatte über agentisches Arbeiten gerade irritiert: Überall sieht man Geschichten von Einzelnen. Eine Person, ein Agenten-Setup, ein Wochenende, und plötzlich steht da etwas, wofür früher ein kleines Team nötig gewesen wäre. Was ich fast nie sehe, sind gute Berichte darüber, wie Teams anfangen, wirklich agentisch zu arbeiten.

Ich glaube nicht, dass das nur Hype ist. Ich glaube auch nicht, dass das Zufall ist.

Ich merke den Sog ja selbst. Wenn ich agentisch arbeite, fühle ich mich oft weniger wie ein Entwickler und mehr wie ein PO. Ich schreibe Anforderungen, zerlege Aufgaben, formuliere Bugs, schärfe Akzeptanzkriterien und prüfe Ergebnisse. Das ist nicht ein bisschen effizienter. Das ist teilweise absurd effizient. Genau deshalb werde ich bei dem Thema vorsichtig.

In einer Diskussion neulich fiel ein Satz, der mir seitdem nicht mehr aus dem Kopf geht: Agentisches Arbeiten braucht ein verifizierbares Feedbacksignal. Also irgendetwas, das ziemlich schnell sagt: passt, passt nicht, nochmal. Je länger ich darüber nachdenke, desto mehr erklärt mir dieser Satz die aktuelle Lone-Wolf-Welle.

Warum das ausgerechnet in Software so gut klappt

Software ist voll von genau solchen Signalen. Compiler. Tests. Linter. Typen. CI. Laufende oder kaputte Builds. Das ist nicht dasselbe wie echtes Verständnis, klar. Grüne Tests beweisen noch lange nicht, dass das Richtige gebaut wurde. Aber sie reichen oft, um einen Agenten durch viele Schleifen zu treiben, ohne dass jedes Mal ein Mensch daneben sitzen muss.

Genau deshalb kann ein einzelner Mensch mit ein paar Agenten in der Softwareentwicklung heute so weit kommen. Das System antwortet schnell. Und maschinell.

Außerhalb der Software sieht das anders aus. Für Strategie gibt es keinen Compiler. Für Priorisierung keine Unit-Tests. Für gutes Product Thinking kein npm test. Dort ist Feedback später, teurer, weicher und oft politisch aufgeladen. Man merkt häufig erst nach Tagen, Wochen oder Monaten, ob etwas wirklich gut war. Und bis dahin ist der Zug oft längst weitergefahren.

Ich glaube, genau deshalb wirkt agentisches Arbeiten gerade im Engineering so überzeugend. Nicht weil Entwickler plötzlich die besseren Unternehmer wären. Sondern weil ihr Arbeitsfeld heute schon mehr maschinenlesbare Rückmeldungen enthält als fast jeder andere Bereich im Unternehmen.

Deshalb verschiebt sich der Flaschenhals

Wenn Implementierung plötzlich billig und schnell wird, verschwindet der Rest der Arbeit ja nicht. Er fällt nur viel härter auf.

Der Flaschenhals sitzt dann nicht mehr primär im Code, sondern bei Anforderungen, fachlicher Klärung, QA, Abnahme, Priorisierung und Governance. Genau dort also, wo das Feedbacksignal schwach ist oder teuer wird. Das ist der Punkt, an dem viele Organisationen gerade knirschen.

Viele reagieren darauf nicht mit organisatorischem Umbau, sondern mit Verkleinerung. Das ist kurzfristig sogar nachvollziehbar. Wenn ein oder zwei Leute mit Agenten plötzlich sehr viel schaffen, warum sollte man dann erst mühsam den Rest der Organisation auf dieses neue Tempo bringen?

Darin steckt für mich aber ein Denkfehler. Das Ein-Mann-Setup ist nicht automatisch das bessere Modell. Es ist oft nur das Modell mit den geringsten Koordinationskosten.

Der betriebliche Schaden zeigt sich auch nicht sofort. Erst entstehen Wissensinseln, weil immer weniger Leute wirklich verstehen, wie Entscheidungen zustande kamen. Dann werden Reviews zum Nadelöhr, weil ein paar wenige alles fachlich und technisch abfangen sollen. Und irgendwann werden Entscheidungen fragiler, weil der Widerspruch fehlt, der sie früher im Team robuster gemacht hat.

Vielleicht wird der Rest der Organisation auch noch agentischer. Aber dafür müssten dort erst eigene verifizierbare Feedbacksignale entstehen. Klarere Qualitätskriterien. Reversiblere Entscheidungen. Bessere Entwurfs- und Review-Schleifen. Genau da stehen viele Firmen noch ziemlich am Anfang.

Warum mich das beunruhigt

Ich will den Reiz davon gar nicht kleinreden. Ich genieße ihn ja selbst. Weniger Meetings. Weniger Warten. Weniger Abstimmung. Mehr Flow. Mehr Output. Das fühlt sich gut an, und oft ist es auch wirklich gut.

Trotzdem halte ich das langfristig für ein schlechtes Zielbild.

Vielleicht ist genau das der unangenehme Teil daran: Dieses Modell wirkt nicht gefährlich, sondern erstmal befreiend.

Denn wenn Menschen immer mehr mit Maschinen und immer weniger miteinander arbeiten, geht etwas verloren, das in keiner Produktivitätsgrafik auftaucht. Widerspruch. Reibung. Gemeinsame Begriffsbildung. Lernen am Gegenüber. Das Korrektiv eines Teams. Die Erfahrung, dass jemand anders dasselbe Problem ganz anders anschaut und damit den eigenen Horizont erweitert.

Allein mit Agenten kann man sehr viel schaffen. Das ist ja gerade der Punkt. Aber meistens bleibt man dabei innerhalb der Grenzen der eigenen Perspektive. Die Agenten multiplizieren dann nicht nur die Stärken, sondern auch die blinden Flecken. Man baut schneller, aber nicht automatisch besser. Und man entwickelt sich dabei auch nicht automatisch weiter.

Teams sind anstrengend. Keine romantische Verklärung von meiner Seite. Aber sie sind nicht nur ein Kostenfaktor. Sie sind auch ein Denkraum. Wenn ich das durch einen einzelnen Menschen mit sehr viel Output ersetze, gewinne ich Geschwindigkeit und verliere oft Ambition, Qualitätstiefe und gemeinsame Verantwortung.

Was es stattdessen braucht

Mich interessiert deshalb weniger, wie viele Entwickler man durch Agenten ersetzen kann. Mich interessiert mehr, wie Organisationen mehr verifizierbare Feedbacksignale bauen können und wie sie dabei Teamarbeit nicht kaputtsparen.

Für mich sind das gerade zwei Hebel.

Der erste Hebel ist technischer und prozessualer Natur: bessere Tests, klarere Akzeptanzkriterien, Example Mapping, saubere Review-Schleifen. Außerhalb der Software heißt das eher: Entwürfe statt Direktentscheidungen, reversiblere Prozesse, explizitere Qualitätskriterien, klarere Freigaben und nachvollziehbare Protokolle.

Der zweite Hebel ist sozial und organisatorisch: Formate schützen, in denen Verständnis gemeinsam entsteht. Gemeinsame Reviews. Architekturgespräche. Pairing an den kritischen Stellen. Rotierende Verantwortung statt eines einsamen Hochleisters mit eigener Agentenflotte.

Nicht damit Menschen aus dem Prozess verschwinden. Sondern damit Menschen mit Agenten arbeiten können, ohne voneinander abgeschnitten zu werden.

Ich glaube durchaus, dass Teams durch agentisches Arbeiten kleiner und schärfer werden. Das erscheint mir realistisch. Aber wenn am Ende jeder nur noch mit seiner persönlichen Agentenflotte arbeitet und die eigentliche Zusammenarbeit verdampft, dann haben wir auf das falsche Ziel optimiert.

Nur produktiver zu vereinsamen ist für mich kein Fortschritt.