Snelheid werd goedkoop. Je oordeel niet.

Anthropic heeft Dynamic Workflows uitgebracht voor Claude Code. Vanuit één opdracht in gewone taal schrijft Claude ter plekke een JavaScript-orkestratiescript, en een runtime voert dat op de achtergrond uit, met tientallen tot honderden subagents parallel. De harde grens ligt op duizend.

Het getal dat iedereen noemt is duizend. Het interessante getal is hoe weinig je er eigenlijk nodig hebt.

Het pleidooi ervoor klopt ​

Voordat ik de tool uit elkaar haal: de techniek eronder is goed.

Eén agent met een grote, vage taak gaat zwalken. Hij leest bestanden opnieuw die hij al gelezen had, plant werk opnieuw dat hij al gepland had, en zit halverwege zonder context. Dynamic Workflows lossen dat op door de orkestratie deterministisch te maken. Claude schrijft de besturing één keer, in gewoon JavaScript, en de runtime draait hem: loops, fan-out, verificatie, synthese. Het model bepaalt de strategie. Het script bepaalt de uitvoering.

De patronen die erbij zitten, zijn de goede. pipeline() stuurt elk item door alle fases zonder barrière ertussen, dus item A kan in verificatie zitten terwijl item B nog gezocht wordt. Adversarial verify start onafhankelijke sceptici op met als taak om een bevinding te weerleggen, en gooit hem weg als de meerderheid dat doet. Judge panels laten concurrerende pogingen ontstaan en geven ze een score.

Komt dat bekend voor? Dat hoort ook. Het is het trio Architect, Feitenchecker en Advocaat van de Duivel gemaakt tot iets uitvoerbaars. Wat je vroeger met de hand deed, drie rollen spelen in één chat, is nu een script dat ze draait als losse agents die elkaars redenering echt niet kunnen zien. Die onafhankelijkheid is iets waard. Anchoring is echt, en een verificateur die context deelt met wat hij verifieert, is geen verificateur van betekenis.

Dat is echte structuur, en eer wie eer toekomt.

Een minimale workflow, zodat je weet waar we het over hebben ​

Dit is de vorm. Beoordeel een diff op twee dimensies, en probeer daarna elke bevinding te weerleggen voordat hij overleeft.

export const meta = {
  name: 'review-changes',
  description: 'Review the diff across dimensions, verify each finding',
  phases: [{ title: 'Review' }, { title: 'Verify' }],
}

const DIMENSIONS = [
  { key: 'bugs', prompt: 'Find correctness bugs in the current diff.' },
  { key: 'perf', prompt: 'Find performance regressions in the current diff.' },
]

const results = await pipeline(
  DIMENSIONS,
  (d) => agent(d.prompt, { phase: 'Review', schema: FINDINGS }),
  (review) =>
    parallel(
      review.findings.map(
        (f) => () =>
          agent(`Try to refute this finding. Default to refuted if unsure: ${f.title}`, {
            phase: 'Verify',
            schema: VERDICT,
          }).then((v) => ({ ...f, verdict: v })),
      ),
    ),
)

const confirmed = results
  .flat()
  .filter(Boolean)
  .filter((f) => f.verdict?.real)
return { confirmed }

Dat is een echte workflow. pipeline() is de standaard omdat er geen barrière in zit. parallel() is wél een barrière: hij wacht op alles voordat hij teruggeeft, en dat wil je alleen als een latere fase echt alle eerdere resultaten tegelijk nodig heeft, bijvoorbeeld om over de hele set te ontdubbelen. De optie schema dwingt elke agent om gevalideerde, gestructureerde data terug te geven in plaats van proza dat je zelf moet uitpluizen. Het geheel draait op de achtergrond en geeft je confirmed terug.

Twee dimensies, met elk een verificateur. Dat zijn zes agents. Nuttig, begrensd, en het kost je een paar cent.

Kijk nu wat er gebeurt als de begrenzing eraf gaat.

Het stuk dat niemand narekent ​

Dit is Anthropics eigen waarschuwing, in de docs, in gewone taal: Dynamic Workflows "can consume substantially more tokens than a typical Claude Code session." Begin klein, zeggen ze. Eerst goed afgebakende taken.

Dat is geen valse bescheidenheid. Het mechanisme is keihard en het is geen bug. Elke subagent draait in zijn eigen verse context. Hij erft de tokens van de ouder niet. Dus de context wordt opnieuw verstuurd, per agent, elke keer. Drie parallelle workers verviervoudigen je verbruik ruwweg ten opzichte van serieel werken. Schaal dat nu op naar honderd.

