Letzte Woche habe ich für eine Meetup Demo (CocoaHeads Aachen) einen Skill für Claude Code angepasst. Der Skill Creator ist super dafür: ein Plugin, das beim Erstellen und Verbessern von Skills hilft und mit Opus sehr gute Vorschläge von sich aus machen kann. Am Ende hat der Workflow etwas Kluges vorgeschlagen: „Soll ich den alten und den neuen Skill gegeneinander laufen lassen? Baseline gegen Variante, damit du siehst, ob die Änderung wirklich besser ist.“
Ich war sofort dabei. A/B-Test für Prompts, automatisch orchestriert, direkt aus dem Workflow heraus? Das ist das Level an Professionalität, das wir brauchen! Super.
Der Agent hat einen Worktree angelegt, die Kontrollgruppe vorbereitet, den neuen Skill daneben gestellt. Dann ließ er den Vergleichslauf starten. Ich wartete Ergebnisse ab. Nach 5–10 Minuten waren alle Vergleiche getan – und es stellte sich heraus, dass der Vergleich scheiterte: Der Subagent im Worktree hatte keine Berechtigung, Skills zu lesen oder weitere Subagents zu starten.
Die Infrastruktur, die der Vorschlag brauchte, war gar nicht da.
Kein Absturz oder kryptischer Fehler, sondern einfach: „Ich kann das gar nicht.“ (sad trombone)
Tolle Ideen, aber bitte mit Vorsicht!
Diese Episode fasst für mich den aktuellen Stand von agentischer Entwicklung ziemlich gut zusammen. Die Agenten werden erkennbar cleverer darin, sinnvolle nächste Schritte vorzuschlagen. Sie erkennen Muster, bieten Workflows an, die man selbst vielleicht nicht sofort im Kopf gehabt hätte. Der Vorschlag war nicht dumm. Er war sogar ausgesprochen gut!
Aber zwischen „guter Vorschlag“ und „funktionierender Workflow“ liegt eine Lücke, die gerade noch überraschend groß ist. Nicht weil die Modelle schlecht wären, sondern weil die Infrastruktur drumherum — Berechtigungen, Sandbox-Grenzen, Tool-Zugriffe, Orchestrierung über Kontextgrenzen hinweg — noch nicht mitgewachsen ist.
Das betrifft nicht nur Claude Code. Es betrifft jedes agentische Setup, das über einen einzelnen Agenten in einem einzelnen Verzeichnis hinausgeht. Sobald Parallelisierung, Worktrees oder Subagent-Ketten ins Spiel kommen, stößt man auf Stellen, an denen die Werkzeuge ihre eigenen Fähigkeiten überschätzen.
Guter Wille, fehlende Durchgängigkeit
An der Situation hat mich beschäftigt, dass nicht die technische Einschränkung als solche existiert, sondern das Muster, dass die Ausführung manchmal immer noch nicht klappt.
Der Agent hat eine Aktion vorgeschlagen, die konzeptionell sinnvoll war. Ich habe zugestimmt, weil der Vorschlag plausibel klang. Und keiner von uns beiden — weder der Agent noch ich — hatte vorher geprüft, ob die nötigen Voraussetzungen überhaupt erfüllt sind. Ich nahm an, der Agent weiß am besten, wie die eigenen Tools funktionieren. Schließlich lese ich die API, die dem Agent mitgeteilt wird, selbst ja gar nicht.
Hier liegt die Gefahr im Arbeitsalltag, an einer amüsanten Anekdote illustriert: Der Agent agiert zuversichtlich. Der Mensch vertraut, weil die Zuversicht überzeugend klingt. Und dann bricht etwas an einer Stelle, die keiner auf dem Schirm hatte. Auf diese Assertivität fallen wir schnell herein.
Im Teamkontext wird es interessanter. Wenn ein Agent einen Refactoring-Plan vorschlägt und das Team dem Plan folgt, ohne die impliziten Annahmen zu prüfen, kann dieselbe Dynamik teurer werden.
„Der Agent hat gesagt, das geht“ ist kein Argument.
Es ist ein Warnsignal dafür, dass die Verantwortung gerade den Besitzer wechselt — weg vom Entwickler, hin zum Tool.
Hier müssen wir alle vorsichtig sein.
Für den Praxisalltag als Agentic Engineer
Drei Dinge kann man aus der Story mitnehmen:
Erstens: Agentenvorschläge kritisch lesen, auch wenn sie klug klingen. Die Qualität der Vorschläge steigt mit jeder Modellgeneration. Das macht es einfacher, ihnen zu folgen. Und schwieriger, sie rechtzeitig zu hinterfragen. Die Frage „Kann der Agent das auch tatsächlich ausführen?“ ist genauso wichtig wie „Ist der Vorschlag inhaltlich sinnvoll?“
Zweitens: Orchestrierung ist noch kein gelöstes Problem. Wer heute mit Subagents, Worktrees und parallelen Workflows arbeitet, bewegt sich in einem Bereich, der zwar technisch möglich, aber nicht durchgängig zuverlässig ist. Das ist kein Grund, es nicht zu tun. Aber es ist ein Grund, die eigenen Erwartungen zu kalibrieren — und ein Backup zu haben, wenn der elegante Weg nicht funktioniert. In den letzten 6 Monaten hat sich unglaublich viel getan. Aber es ist immer noch sozusagen alles in „Beta“. (Interessanterweise ist ein schlankerer, aber auch gefährlicherer Agent Harness wie pi da flexibler und zuverlässiger zugleich.)
Drittens: Die Lücke zwischen Vorschlag und Umsetzung schrumpft, aber sie ist noch da. Vor einem Jahr hätte kein Agent diesen A/B-Test vorgeschlagen. In einem Jahr wird er wahrscheinlich funktionieren. Heute liegt der Wert darin, das Muster zu erkennen: gut gedacht, nicht ganz durchführbar, trotzdem ein Schritt nach vorn.
Wenn du in deinem Team agentische Workflows einführst, wird dir diese Dynamik begegnen. Ein Agent schlägt etwas Sinnvolles vor. Es klingt überzeugend. Und dann stellt sich heraus, dass eine Voraussetzung fehlt — ein Zugriff, eine Berechtigung, ein Kontext, den der Agent nicht hat.
Die Reaktion darauf entscheidet über die Qualität eurer Adoption.
Teams, die diesen Moment als „das Tool taugt nichts“ interpretieren, verlieren den Faden.
Teams, die lernen, Agentenvorschläge als Hypothesen zu behandeln — prüfbar, verwerfbar, oft gut, manchmal nicht umsetzbar — bauen eine belastbare Arbeitsweise auf.
Genau das ist der Unterschied zwischen Vibe Coding und Engineering mit KI: nicht blind folgen, sondern steuern, prüfen und entscheiden. Auch dann, wenn der Vorschlag verlockend klingt.