Der Käfig war der Punkt: Warum Unternehmen noch nicht bereit für vollautonome Agents sind

Das Experiment, das ich im Side-Project-Post beschreibe, begann wegen eines Käfigs.

Kein feindlicher Käfig. Kein schlechter. Einer, der aus guten Gründen gebaut wurde: Produktionssysteme, die täglich Millionen von Menschen nutzen. Teamprozesse, die verhindern, dass der Fehler eines einzelnen Entwicklers zum Incident für alle wird. Code-Review-Zyklen, die die Dinge auffangen, die Erschöpfung unsichtbar macht. Freigabeprozesse, die existieren, weil die Kosten einer Fehlentscheidung in einem Unternehmen sozialisiert werden — sie landen bei Kollegen, bei Kunden, bei den Entwicklern, die um 2 Uhr nachts rausgeklingelt werden.

Ich arbeite bei Kleinanzeigen. Ein toller Arbeitgeber. Ich bin stolz auf das, was das Unternehmen macht und wie es arbeitet. Und nach Monaten KI-gestützter Entwicklung in dieser Umgebung bin ich immer wieder gegen eine andere Art von Wand gestoßen — keine technische, sondern eine organisatorische. Ich konnte nie herausfinden, wie weit KI wirklich gehen kann, weil das System jedes Mal, wenn ich an die Grenzen stieß, zu Recht zurückdrückte. Ein Sprint-Commitment. Ein Review-Zyklus. Ein Abstimmungsgespräch, das stattfinden musste, bevor eine Entscheidung getroffen werden konnte.

Ich habe den Käfig nicht gehasst. Ich habe ihn verstanden. Und dieses Verständnis hat ihn in ein Experiment verwandelt.

---

Meine Rolle an der Front

Bevor ich erkläre, warum Unternehmen noch nicht bereit sind, muss ich erklären, was ich dort tue.

Ich nutze KI-Tools bei der Arbeit nicht einfach nur für mich. Meine Rolle hat sich zu etwas wie einem internen KI-Experten entwickelt — ich nehme an Meetings teil, halte Workshops ab, beantworte Einzelfragen von Kollegen, die irgendwo auf dem Weg sind von „Ich hab mal ChatGPT benutzt” bis zu „Ich will verstehen, was das für unsere Softwareentwicklung bedeutet.” Meistens bin ich die Person im Raum, die das Ding schon ausprobiert hat, über das alle noch spekulieren.

Diese Position erarbeitet man sich, indem man die Experimente zuerst macht. Du kannst nichts lehren, was du nicht selbst erlebt hast. Also mache ich Sessions, stoße an Wände, dokumentiere was bricht, und bringe dieses Wissen zurück. Die KI, die ich bei der Arbeit einsetze, unterscheidet sich von der auf dem Side-Project — nicht das Modell, aber die Konfiguration, die Berechtigungen, der Umfang dessen, was ich sie anfassen lasse. Das Arbeitsumfeld erzwingt Einschränkungen, die dort Sinn ergeben. Das Side-Project-Umfeld hatte keine dieser Einschränkungen — und das war Absicht. Nur dort konnte die eigentliche Frage — „wie weit kann man wirklich gehen?” — ehrlich beantwortet werden.

Der Unterschied ist wichtig. Ich bin nicht hier, um Unternehmen zu kritisieren. Ich bin hier, weil ich in einem Unternehmen arbeite, es für richtig halte, und mir genau überlegt habe, was KI-Autonomie voraussetzt, bevor ein Unternehmen sie sicher entfesseln kann.

---

Die Fragen, die noch niemand vollständig beantwortet hat

Das sind die Punkte, über die Unternehmen zu Recht nachdenken — geordnet danach, wie lösbar sie sind.