De horrorverhalen staan al online. Eén developer draaide een slash-commando dat 49 subagents tweeënhalf uur parallel liet werken: geschat op acht- tot vijftienduizend dollar voor één sessie. Een team uit de financiële dienstverlening liet 23 subagents onbeheerd code analyseren en kwam uit op zevenenveertigduizend dollar over drie dagen.

En dan de stille standaardinstelling die een fan-out laat ontsporen: elke worker erft het model van de hoofdsessie, en dat is voor de meeste mensen Opus. Opus kost vijf dollar per miljoen invoertokens en vijfentwintig per miljoen uitvoer. Haiku is een vijfde daarvan. Dus je hebt honderd workers die Opus-prijzen betalen voor grep-achtig werk dat Haiku voor een schijntje afmaakt. Niemand heeft dat gekozen. Het gebeurt gewoon als je het model niet per agent instelt.

Dit is de token-bespaartaks omgekeerd. Daar lag de rekening al op de mat, voordat er werk was gedaan. Hier komt de rekening tijdens het werk, en hij schaalt mee met hoe lui je naar de fan-out grijpt. Zelfde les, andere kant: de kosten die je ziet zijn zelden waar de kosten echt zitten.

Snelheid, efficiëntie, kwaliteit: kies de afweging bewust ​

De fan-out wint je tijd. Dat is de hele belofte, en het is een eerlijke. De traagste enkele keten is klaar en jij bent klaar, in plaats van honderd taken op een rij af te wachten.

Maar doorlooptijd is niet de enige as, en doen alsof dat zo is, is de nieuwe cargocult.

Let op die kwaliteitsregel, want die wordt overschat. Meer agents geven je niet meer juistheid. Ze geven je meer plausibele output, sneller, met een verificatielaag die een deel van de overduidelijke fouten vangt. Die onafhankelijke sceptici zijn echt nuttig. Maar de overlevers belanden alsnog op je bureau, en je moet nog steeds elke diff lezen alsof je hem zelf schreef. Duizend agents veranderen daar niets aan. Ze produceren de reviewstapel alleen sneller dan jij hem kunt wegwerken.

De flessenhals is nooit weggegaan. Hij is verschoven. Vroeger was het "kan de tool dit." Nu kan de tool bijna alles wat je kunt beschrijven, en de echte beperking is of jij nog kunt begrijpen en beoordelen wat hij teruggaf, en of je dat nog steeds tegen dezelfde norm houdt als een uur geleden. Fan-out is een doorvoervermenigvuldiger op een stap die nooit jouw doorvoerprobleem was.

Wat je echt moet doen ​

• Baken de fan-out af voordat je ernaar grijpt. Een review op twee dimensies heeft zes agents nodig, geen zestig. Anthropics eigen advies voor agent teams zegt: begin met drie tot vijf, en "three focused teammates often outperform five scattered ones." Geloof ze. De meeropbrengst neemt snel af.
• Stel het model per fase in. Planner op Opus, workers op Haiku of Sonnet. Dat is één regel per agent en het is de grootste hefboom op je rekening. Controleer meteen CLAUDE_CODE_SUBAGENT_MODEL, want die overschrijft je routering stilletjes.
• Pipeline boven barrière. Gebruik parallel() alleen als een fase echt alle eerdere resultaten tegelijk nodig heeft. Anders verspilt de barrière de tijd van de snelle workers, die op de trage staan te wachten.
• Verifieer adversarieel, maar in verhouding. Drie sceptici op een echte architectuurclaim, prima. Een stemming met vijf op een typefout is theater waar je Opus voor betaalt.
• Kijk naar de meter, niet naar de klok. Als een taak goedkoop serieel te draaien is en je het antwoord niet binnen vijf minuten nodig hebt, draai hem dan serieel. Tokenmaxxing meet het verkeerde als het resultaat is waar je echt om geeft.

Dynamic Workflows zijn een goede tool, en ik blijf ze gebruiken voor het werk waar ze bij passen: breed onderzoek, grote audits, migraties die te groot zijn voor één context. Dat is echt werk. Daar verdient de fan-out zijn rekening terug.

Het plafond van wat de tool kan, is nauwelijks verschoven, en dat plafond was nooit het probleem. Wat veranderde, is dat snelheid nu goedkoop is en je oordeel nog steeds niet. De tool spendeert met liefde duizend agents aan een vraag die er zes nodig had. Bepalen welke van de twee het was, dat is het werk. Dat was het altijd al.