agentic-coding · 2026-05-17

Was bei Agentic Coding nicht funktioniert — Lessons aus 8 Conductor-Versionen

agentic-codingconductorlessons-learnedfailuresanti-patterns

TL;DR

Acht Major-Versionen Conductor in 24 Monaten, jede mit einem Architektur-Bruch. Dieser Post listet die sieben konkreten Failures, die mich diese Brüche gekostet haben — jeder mit Ursache, Symptom, und Fix. Keine Best-Practice-Liste, sondern eine Anti-Best-Practice-Liste: was Agentic Coding kaputt macht, wenn man es nicht weiß. Der Diskurs zu “Agentic Coding Best Practices” ist gesättigt (Anthropic Engineering Blog, Maven, GoDaddy, Google Cloud, McKinsey). Was fehlt: ehrliche Failure-Berichte mit Token-Budget-Deltas.

Acht Versionen Conductor — sieben Failures, sieben Fixes Featured-Image-Platzhalter: stilisierte Versions-Timeline mit Bruchstellen. Asset folgt — Prompt am Ende.

Inhaltsverzeichnis

Failure 1: Der Mega-Prompt war eine Lüge

Version: Conductor v1.0 (Mai 2024) Symptom: Antworten wurden nach 20 Min Session unsauber, irrelevant, halluziniert. Ursache: Ich hatte einen 8.000-Wort-System-Prompt, der “alles” beschrieb — PRD, API, DB, Tests, Release-Notes. Dachte: mehr Kontext = bessere Antworten.

Was tatsächlich passierte: der Mega-Prompt verschlang das Kontext-Window von Anfang an. Schon die erste Antwort hatte 60% des verfügbaren Token-Budgets bereits in System-Prompt-Re-Reading verbraucht. Mit jeder Interaktion verschlechterte sich die Output-Qualität, weil das Model mehr Energie auf das Re-Parsing des Prompts verwandte als auf die eigentliche Aufgabe.

Fix in v2.0: Aufteilung in 4 kleinere Plugins. Je Plugin nur das, was für die spezifische Phase relevant ist. Token-Budget-Ersparnis: ~70%.

Lesson: “Mehr Kontext = besser” ist falsch ab einer bestimmten Größe. Pro Domäne ein Plugin, nicht pro Solo-Founder ein Mega-Plugin. Anthropics Engineering-Blog zu Context Engineering hat das mittlerweile bestätigt — aber als ich v1 baute, war diese Doku noch nicht öffentlich.

Failure 2: Cleverness statt Granularität (v5-Rollback)

Version: Conductor v5.0 (April 2025) — wurde nach 2 Wochen zurückgerollt Symptom: Output war träge, Antwort-Qualität schlechter als v4, Switching zwischen Phasen langsamer. Ursache: Ich hatte versucht, eine “smart-router”-Plugin-Architektur zu bauen. Ein einzelnes Master-Plugin sollte intelligent entscheiden, welches Sub-Plugin geladen wird. Decision-Tree mit ~20 Verzweigungen.

Was tatsächlich passierte: Der Smart-Router war selbst zu komplex. Bei jeder Anfrage musste Claude erst durch den Decision-Tree laufen, bevor die eigentliche Arbeit starten konnte. Die “intelligente” Pre-Stage fraß ~300-500 Token pro Aufruf, ohne dass die Routing-Entscheidung besser war als ein trivialer Heuristic.

Fix in v6.0: Smart-Router komplett raus. Plain Slot-Strategie: Du sagst welche Plugin-Familie ist relevant, Conductor lädt direkt. Latenz-Ersparnis: ~25%. Output-Qualität: +1 Tier.

Lesson: Dumm-explizit schlägt schlau-implizit fast immer im Agent-Loop. Wenn du eine “intelligente” Entscheidungsschicht baust, frage erst: kann der Mensch das in 5 Sekunden treffen? Wenn ja, ist die intelligente Schicht overhead.

Failures 1-2 visualisiert: Mega-Prompt → Granularität → Smart-Router-Failure Inline-Image-Platzhalter: Visualisierung der ersten zwei Failures als Lerne-Pfeil. Asset folgt.

Failure 3: Synchrone MCP-Calls im Agent-Loop

Version: Conductor v6.0-v6.3 (August-Oktober 2025) Symptom: Agent-Loop blockierte für 5-10 Sekunden bei jedem Tool-Call. Workflows mit 15+ Calls wurden unbenutzbar. Ursache: Ich hatte einen Yahoo-Finance-MCP-Server gebaut. Jeder Call war synchron, dauerte ~400ms im Median, manchmal 2-3s bei Quota-Limits oder Network-Hiccups.