Blast Radius. Wenn ein Agent einen Fehler macht — falscher API-Aufruf, falsche Umgebung, falscher Aktionsumfang — was ist der maximale Schaden? Das ist keine Hypothese. Agents haben Schreibzugriff. Sie können Dinge löschen, E-Mails verschicken, schlechten Code committen, Infrastruktur provisionieren. Die Frage „wie begrenzen wir, was ein Agent beeinflussen kann?” hat noch keine saubere unternehmenstaugliche Antwort. Scoped Credentials helfen. Sandbox-Umgebungen helfen. Aber das mentale Modell von „was darf dieser Agent genau tun, und wie verifiziere ich das?” wird gerade noch branchenübergreifend erarbeitet. Wir haben noch kein Äquivalent zu Kubernetes RBAC für autonome Agents.

Produktionszugriff. Verwandt, aber verschieden. In einem professionellen Umfeld ist der Zugriff auf Produktionssysteme kontrolliert, auditiert und bewusst vergeben. Ein Agent, der im Namen eines Entwicklers handelt, erbt — oder sollte erben — dieselben Zugangsbeschränkungen wie dieser Entwickler. Aber die meisten Tools setzen das nicht sauber durch. Der Agent, der in der Entwicklungsumgebung einwandfrei funktioniert, hat dieselben Credentials wie der Entwickler, der ihn ausführt — und damit Zugriff auf alles, worauf dieser Entwickler Zugriff hat. So würde man es nicht bauen, wenn man es absichtlich bauen würde.

Wer darf Agents orchestrieren? Das ist die Frage, die ich in jedem Workshop stelle. Nicht „kannst du Claude Code nutzen?” — das ist eine Fähigkeitsfrage. Sondern: Verstehst du, was du übergibst, wenn du einem Agent eine Aufgabe gibst? Weißt du, wann du ihn stoppen musst? Kannst du die Ausgabe kritisch genug lesen, um die subtil falschen Antworten zu erkennen — den Code, der kompiliert, die Ausgabe, die richtig aussieht, die Änderung, die in einem anderen Kontext in Ordnung gewesen wäre, hier aber ein Problem ist? Agent-Orchestrierung erfordert ein Skillset, das Zeit braucht, um es aufzubauen. Jemandem die Tools zu geben, der dieses Skillset noch nicht hat, gibt ihm keine Fähigkeiten — es gibt ihm Verantwortung ohne das Urteilsvermögen, sie auszuüben.

Genau hier stecken die meisten Unternehmen fest — und das zu Recht. Und es führt zur Erkenntnis, über die ich am meisten nachdenke.

---

Was ich nicht teile

In jedem Workshop stellt jemand dieselbe Frage.

„Kannst du dein Setup teilen? Die Agents, die Skills, die MCP-Verbindungen — das ganze Ding?”

Die Antwort ist nein. Nicht weil ich meine Tools schütze. Sondern weil mein Setup ihnen nicht geben würde, wonach sie eigentlich fragen.

Meine Agents funktionieren für mich, weil sie die Art widerspiegeln, wie ich denke. Die Prompts, die in meinen Skills funktionieren, sind keine übertragbaren Anweisungen — sie sind komprimierte Versionen meines mentalen Modells. Das Vokabular, das ich verwende, die Art, wie ich ein Problem formuliere, die Annahmen, die ich darüber treffe, was „fertig” bedeutet: all das steckt in meinem System-Prompt, meiner CLAUDE.md, den Wörtern, die ich instinktiv wähle, wenn ich eine Aufgabe beschreibe. Jemand anderes mit exakt meinem Skills-Verzeichnis würde bei Prompts scheitern, bei denen ich Erfolg habe — weil sein Hintergrund ein anderer ist. Seine Worte sind andere. Seine Intuitionen darüber, was ein Agent hören muss, um das Richtige zu tun, sind andere.

Ich habe das beobachtet. Ein Kollege nimmt ein Setup, das für mich funktioniert, führt es auf einer ähnlichen Aufgabe aus — und bekommt nur Müll raus. Nicht weil die Tools schlecht sind — sondern weil die Prompts eine Sprache sind, und diese Sprache hat sich zwischen mir und den Tools entwickelt, über Hunderte von Sessions, geprägt durch meine spezifische Geschichte und mein Denken. Das lässt sich nicht installieren. Man kann nur seine eigene Sprache entwickeln.

