Claude Code Dynamic Workflows: Wenn KI die eigene Orchestrierungs-Schicht schreibt

Anthropic macht Dynamic Workflows für alle Pro-Nutzer verfügbar. 1'000 parallele Subagenten pro Run, Migrations-Tasks über Nacht, und die Architektur-Entscheidung, die Multi-Tag-Runs erst möglich macht.

Am 2. Juli verschickte Anthropic eine Update-Mail, die auf den ersten Blick wie ein Feature-Launch aussah: Dynamic Workflows sind jetzt General Availability, erstmals auch für Pro-Plan-Nutzer. Wer die Details las, verstand: Das ist kein Feature-Upgrade. Das ist ein Architektur-Shift, der die Frage neu definiert, was ein KI-Coding-Tool überhaupt ist.

Claude Code war bis vor zwei Wochen ein sehr guter AI-Coding-Assistent. Seit Dynamic Workflows GA sind, ist es eine Entwicklungsumgebung, in der die KI ihre eigene Orchestrierungs-Schicht schreibt — on the fly, tailored für den spezifischen Task, und mit bis zu 1’000 parallelen Subagenten pro Run.

Die Konsequenz: Migrations-Tasks, die im Backlog für «Q3 2027, wenn wir Zeit haben» standen, laufen jetzt über Nacht. Codebase-weite Security-Audits, die manuell drei Wochen dauern würden, sind in einem nachmittäglichen Workflow erledigt. Und die Definition von «technischer Schuld» verschiebt sich fundamental — weil der Bottleneck nicht mehr «haben wir die Kapazität dafür» ist, sondern «haben wir einen klaren Spec für was wir wollen».

Was Dynamic Workflows architektonisch anders macht

Normale Claude-Code-Sessions halten den Orchestrierungs-Plan im Context-Window des Modells. Wenn Claude einen Task in 5 Subtasks zerlegt, Subagents spawnt, deren Output sammelt, und synthetisiert — jedes Zwischenergebnis, jeder Dead-End, jeder Retry akkumuliert im selben Context. Bei einer 500’000-Zeilen-Codebase füllt sich das Window, bevor der Task fertig ist.

Dynamic Workflows externalisieren den Plan. Claude schreibt ein JavaScript-Orchestrierungs-Script. Ein separater Runtime (nicht das Modell selbst) führt das Script aus. Die Subagenten arbeiten parallel, jeder mit einem sauberen Context-Window und einem fokussierten Job. Das Modells Context-Window bekommt nur die finale synthetisierte Antwort — nicht die 200 Intermediate-Results.

Das ist der Grund, warum Multi-Tag-Runs überhaupt möglich sind. Nicht «schneller» — architektonisch möglich. Bei klassischen Agenten ist der Context-Window der Flaschenhals. Bei Workflows ist er es nicht mehr.

Rahul Patil, CTO bei Anthropic, formulierte es so: «Die Verbesserung, zu der ich immer zurückkomme, ist Ehrlichkeit.» Claude Opus 4.8 sprang auf SWE-bench Pro von 64,3 auf 69,2 Punkte. Aber Patils Punkt war: Das Modell hört jetzt auf, «fertig» zu sagen, wenn es nicht fertig ist. Workflows erzwingen das strukturell — weil der Plan nicht mehr im Kopf des Modells lebt, sondern in Code, der nicht müde wird, sich nicht selbst benotet, und nicht vergisst.

Der Bun-Port: 960’000 Zeilen in 6 Tagen, 99,8 % Tests grün

Jarred Sumner (Bun-Creator) nutzte Dynamic Workflows, um die Bun-Runtime von Zig nach Rust zu portieren. Das Resultat: ca. 750’000 Zeilen Rust-Code, 99,8 % der bestehenden Test-Suite läuft durch, Zeitrahmen: 11 Tage vom ersten Commit bis zum Merge.

Das Vorgehen in Phasen:

1. Mapping-Workflow: Rust Lifetimes für jedes Struct-Field mappen
2. Parallel-Port-Workflow: Behaviour-identische .rs-Ports für jedes .zig-File parallel schreiben
3. Fix-Loop-Workflow: Iterativ durch Build- und Test-Failures, bis Suite clean läuft
4. Optimierungs-Workflow (über Nacht): Unnötige Data Copies eliminieren, für jede ein PR öffnen zur finalen Review

Das wäre manuell ein Team-Projekt über mehrere Monate gewesen. Mit Workflows: ein Developer, 11 Tage, und die Test-Pass-Rate beweist, dass es keine Quick-and-Dirty-Konvertierung war.

Warum das Schweizer Agenturen interessiert: Wie viele Legacy-Codebases sitzen bei Suxeedo oder Whatwedo, wo die Migration von Framework X auf Y seit Jahren im Backlog steht, weil niemand 3 Monate Engineer-Zeit committen will? Workflows ändern die Kosten-Kalkulation radikal. Der Bottleneck ist jetzt nicht mehr «haben wir die Kapazität» — es ist «haben wir einen klaren Spec und eine Test-Suite».

Was Schweizer Dev-Teams diese Woche testen sollten

1. Codebase-weite Migrations-Tasks

Beispiel-Prompt:

«Create a workflow to migrate all class-based React components in /src to functional components with hooks. Preserve all existing behavior, convert lifecycle methods to useEffect/useCallback correctly, add TypeScript types where missing, run the existing test suite after each file migration, stop and report if any test fails.»

Claude schreibt ein Orchestrations-Script, validiert während der Migration, und stoppt wenn Tests failn — statt blind durch 500 Files zu powern und Ihnen am Ende einen roten Test-Report zu geben.

Schweizer Agenturen wie Ginetta (Design + Dev) könnten das für Design-System-Migrations nutzen: alte Component-Library → neue, mit Behavioral-Parity-Checks pro Component.