Was tatsächlich passierte: Bei einem typischen AI-Trader-Workflow mit 30 Symbol-Lookups summierten sich die MCP-Latenzen auf 12-90 Sekunden — zusätzlich zu Claudes normaler Antwortzeit. Die Latenz war so spürbar, dass ich den Yahoo-MCP-Server schlicht nicht mehr nutzte.

Fix in v7.0: MCP-Server raus. Ersetzt durch ein Python-Script, das Yahoo-Daten alle 5 Minuten lokal cacht. Claude greift via Standard-Bash-Tool auf die gecacheden Daten zu. Latenz-Reduktion: ~95%.

Lesson: MCP ist die teuerste Extension-Klasse (siehe meinen Plugins-vs-Skills-Post). Pro Call 200-500ms im Idealfall, real oft mehr. Nur einsetzen, wenn der Service-Charakter zwingend ist — und nie für Daten, die du lokal cachen kannst.

Failure 4: Skills ohne präzise Description-Zeile

Version: Conductor v3.5 (November 2024) Symptom: Skills wurden nie automatisch geladen — oder zu oft, am falschen Punkt. Ursache: Die Description-Zeilen meiner Skills waren vage: “This skill handles testing”, “This is for documentation”. Claude konnte nicht zwischen ähnlichen Kontexten unterscheiden.

Was tatsächlich passierte: Bei “Wie viele Tests hat dieses Modul?” (Frage) und “Schreibe Tests für dieses Modul” (Aufgabe) wurde derselbe Skill geladen. Aber die Skills mussten unterschiedliches Knowledge zur Verfügung stellen.

Fix in v4.0: Description-Zeilen wie Test-Namen formulieren. Vorher: “This skill handles testing”. Nachher: “Use when user wants to generate new test files for an existing module that lacks test coverage. Do NOT use for reading or analyzing existing tests.” Skill-Trefferquote: von ~30% auf ~85%.

Lesson: Skill-Descriptions sind API-Verträge mit Claude. Vague Descriptions = breaking the contract. Anthropics offizielle Skill-Doku zeigt das Format — aber die Trennschärfe muss von dir kommen.

Failure 5: Subagents als Konversations-Container

Version: Conductor v6.5 (September 2025) Symptom: Subagent-Workflows brachen mitten in der Aufgabe ab oder produzierten halbfertigen Output. Ursache: Ich hatte versucht, Subagents iterativ zu nutzen. “Hey Subagent, mach Step 1. Okay, gut, jetzt Step 2 mit dem Ergebnis von Step 1.”

Was tatsächlich passierte: Subagents haben keine Persistenz zwischen Aufrufen. Der zweite Aufruf wusste nichts vom ersten — er fing mit frischem Kontext an. Das Iterations-Pattern, das ich versucht hatte, war nie für Subagents gedacht.

Fix in v7.0: Subagents nur für one-shot heavy work. Iterative Workflows bleiben in der Hauptkonversation oder werden als Sequenz mehrerer separater Aufgaben mit explizitem Hand-off (Markdown-Datei als State) realisiert. Workflow-Abbruchrate: von ~40% auf ~5%.

Lesson: Subagents sind Fresh-Context-One-Shots, keine Konversations-Partner. Wenn du iterieren willst, brauchst du entweder Main-Claude oder explizites State-Passing zwischen separaten Subagent-Calls.

Failure 6: Keine Hooks vor Quality-Gates

Version: Conductor v1-v6 (Mai 2024 bis November 2025) Symptom: Production-Bugs durch Commits, die Tests verfehlt hatten oder ohne Build-Check rauspusht waren. ~5-8 Bug-Inzidente in 18 Monaten. Ursache: Ich verließ mich darauf, dass ich vor jedem Push “manuell daran denke”, Tests laufen zu lassen. ADHS-typischer Vergessens-Tax in der Praxis.

Was tatsächlich passierte: Manuelle Disziplin in 8-parallele-Projekte-Modus skaliert nicht. Ich vergaß im Schnitt einmal pro Woche einen Quality-Check. Davon landeten ~30% in Production-Bugs.

Fix in v7.0: Hooks-System eingeführt. Jedes Plugin kann PreToolUse-Hooks definieren, die vor einem git push zwangsweise laufen. finalizer-Plugin enforced: Build grün, Tests grün, Lint clean — sonst kein Push. Bug-Inzidente seit v7.0: 1 (nach 6 Monaten).

Lesson: Hooks > Konventionen. Was du nicht erzwingen kannst, vergisst du. Vor allem in Hyperfokus-Modus.

Failure 7: Cross-Repo-Annahmen ohne Verifikation

Version: Conductor v8.0 (März 2026) Symptom: Cross-Repo-Refactorings schlugen sporadisch fehl. “Plugin A nutzt Convention X, aber Plugin B hat Convention Y.” Ursache: Ich nahm an, dass alle 13 Conductor-Plugins die gleichen internen Conventions nutzten. Tatsächlich war das durch 24 Monate Evolution längst inkonsistent.