Das ist ein echtes Problem für Unternehmen. Wenn der Wert der agentischen Entwicklung nicht in den Tools liegt, sondern in der erlernten Fähigkeit des Entwicklers, sie zu orchestrieren — und das glaube ich —, dann lässt sich das Adoptionsproblem nicht durch das Verteilen von Konfigurationen lösen. Du kannst keine CLAUDE.md schreiben, die für ein ganzes Team funktioniert, so wie ein Style Guide für ein ganzes Team funktioniert. Das Wissen steckt in den Köpfen derer, die es aufgebaut haben, und es überträgt sich langsam, individuell, durch Praxis.

Was ich in Workshops teile, sind nicht meine Agents. Es sind die Prinzipien. Das mentale Modell. Das richtige Verständnis davon, was ein Agent braucht, um gute Arbeit zu leisten. Ich zeige den AI Dev Ladder — die Progression vom Zero-Context-Prompting bis zur vollständig autonomen Pipeline-Orchestrierung — nicht als Anleitung, sondern als Karte. Du bist hier. Der Weg geht dahin. Finde deine eigenen Wände.

Das ist der einzige Weg, wie es skaliert.

---

Fähigkeit und Bereitschaft sind verschiedene Probleme

Das Side-Project hat die Fähigkeitsfrage beantwortet. 847 Commits. Ein Entwickler. Ein Quartal. Ein Produkt in Produktion.

Die Unternehmensfrage ist eine andere. Es geht nicht darum, ob KI-Agents Software bauen können. Diese Antwort ist seit einer Weile ja. Die Unternehmensfrage lautet: „Können wir diese Fähigkeit so entfesseln, dass wir kein unkontrollierbares Risiko einführen, mit Menschen, die das Urteilsvermögen haben, damit umzugehen, in Systemen, in denen der Blast Radius eines Fehlers bereits unter Kontrolle ist?”

Diese Frage hat eine kompliziertere Antwort. Vielleicht. Noch nicht. Aber wir arbeiten daran.

Der Käfig bei Kleinanzeigen hat mich nicht von der Fähigkeit abgehalten. Er hat zu Recht eine Reihe von Bedenken geschützt, mit denen autonome Agents noch nicht selbst umgehen können. Jede Freigabekette ist ein menschliches Urteil, das bei einer Entscheidung greift, der man das automatisierte System noch nicht allein überlassen kann. Das Ziel ist nicht, diese Ketten zu entfernen. Das Ziel ist, sich das Recht zu verdienen, sie zu lockern — ein gelöstes Problem nach dem anderen.

Blast Radius unter Kontrolle. Gelöst? Eine Kette entfernen.

Produktionszugriff-Governance. Gelöst? Eine Kette entfernen.

Genug Entwickler, die Agents wirklich sicher orchestrieren können. Aufgebaut? Eine Kette entfernen.

Wir arbeiten an allen dreien, parallel, mit unterschiedlichem Tempo. Diese Arbeit ist real, sie läuft, und sie wird dieses Jahr nicht abgeschlossen sein. Die Unternehmen, die hier vorsichtig vorgehen, sind keine Maschinenstürmer. Sie sind Ingenieure.

---

Das Experiment auf dem Side-Project war keine Flucht aus dem Käfig. Es war eine andere Frage — gestellt in einem anderen Raum. Die Unternehmensfrage und die Fähigkeitsfrage müssen getrennt beantwortet werden — sonst verwechselt man, was man eigentlich misst.

Der Käfig war der Punkt. Ohne ihn hätte ich den Reinraum nicht gebraucht. Ohne den Reinraum hätte ich die Antwort nicht, um sie zurückzubringen.

Genau das ist die Aufgabe der Front.