2. Security-Audits und OWASP-Compliance-Checks

«Create a workflow to audit this Express.js API for OWASP Top 10 vulnerabilities. Check every route handler for missing authentication, unvalidated inputs, SQL injection risks, XSS vectors. Cross-validate findings before reporting.»

Workflows spawnen parallele Agents über die Codebase, validieren Findings gegenseitig (adversarial review), und filtern False Positives raus, bevor das Report zu Ihnen kommt.

Für Agenturen mit öffentlichen-Sektor-Clients (Whatwedo macht viel Bund/Kantone-Arbeit) ist das der Unterschied zwischen «wir machen Security-Review in Sprint 12» und «wir laufen Security-Audit jede Woche automatisiert».

3. Dead-Code-Cleanup und Refactoring-Opportunities

Klarna-Teams nutzen Workflows, um Dead Code zu identifizieren, den Traditional Static Analysis übersieht. Das Ergebnis: Cleanup-Opportunities, die Engineers schneller an Maintenance- und Refactoring-Work bringen.

«Create a workflow to identify all functions, classes, and modules in this codebase that are never imported or called. Cross-check with test files to avoid false positives. Report candidates for deletion with confidence scores.»

Für Schweizer Agenturen mit grossen Legacy-Monolithen (die meisten Software-Häuser über 10 Jahre alt) ist das der Use Case, der Material-Wert liefert: pro Quartal einen Cleanup-Workflow laufen lassen, die Top-20-Candidates reviewen, und die Codebase gesund halten.

4. Multi-Source-Fact-Checking (Content-Teams)

Der /deep-research-Built-in-Workflow in Claude Code zeigt den Pattern: eine Frage über viele Sources recherchieren, Claims cross-checken, Widersprüche flaggen, finale Report mit nur verified Claims zurückgeben.

NZZ Visuals (Data Journalism) könnte das für Fact-Checking-Pipelines nutzen: «Check this claim against 10 authoritative sources, verify numbers, flag conflicting reports, synthesize a final verified statement with citations.»

Die Grenzen: Wann Workflows NICHT die Lösung sind

Workflows sind nicht «schnellere Single-Agent-Runs». Sie sind für Tasks, wo die Ausgabe von Stage N die nächste Stage bestimmt — also Route, Score, Filter, Loop, Retry, Generate, Verify, Build.

NICHT geeignet für:

• Single-Function-Rewrites (normaler Claude Code ist schneller + billiger)
• Tasks, wo Sie den exakten Ablauf manuell steuern wollen (Workflows sind autonomer — Claude entscheidet den Plan)
• Exploratives Prototyping (Workflows sind für definierte Outcomes, nicht «lass uns mal schauen was rauskommt»)

Workflows vs. Agent Teams: Teams sind persistent, Workflows sind einmalig. Wenn Sie eine langlebige Struktur brauchen (z. B. ein Customer-Support-Bot mit spezifischen Agents für Billing/Tech/Eskalation), bauen Sie ein Team. Workflows sind für «diese Migration jetzt einmal durchziehen».

Workflows vs. Agent SDK: Das Agent SDK ist für embedded agents — die Sie in Ihre eigene App/Produkt bauen. Dynamic Workflows sind für workspace agents — die Ihre eigene Arbeit (Coding, Research, Knowledge Work) in Claude Code erledigen. SDK = agents you ship. Workflows = agent you work with.

Wie Sie Dynamic Workflows aktivieren (Pro-Plan-Nutzer)

1. Claude Code aktualisieren: v2.1.154 oder neuer (CLI, Desktop, VS Code Extension)
2. In /config aktivieren: Dynamic Workflows Row auf ON
3. Trigger via Prompt: «Create a workflow to…» ODER
4. Ultracode-Setting nutzen: Schaltet Effort auf xhigh, Claude entscheidet automatisch wann ein Workflow nötig ist

Empfohlene Reihenfolge für erste Tests:

1. Kleiner Scope (ein Directory, 10–50 Files)
2. Klarer Outcome (Migration, Audit, Cleanup — nicht «mach mal besser»)
3. Bestehende Test-Suite als Validation (Workflows können Tests nach jeder Change laufen lassen)
4. /workflows-View offen halten, Token-Usage monitoren

Nach 2–3 erfolgreichen Runs haben Sie ein Gefühl für Cost/Benefit — dann können Sie auf Full-Repo-Scale gehen.

Was das für die nächsten 6 Monate bedeutet

Anthropic hat mit Dynamic Workflows die Definition von «AI Coding Tool» neu gezogen. Das ist nicht mehr «schnellerer Autocomplete» oder «besserer Copilot». Das ist eine Entwicklungsumgebung, in der die KI ihre eigene Orchestrations-Schicht schreibt — tailored, on-demand, mit parallelen Subagenten und struktureller Validation.

Die Konsequenz für Schweizer Agenturen: Der Backlog-Eintrag «Migration von X auf Y» ist jetzt nicht mehr ein 3-Monats-Projekt. Es ist ein Nachmittag zum Spec schreiben, ein Overnight-Workflow, und ein Tag zum Review. Die Frage verschiebt sich von «haben wir die Kapazität dafür» zu «haben wir einen klaren Outcome-Spec».

Teams, die das im nächsten Quartal verstehen und anwenden, werden ihre Velocity 3–5× steigern — nicht weil sie schneller coden, sondern weil die Arbeit, die bisher «zu gross für jetzt» war, jetzt «zu billig um sie NICHT zu machen» ist.

Die Tools existieren. Die Architektur ist proven. Was fehlt, ist das mentale Modell: «Welche unserer Backlog-Items sind eigentlich Workflow-Kandidaten?»