Was tatsächlich passierte: Ein neues marketing-pilot-Plugin nutzte eine Konvention, die seit v6 deprecated war. Aber nichts hatte die alte Konvention je explizit verworfen. Cross-Plugin-Calls schlugen unvorhersagbar fehl.

Fix in v8.1.0: Cross-Repo-Convention-Check als Teil der Hooks-Stage. Aktuell teilweise gefixt — vollständige Lösung kommt erst mit v9, da das ein systematisches Problem ist, das mehr Tooling braucht.

Lesson: Implizite Conventions in Multi-Plugin-Systemen verfaulen. Wenn du nicht explizit Convention-Definitionen pflegst (versioned, mit Migration-Pfad), wirst du in Cross-Plugin-Bugs verlieren. Microservices-Diszipline ist hier 1:1 anwendbar.

Die sieben Failures als Lessons-Map Inline-Image-Platzhalter: Lessons-Map der sieben Failures. Asset folgt.

Was die Best-Practice-Posts auslassen

Ich habe vor diesem Post die zehn meistgelesenen “Agentic Coding Best Practices”-Artikel durchgesehen (Anthropic Engineering, Google Cloud, McKinsey QuantumBlack, Maven, GoDaddy, timdeschryver.dev, MindStudio, plus die Reddit-Threads). Sieben dieser zehn enthalten keine Failure-Berichte. Drei haben einen kurzen Satz dazu.

Das ist die Diskurs-Lücke. Best Practices sind nur halb so lehrreich wie die Failures, aus denen sie kondensiert wurden. Was du oben gelesen hast, sind die Failures — die “Best Practice” “separate plugins, scoped contexts, hooks before push, precise skill descriptions, one-shot subagents, no MCP for cacheable data, explicit cross-repo conventions” ist die destillierte Form. Aber die destillierte Form alleine sagt dir nicht, warum sie wichtig ist.

Wo das hingeht

Conductor v9 wird primär drei dieser Failures systematisch adressieren:

  1. Cross-Repo-Convention-Versioning (Failure 7) — mit Migration-Pfaden für deprecierte Patterns
  2. Subagent-State-Passing als First-Class-Konzept (Failure 5) — keine iterativen Subagent-Patterns mehr nötig
  3. Multi-LLM-Orchestrierung — neue Klasse von Failures, die noch nicht aufgetreten ist, aber kommen wird wenn Codex/Kimi für spezifische Sub-Tasks aufgerufen werden

Wenn du selbst einen Agentic-Coding-Stack baust und an einem der oben gelisteten Failures hängst: schreib mir auf LinkedIn oder GitHub.

FAQ

Welcher der sieben Failures hat am meisten Zeit gekostet?

Failure 2 (Smart-Router-v5). 2 Wochen Bauzeit, 1 Woche Rollback-Schmerz, plus ~3 Wochen mentaler Reset bis ich an v6 wirklich frisch ran konnte. Total: ~6 Wochen.

Sollte ich Agentic Coding überhaupt versuchen, wenn so viele Failures möglich sind?

Ja, aber kleiner starten als ich. v1 mit Mega-Plugin war Hybris. Beginnt mit 1-2 Custom Commands, eskaliert zu Skills bei wiederholten Workflows, baut Plugins erst nach ~6 Monaten produktiver Nutzung. Das spart 5 der 7 Failures.

Sind diese Failures Anthropic-spezifisch oder gelten sie auch für Codex / Cursor?

Failures 1, 2, 5, 6 sind LLM-Agent-übergreifend. Failures 3, 4, 7 sind Claude-Code-spezifisch wegen MCP/Skills/Plugin-Mechanik. Wenn du auf Cursor oder Codex bist, hat dein System eigene strukturelle Failures, die ich nicht kenne.

Wann ist ein Conductor-Rollback (wie v5) die richtige Entscheidung?

Wenn nach 2 Wochen messbarer Einsatz schlechter ist als die vorherige Version. Nicht warten bis es “objektiv schlimm” ist — dann hast du 4-6 Wochen verloren. Ich nutze die Daumenregel: wenn ich nach 2 Wochen die Daten überprüfe und der Output messbar schlechter ist, rollback noch in derselben Woche.

Welcher Failure war der peinlichste?

Failure 6 (keine Hooks vor Quality-Gates). 18 Monate lang dachte ich, ich könnte das manuell kompensieren. ADHS hat mir das nie verziehen. Production-Bugs in 6 von 18 Monaten — alle durch denselben Mechanismus. Sollte ich nach v1 bereits gefixt haben.

Geschrieben am 17. Mai 2026 in Hamburg. Wenn du diesen Post hilfreich findest, verlinke ihn — Failure-Berichte sind im Agentic-Coding-Diskurs unterrepräsentiert.