1.000 subagents tegelijk: wat Dynamic Workflows betekent voor verouderde software.

Dynamic Workflows verscheen op 28 mei als research preview in Claude Code, het programmeergereedschap van Anthropic. Het idee: in plaats van dat een mens het werk in stukken hakt en aan losse AI-agents uitdeelt, schrijft Claude zelf de orkestratiescripts en stuurt daarmee tot 1.000 parallelle subagents in één sessie aan.

Het is geen laboratoriumdemonstratie die je niet kunt aanraken. De functie is beschikbaar op alle betaalde Claude Code-abonnementen en staat op de zwaardere plannen standaard aan.

Als bewijs portte Bun, een bekende JavaScript-runtime, zijn codebasis van de programmeertaal Zig naar Rust: circa 750.000 regels code, waarbij 99,8 procent van de bestaande testsuite slaagde. Er zaten elf dagen tussen de eerste commit en de merge.

Om dat te ijken: een migratie van die omvang was tot voor kort een meerjarenproject waar je een gespecialiseerd bureau voor inhuurde, met een stuurgroep, een risicoparagraaf en een einddatum waar niemand in geloofde. Dat zo'n traject nu in dagen wordt geteld, is de eigenlijke aankondiging.

Eén detail verdient een markering: die 99,8 procent kon alleen gemeten worden omdat Bun een uitgebreide testsuite hád. Het vangnet bestond al voordat de agents begonnen. Onthoud dat, want daar komt het MKB-verhaal zo op terug.

Veel MKB-bedrijven draaien op software waar niemand meer aan durft te komen. Het maatwerkpakket uit 2012, de database van een vertrokken medewerker, de koppeling die alleen de vorige IT-er begreep. De strategie heet doormodderen, en die is nooit gekozen omdat hij goed is; hij is gekozen omdat herbouwen onbetaalbaar was.

Die rekensom verschuift nu. Als 750.000 regels in elf dagen kan, is de vraag bij een pakket van een paar tienduizend regels niet langer of herbouwen haalbaar wordt, maar wat je precies terug wilt hebben. En dat is een procesvraag, geen AI-vraag: welke stappen doet dat oude systeem, welke daarvan zijn ooit om een goede reden zo gebouwd, en welke sleep je al tien jaar mee omdat niemand ze durfde te schrappen.

Wie zijn huidige systeem klakkeloos laat migreren, krijgt dezelfde rommel terug in een nieuwe taal, sneller opgeleverd dan ooit. Begin dus bij het proces, niet bij de tool; dat geldt bij een migratie van elf dagen net zo hard als bij een traject van drie jaar.

Nuchterheid hoort erbij: dit is een research preview, en Bun is geen doorsnee bedrijf. Daar werken mensen die hun software volledig onder versiebeheer hebben en een testsuite onderhouden die goed genoeg is om 99,8 procent op te meten. De gemiddelde verouderde MKB-applicatie heeft geen van beide.

Precies daarom is het huiswerk nu al duidelijk. Documenteer wat het oude systeem werkelijk doet, leg vast welke uitkomsten goed zijn, en bepaal wat er bij een herbouw uit mag. Dat is het vangnet dat Bun al had en jij waarschijnlijk nog niet, en het is nodig bij elke migratie, wie of wat hem straks ook uitvoert. Bedrijven die dat voorwerk op orde hebben, kunnen instappen zodra dit gereedschap volwassen is. Wie het niet heeft, kan straks alleen kiezen tussen doormodderen en een herbouw waarvan niemand kan aantonen of hij goed is gegaan.