In het VM0 dev team werkt elke ontwikkelaar met meerdere Claude Code-instanties tegelijk. Meestal meer dan acht.
We behandelen Claude Code op dezelfde manier als een echte ontwikkelaar. (Ja, ons bedrijf heet half-grappend AI Colleagues Co!)
Daarom weerspiegelt de ontwerpfilosofie achter de VM0 dev workflow klassieke teammanagementpraktijken uit de software engineering.
We gebruiken GitHub Issues om werk te volgen, Pull Requests voor code review en samenvoegen, en GitHub Actions voor automatisering. Over twee maanden hielp deze opzet ons om 404 releases te leveren en meer dan 230.000 regels code te schrijven.
Dit artikel legt uit hoe we dat werkbaar maakten, en waarom het kernprobleem nooit AI-capaciteit was, maar menselijke coördinatie.
AI-gedreven dev workflow in de praktijk
Wanneer je veel AI-agenten parallel coördineert, is de bottleneck niet of het model code kan schrijven. De echte bottleneck is menselijke cognitieve belasting.
Deze workflow bestaat uit 14 slash-commando's, georganiseerd in drie lagen: Deep Dive, Issue Management en PR Management.
Laten we eerst kijken hoe mijn workflow eruitziet en hoe een feature meestal wordt gebouwd.
-
Vereisten afstemmen
Een mens start een Claude-sessie en begint met
/deep-research. Claude verzamelt feiten uit de codebase, documentatie en relevante context. We bespreken de bevindingen en stemmen af welk probleem we daadwerkelijk oplossen. -
Oplossingen verkennen
Met
/deep-innovatestelt Claude verschillende mogelijke richtingen voor, met afwegingen. We bespreken, verfijnen en kiezen een richting. -
Issue aanmaken
We maken een GitHub issue aan met
/issue-create. De mens controleert of de vereisten duidelijk zijn vastgelegd. -
Plannen en goedkeuren
Gebruik
/issue-planom Claude het werk te laten voortzetten. Claude voert automatisch de volledige deep-dive workflow uit en plaatst de resultaten bij het issue, waaronder:- bevindingen uit
/deep-research - vergelijkingen uit
/deep-innovate - een concreet implementatieplan uit
/deep-plan
- bevindingen uit
-
Implementatie
Na goedkeuring laat
/issue-actionClaude het plan uitvoeren, tests schrijven, een PR openen en zorgen dat CI slaagt. -
Review en samenvoegen
We gebruiken
/pr-reviewvoor een gestructureerde review, gevolgd door een laatste menselijke beoordeling voor het samenvoegen.De mens grijpt in op drie controlepunten: vereisten, richting en acceptatie. Alles daartussen verloopt autonoom.
Mindset shift: je leidt een team van AI-ontwikkelaars
Het moment dat ik besefte dat we een gestructureerde workflow nodig hadden, was toen meer Claude-sessies de situatie juist verslechterden. Hoe meer instanties ik parallel draaide, hoe moeilijker het werd om bij te houden wat elke instantie deed, in welke staat het werk was en wat al was besloten.
Zonder externe tools kon ik simpelweg niet zoveel Claude-instanties tegelijk beheren. Toen viel het kwartje: dit was geen AI-probleem, maar een managementprobleem.
GitHub is al het natuurlijke hulpmiddel voor samenwerking in softwareontwikkeling, dus in plaats van iets nieuws te verzinnen, begon ik Claude te behandelen als een menselijke teamgenoot. Toen ik dat deed, schaalde mijn managementcapaciteit ineens mee.
Tien jaar ervaring met project- en teammanagement kreeg eindelijk betekenis in deze nieuwe context. Door Claude als teamlid te behandelen en GitHub als onze gedeelde communicatie- en managementruimte, werd het hele systeem weer beheersbaar.
Een goede teamleider weet wanneer hij moet ingrijpen en wanneer hij moet loslaten:
| Controlepunt | Wat ik doe | Wat AI doet |
|---|---|---|
| Vereisten | Probleem afstemmen, scope verduidelijken | Codebase onderzoeken, context verzamelen |
| Richting | Bevindingen beoordelen, aanpak goedkeuren | 2-3 aanpakken voorstellen, afwegingen evalueren |
| Acceptatie | PR beoordelen, kwaliteit verifiëren | Implementeren, testen, CI oplossen |
Dit weerspiegelt hoe effectieve softwareteams werken. Ik micromanage geen ontwikkelaars, maar stel duidelijke vereisten, beoordeel belangrijke beslissingen en verifieer het eindresultaat. Hetzelfde principe geldt bij het beheren van AI-agenten.
De deep dive flow dwingt gestructureerd, langzaam denken af
De deep dive workflow dwingt tot bewust nadenken vóór implementatie. Soms loopt Claude vast. Dan laten we Claude stoppen en nadenken, en bespreken we het samen. Het bestaat uit drie fasen:
| Fase | Commando | Doel | Output |
|---|---|---|---|
| Onderzoek | /deep-research | Feiten verzamelen, context begrijpen | research.md |
| Innoveren | /deep-innovation | Meerdere aanpakken verkennen | innovate.md |
| Plannen | /deep-plan | Concrete stappen definiëren | plan.md |
Elke fase heeft strikte grenzen.
- Onderzoek: geen suggesties
- Innoveren: geen details
- Plannen: geen implementatie
Deze beperkingen dwingen Claude tot langzaam, bewust redeneren in plaats van direct naar code te springen. Zonder deze stappen worden edge cases en architecturale kwesties vaak gemist!
Gebruiksvoorbeeld
/deep-research investigate the authentication flow, I'm seeing token expiration issues
[Claude researches, analyzes 12 related files, finds 3 similar patterns]
/deep-innovate what are our options for fixing this?
[Claude presents 3 approaches with trade-offs, you pick one]
/issue-create let's track this fix
Voor eenvoudige taken kun je de deep dive overslaan en direct naar /issue-create gaan.
Voor complexe taken met technische onzekerheid zorgen de deep dive-fasen ervoor dat jij en Claude op één lijn zitten voordat de implementatie begint.
Gebruik GitHub als gedeeld geheugen
De meeste AI-tools behandelen context als tijdelijk. Als de sessie eindigt, verdwijnt het geheugen.
VM0 gebruikt GitHub als permanent geheugen:
| GitHub-functie | Wat wordt opgeslagen |
|---|---|
| Issue body | Vereisten en beslissingen |
| Issue comments | Onderzoek, opties, plannen |
| PR comments | Reviews en samenvattingen |
| Labels | Workflowstatus |
Dit lost ook een menselijk probleem op: contextherstel.
Als ik 8+ Claude-instanties beheer, krijg ik meldingen dat werk klaar is. Maar ik kan uit het gesprek met Claude niet reconstrueren wat het deed, welke beslissingen zijn genomen of wat de huidige status is.
GitHub issues lossen dit op. Elk issue toont:
- De oorspronkelijke vereisten
- Onderzoeksbevindingen (wat is ontdekt)
- Innovatiefase (welke opties zijn overwogen)
- Het goedgekeurde plan (wat wordt geïmplementeerd)
Dit gestructureerde format maakt review efficiënt. Zo kan ik snel de fasen scannen, de aanpak begrijpen en goedkeuren of wijzigingen vragen, zonder het oorspronkelijke gesprek te hoeven onthouden.
Als het werk klaar is, hoef ik niet te onthouden wat er in een chatvenster is gebeurd. Ik open het issue en zie het volledige verhaal, gestructureerd en vastgelegd.
Overdracht tussen agenten
Omdat alle context in GitHub leeft, kan werk naadloos tussen agenten worden overgedragen:
- De ene agent maakt een issue of PR aan
- Een andere gaat later verder met
/deep-research issue 123of/issue-plan 123of/deep-research PR 124
Voor lange discussies consolideert /issue-compact alles tot een overzichtelijke issue body. Dit maakt overdracht eenvoudig voor zowel mensen als AI.
Laten we de workflowpatronen samenvatten
Na dit alles vat ik graag een paar praktische tips samen.
Eenvoudige taken
/issue-create → /issue-plan → /issue-action → /pr-check-and-merge
Gebruik dit als de vereisten duidelijk zijn en het werk rechttoe rechtaan is.
Complexe taken
/deep-research → discussion → /deep-innovate → discussion →
/issue-create → /issue-plan → /issue-action →
/pr-review → /pr-check
Dit voorkomt verspilde moeite aan de verkeerde aanpak.
Parallel werken
Meerdere agenten kunnen tegelijk werken terwijl de mens voltooide controlepunten beoordeelt. Hier schaalt de workflow het beste.
Agent 1: /issue-plan #123
Agent 2: /issue-plan #124
Agent 3: /pr-review #100
Agent 4: /deep-research new feature requirements
Commandoreferentie
Deep dive-commando's
| Commando | Doel |
|---|---|
/deep-research | Informatie verzamelen, codebase begrijpen. Geen suggesties toegestaan. |
/deep-innovate | 2-3 aanpakken verkennen, afwegingen evalueren. Geen code toegestaan. |
/deep-plan | Concrete implementatiestappen maken. Geen implementatie toegestaan. |
Issue-commando's
| Commando | Doel |
|---|---|
/issue-create | Issue aanmaken vanuit gesprekscontext |
/issue-bug | Bugrapport aanmaken met reproduceerbare stappen |
/issue-feature | Feature request aanmaken gericht op vereisten |
/issue-plan | Volledige deep-dive workflow uitvoeren, resultaten bij issue plaatsen |
/issue-action | Implementatie voortzetten na menselijke goedkeuring |
/issue-compact | Issue body + opmerkingen consolideren voor overdracht |
PR-commando's
| Commando | Doel |
|---|---|
/pr-check | CI-pijplijn monitoren, automatisch oplossen, tot 3x opnieuw proberen |
/pr-review | PR commit-voor-commit beoordelen op projectstandaarden |
/pr-comment | Gespreksdiscussie samenvatten naar PR-opmerking |
Aan de slag
- Begin eenvoudig: Gebruik
/issue-create→/issue-plan→/issue-actionvoor je eerste taak - Voeg deep dive toe voor complexe taken: Als vereisten onduidelijk of technisch complex zijn, begin met
/deep-research - Schaal geleidelijk op: Voeg meer Claude-instanties toe naarmate je vertrouwd raakt met het reviewritme
- Vertrouw op het proces: Laat Claude autonoom werken tussen controlepunten
De workflow is ontworpen om stapsgewijs te worden ingevoerd. Je hoeft niet alle 14 commando's vanaf dag één te gebruiken. Begin met de basis issue flow, voeg daarna deep dive-fasen en parallel werk toe naarmate je meer vertrouwen krijgt.
Schaaloverwegingen: Wat te doen als je meer agenten hebt
De workflow is getest met 10+ gelijktijdige Claude-instanties. Onze aanbeveling:
- Tot 10 agenten: Comfortabel voor diepe samenwerking met elk
- Meer dan 10: Niet aanbevolen
De beperkende factor is niet de workflow, maar menselijke aandacht en besluitvorming. Bij meer dan 10 agenten loop je het risico een bottleneck te worden bij reviewmomenten, en gaat de besluitkwaliteit achteruit.
Het klassieke "two pizza team"-principe geldt hier. Dezelfde beperkingen die de grootte van menselijke teams beperken, bepalen ook hoeveel AI-agenten één persoon effectief kan aansturen.
Ik onderzoek momenteel een 8×8 tweelaags teamstructuur om verder te schalen dan 10 agenten, maar heb nog geen effectieve werkwijzen ontwikkeld. Ik deel meer zodra er concrete resultaten zijn…
De VM0 dev workflow verandert hoe we over softwareontwikkeling denken wanneer AI deel uitmaakt van het team.
Als je AI-agenten als teamleden behandelt in plaats van als tools, valt alles op zijn plek. GitHub wordt het gedeelde geheugen van je team. Issues worden werkitems. PR's worden opleveringen. En jij wordt de teamleider, gericht op architectuur, richting en kwaliteit terwijl je AI-team de implementatie verzorgt.
Zo leverden wij 404 releases in 2 maanden op. En zo kun jij je eigen ontwikkeling met AI opschalen.
