De Claude Code-workflow die mijn team overbodig maakte

De Claude Code-workflow die mijn team overbodig maakte

Zes weken geleden zag ik een senior engineer een compleet authenticatiesysteem, een betalingsintegratie en een dashboard-redesign opleveren — allemaal op één middag. Geen prototypes. Geen wegwerp-demo’s. Productiecode met tests, typeveiligheid en een schone Git-geschiedenis. Ze had drie Claude Code-sessies tegelijk draaien, elk in een eigen worktree, elk verantwoordelijk voor een andere feature terwijl ze pull requests van de vorige batch reviewde.

Ik vroeg haar hoe lang het duurde om deze workflow op te bouwen. “Ongeveer een week gericht oefenen,” zei ze. “Maar het echte antwoord is dat ik Claude niet meer als een chatbot benaderde, maar als een junior engineer die structuur nodig heeft om optimaal te presteren.”

Die benadering bleef hangen. Ik gebruikte Claude Code op dat moment al maanden — projecten opleveren, agent-systemen bouwen, er constant over schrijven. Maar mijn workflow was nog steeds vooral reactief. Prompt, genereren, reviewen, fixen, opnieuw prompten. Die cyclus werkte, maar liet enorm veel productiviteit liggen.

Toen kwam ik Maddy’s analyse tegen. Maddy is een senior software engineer die bij Google, Amazon, IBM en Microsoft heeft gewerkt — niet iemand die snel in hypes gelooft. Haar aanpak van Claude Code draait niet om slimme prompts of verborgen features. Het is een complete methodologie: negen onderling verbonden praktijken die Claude transformeren van een codegenererende chatbot tot iets dat functioneert als een autonoom engineeringteam. De afgelopen maand heb ik elk onderdeel geïmplementeerd, en de resultaten dwongen me om opnieuw na te denken over hoe ik elk project structureer.

Hier is het systeem, stap voor stap, met alles wat ik heb geleerd tijdens het toepassen in de praktijk.

Waarom De Meeste Ontwikkelaars Tegen Een Plafond Aanlopen Met Claude Code

Er is een patroon dat ik keer op keer zie in ontwikkelaarsgemeenschappen, zo consequent dat het wel een natuurwet lijkt. Iemand ontdekt Claude Code. Ze genereren een paar componenten, voelen de adrenaline van AI-ondersteunde ontwikkeling en beginnen iedereen te vertellen dat dit de toekomst is. Twee weken later zijn ze gefrustreerd. Bugs stapelen zich op. De AI stelt functies voor die niet bestaan. Contextvensters raken overvol en Claude begint zichzelf tegen te spreken.

De standaardreactie is om het model de schuld te geven. "Het is niet slim genoeg voor echte projecten" of "het werkt voor simpele voorbeelden, maar niet voor productiecode." Ik heb beide dingen op verschillende momenten zelf gezegd.

Het werkelijke probleem is bijna nooit het model. Het is het ontbreken van structuur rondom het model.

Denk er eens zo over: als je de meest getalenteerde junior engineer ter wereld zou aannemen en hem of haar geen enkele onboarding zou geven, geen coding standards, geen reviewproces en geen test suite — dan krijg je chaos. Niet omdat ze geen vaardigheden hebben, maar omdat vaardigheid zonder structuur tot inconsistente resultaten leidt. Met Claude Code is het precies hetzelfde. De ruwe intelligentie is buitengewoon. Maar intelligentie zonder workflow leidt tot exact de symptomen waar ontwikkelaars over klagen: niet-uitgelijnde implementaties, toenemende bugaantallen en het sluipende gevoel dat je meer tijd kwijt bent aan het corrigeren van AI-output dan je kwijt zou zijn aan het zelf schrijven van de code.

Maddy’s methodologie lost dit op door Claude Code te omringen met hetzelfde soort engineeringdiscipline die je op een menselijk team zou toepassen. Elke stap bestaat om een specifiek faalpatroon te voorkomen dat ik persoonlijk heb meegemaakt. En het gecombineerde effect — alle negen praktijken samen — is wat zorgt voor die “dit kan niet echt zijn”-productiviteitswinst die als marketing klinkt tot je het zelf ervaart.

Het addertje? Je moet ze bewust implementeren. Stappen overslaan vermindert niet alleen het voordeel — het ondermijnt het hele systeem. Ik heb dat op de harde manier geleerd toen ik probeerde de planmodus over te slaan voor “simpele” taken en uiteindelijk drie uur bezig was met debuggen van iets wat een kwartier had moeten kosten.

Stap 1: Bouw een CLAUDE.md die écht werkt

Elke gestructureerde Claude Code-workflow begint met CLAUDE.md, en Maddy’s aanpak van dit bestand is veel gedisciplineerder dan wat ik doorgaans zie.

Wanneer je /init uitvoert op een nieuwe codebase, voert Claude een structurele analyse uit en genereert dit bestand automatisch. Het bevat je projectbeschrijving, de bestandsstructuur, sleutelroutes, ontwikkelcommando’s, codeerconventies en tech stack. De automatisch gegenereerde versie is een uitstekend startpunt — veel beter dan alles zelf schrijven, wat ik vroeger deed voordat ik accepteerde dat Claude’s zelfanalyse details oppikt die ik zou vergeten.

Maar hier wijkt Maddy af van het standaardadvies: zij houdt CLAUDE.md tussen de 100 en 200 regels. Geen 300. Geen 500. Honderd tot tweehonderd.

Die beperking vond ik aanvankelijk streng. Mijn eigen CLAUDE.md-bestanden groeiden bij sommige projecten uit tot meer dan 400 regels — architectuurbeslissingen, codeerpatronen, voorbeeldsnippets, historische context. Het voelde grondig. In werkelijkheid was het verspilling. Elke token in CLAUDE.md wordt in elk gesprek opnieuw geladen. Een bestand van 500 regels slokt ongemerkt een aanzienlijk deel van je context window op, nog voordat je je eerste prompt hebt getypt. Ik heb dit uitgebreid behandeld in mijn 50 Claude Code tips guide, maar de korte versie is: opgeblazen contextbestanden zijn een van de belangrijkste redenen waarom de outputkwaliteit van Claude halverwege een sessie afneemt.

Wat thuishoort in het bestand: projectbeschrijving en kernfunctionaliteit, bestandsstructuur en sleutelroutes, build-/test-/lint-commando’s (zodat Claude zijn eigen werk kan valideren), codeerconventies en tech stack, en harde regels die Claude nooit mag overtreden. Wat er niet in thuishoort: codevoorbeelden (Claude kan je daadwerkelijke codebase lezen), lange uitleg over eerdere beslissingen, alles wat je README dupliceert, en alles wat de afgelopen twee weken niet relevant is geweest.

De beperking van 100-200 regels dwingt je om te prioriteren. Elke regel moet zijn plek verdienen. En die compromisloze prioritering is precies wat het context window efficiënt genoeg maakt voor de rest van deze workflow.

Nog iets wat Maddy benadrukt en wat ik nu religieus toepas: behandel CLAUDE.md als een levend document. Wanneer Claude een fout maakt en jij die corrigeert, voeg dan een regel toe die voorkomt dat die fout opnieuw gebeurt. Na verloop van tijd wordt het bestand een gedestilleerd verslag van elke les die jouw project de AI heeft geleerd. Boris Cherny, de bedenker van Claude Code, doet precies dit met een lessons.md-bestand — elke correctie wordt een permanente regel. Het bestand leert zichzelf letterlijk beter te worden in jouw specifieke codebase.

Stap 2: Planmodus vóór elke wijziging

Dit is de meest impactvolle praktijk in Maddy’s hele workflow, en precies degene die de meeste ontwikkelaars overslaan omdat het voelt alsof het hen vertraagt.

Planmodus (in te schakelen met Shift+Tab in de CLI) instrueert Claude om je codebase te analyseren en een implementatieplan op te stellen voordat er ook maar één regel code wordt geschreven. Claude bekijkt welke bestanden aangepast moeten worden, welke logische paden beïnvloed worden, waar de risico’s liggen en hoe de wijziging past binnen de bestaande architectuur. Je krijgt een helder overzicht van wat Claude van plan is te doen — en, cruciaal, jij kunt dat plan goedkeuren, aanpassen of afwijzen voordat er iets daadwerkelijk verandert.

De praktische grens die ik hanteer: gebruik planmodus voor elke taak die meer dan één bestand raakt. Voor een wijziging in één bestand — een variabele hernoemen, een typefout herstellen, een commentaar toevoegen — laat ik Claude direct uitvoeren. Voor alles wat structureel is: eerst plannen.

Waarom dit in de praktijk zo belangrijk is? Zonder planmodus schrijft Claude soms perfect werkende code op totaal de verkeerde plek. Ik vroeg hem ooit om rate limiting toe te voegen aan een API en hij maakte een nieuw middleware-bestand aan, in plaats van het bestaande bestand uit te breiden dat al authenticatie afhandelde. De code klopte. De architectuur niet. Ik ontdekte het pas drie features later, toen ik merkte dat er twee middleware-ketens onafhankelijk van elkaar draaiden.

Met planmodus had ik in het plan direct gezien: “Nieuw bestand aanmaken: middleware/rateLimiter.js” en had ik het meteen gecorrigeerd naar “Bestaand bestand aanpassen: middleware/auth.js — rate limiting-logica toevoegen.” Tien seconden review bespaarden me drie uur refactoren.

De plan-review-uitvoercyclus die Maddy aanbeveelt — en die ik inmiddels als ononderhandelbaar beschouw — ziet er zo uit:

1. Beschrijf de taak in detail (hoe specifieker, hoe beter)
2. Zet planmodus aan en laat Claude de codebase analyseren
3. Review het plan: corrigeer bestandsnamen, bevraag architecturale keuzes, voeg beperkingen toe
4. Keur het plan goed en laat Claude uitvoeren
5. Vergelijk het resultaat met het oorspronkelijke plan

Sommige engineers gaan nog verder. Ik heb workflows gezien waarbij één Claude-sessie het plan opstelt, en een tweede sessie het plan “als senior engineer” reviewt voordat de uitvoering start. Ik probeerde dit bij een complexe databasemigratie en de review-sessie ontdekte twee edge cases die de planningsessie had gemist. Overkill voor de meeste taken. Onmisbaar voor alles wat productiegegevens raakt.

Stap 3: Wis de context na elke taak

Dit klinkt bijna te eenvoudig om belangrijk te zijn. Maar dat is het niet. Het is misschien wel de meest onderschatte praktijk in de hele workflow.

Na het afronden van elke afzonderlijke taak, voer je /clear uit om het contextvenster van Claude te resetten. Elk bestand dat Claude leest, elke uitvoer van een commando die hij verwerkt, elk bericht in het gesprek — alles stapelt zich op in een gedeeld contextbudget. Wanneer dat budget vol is, raakt Claude het overzicht over eerdere instructies kwijt. De symptomen zijn in het begin subtiel: iets minder nauwkeurige code, af en toe inconsistenties met je codestandaarden, suggesties die net niet aansluiten bij wat je hebt gevraagd. Vervolgens stapelen deze zich op, totdat je AI-uitvoer aan het debuggen bent die zichzelf tegenspreekt met suggesties van twintig minuten geleden.

Vroeger zag ik /clear als iets wat je doet als er iets misgaat. Maddy behandelt het als hygiëne — iets wat je doet na elke succesvolle taak, voordat er iets misgaat. Het verschil is preventief versus reactief, en de preventieve aanpak is aanzienlijk efficiënter.

De workflow wordt: taak afronden, controleren of het werkt, committen, en dan /clear uitvoeren voordat je aan de volgende taak begint. Een schone lei. Het volledige contextbudget is beschikbaar voor het volgende probleem. Geen opgehoopte ruis uit het vorige gesprek.

Een praktische overweging: als je volgende taak sterk afhankelijk is van de context van de huidige, kun je de essentiële details meenemen in je volgende prompt in plaats van erop te vertrouwen dat Claude ze onthoudt. "Ik heb zojuist rate limiting toegevoegd aan de auth middleware. Nu moet ik bijbehorende tests toevoegen voor het rate limiting gedrag" geeft Claude precies de context die nodig is, zonder de ballast van alles wat er in de vorige sessie is gebeurd.

Deze praktijk alleen al heeft ongeveer 40% van de momenten waarop "Claude zich vreemd gedraagt" geëlimineerd. En het sluit perfect aan bij planmodus — je begint elke taak altijd met een heldere context en een doordacht plan, in plaats van voort te bouwen op opgehoopte ruis.

Stap 4: Slash-commando’s voor repetitieve prompts

Elke ontwikkelaar heeft prompts die hij keer op keer typt. “Review deze code op beveiligingslekken.” “Schrijf unittests voor deze functie.” “Refactor dit volgens het repository-patroon.” Dit steeds opnieuw typen is niet alleen saai — het zorgt ook voor variatie. Je prompt voor code review op donderdag zal niet exact hetzelfde geformuleerd zijn als die op maandag, en die variatie levert verschillende (vaak slechtere) resultaten op.

Slash-commando’s lossen dit op door je beste prompts om te zetten in herbruikbare triggers. Het zijn Markdown-bestanden die opgeslagen worden in .claude/commands/ (of .claude/skills/ — sinds begin 2026 zijn deze in de praktijk samengevoegd) en die Claude uitvoert wanneer je het bijbehorende slash-commando intypt.

Hier is een praktisch voorbeeld. Ik heb een commando genaamd /security-review dat een gedetailleerde prompt bevat die ik heb verfijnd over tientallen iteraties:

# Security Review

Review de huidige wijzigingen op beveiligingslekken. Controleer op:

1. SQL-injectievectoren in databasequeries
2. XSS-kwetsbaarheden in gerenderde output
3. Mogelijkheden tot omzeiling van authenticatie/autorisatie
4. Blootstelling van gevoelige data in logs of foutmeldingen
5. CSRF-bescherming op endpoints die de status wijzigen
6. Gebrek aan inputvalidatie bij door gebruikers aangeleverde data

Voor elk gevonden probleem:
- Classificeer de ernst (Kritiek / Hoog / Medium / Laag)
- Toon de kwetsbare code
- Geef de verbeterde versie
- Leg de aanvalsvector uit

Als er geen problemen gevonden zijn, bevestig dan dat de code de review doorstaat met een korte samenvatting.

In plaats van elke keer alle zes de controlepunten te moeten onthouden, typ ik nu /security-review en krijg ik consistente, grondige resultaten. De prompt is beproefd. De output is betrouwbaar. En ik bespaar de drie minuten die ik anders kwijt zou zijn aan het uit mijn hoofd samenstellen van de instructie.

Maddy raadt aan om slash-commando’s te maken voor elke prompt die je meer dan drie keer hebt getypt. Ik zou zelfs verder gaan — maak ze voor elke prompt waarbij consistentie belangrijker is dan creativiteit. Code review, testgeneratie, documentatie-updates, API-endpoint scaffolding, database-migratieplanning. Dit zijn workflows waarbij je elke keer voorspelbare, hoogwaardige output wilt.

De commando’s zijn gewoon Markdown-bestanden, dus ze zijn versiebeheerbaar. Je kunt ze delen met je team. Je kunt ze in de loop van de tijd verbeteren — en elke verbetering komt elke toekomstige uitvoering ten goede. Ik onderhoud ongeveer vijftien actieve slash-commando’s verspreid over mijn projecten. De drie die ik het vaakst gebruik besparen me waarschijnlijk dertig minuten per dag.

Stap 5: Validatiehooks waarmee Claude zichzelf corrigeert

Hier verschuift de workflow van “gestructureerd prompten” naar iets dat echt aanvoelt als werken met een autonome engineer.

Validatiehooks zijn geautomatiseerde controles die na elke wijziging van Claude worden uitgevoerd. Bouw het project. Draai de test suite. Voer de typechecker uit. Als er iets faalt, ziet Claude de foutmelding en probeert het automatisch te herstellen — zonder dat jij hoeft in te grijpen. De AI komt in een zelfcorrigerende lus: bewerken, valideren, falen zien, oplossen, opnieuw valideren, herhalen tot alles slaagt.

Dit is de functie die Maddy aanwijst als de grootste enkele kwaliteitsverbetering in haar workflow. En Boris Cherny, de bedenker van Claude Code, stelt dat Claude een feedbackloop geven de uiteindelijke outputkwaliteit twee tot drie keer verbetert ten opzichte van gewoon genereren-en-bidden.

Hooks instellen in je Claude Code-configuratie ziet er zo uit:

{
  "hooks": {
    "postEdit": [
      "npm run build",
      "npm run test",
      "npm run typecheck"
    ]
  }
}

Elke keer dat Claude een bestand wijzigt, worden deze drie commando’s automatisch uitgevoerd. Als de build faalt, ziet Claude de fout. Als een test faalt, ziet Claude welke bewering niet slaagde en waarom. Als de typechecker een incompatibel type vindt, ziet Claude het exacte bestand en de regel.

Het belangrijkste inzicht: zonder hooks controleert Claude zijn werk met zijn eigen oordeel. Dat klinkt redelijk, tot je je realiseert dat Claude’s beoordelingsvermogen afneemt naarmate de context volloopt. Tests en buildchecks zijn een externe bron van waarheid die accuraat blijft, ongeacht de contextdruk. Elke rood-naar-groen-cyclus geeft Claude ondubbelzinnige, machine-gevalideerde feedback waar hij direct op kan handelen, zonder op jou te wachten.

Ik wil eerlijk zijn over de beperkingen hiervan. Hooks voegen tijd toe aan elke bewerkingscyclus. Als je test suite 90 seconden duurt, betekent dat 90 seconden wachten na elke wijziging. Voor snelle iteratie op UI-componenten, waarbij de feedback visueel is, schakel ik hooks soms tijdelijk uit. Maar voor alles wat businesslogica, API-endpoints of datamodellen raakt — blijven hooks aan. De tijd die ze kosten is een fractie van de debugtijd die ze besparen.

Nog een nuance die Maddy benadrukt en die ik in de praktijk heb bevestigd: hooks zijn deterministisch. CLAUDE.md is adviserend — Claude volgt het ongeveer 80% van de tijd. Hooks worden 100% van de tijd uitgevoerd. Als iets na elke wijziging zonder uitzondering moet gebeuren — formatteren, linten, security checks — maak er een hook van, geen CLAUDE.md-regel.

Stap 6: Parallelle Sessies en Git Worktrees

Hier wordt de productiviteitsvermenigvuldiger echt absurd.

De meeste ontwikkelaars draaien één Claude Code-sessie tegelijk. Eén taak, één branch, één sequentiële pipeline. Maddy draait meerdere sessies gelijktijdig — sommige in terminaltabs, andere in IDE-panelen — elk met een volledig onafhankelijke taak. Het geheim waardoor dit werkt zonder te verzanden in Git-conflicten: elke sessie draait in zijn eigen Git worktree.

Een worktree is een aparte werkdirectory die gekoppeld is aan dezelfde repository. Elke worktree heeft zijn eigen uitgecheckte branch. Wijzigingen in de ene worktree beïnvloeden de andere niet. Claude Code heeft native ondersteuning voor worktrees — je kunt met één commando een sessie starten in een eigen geïsoleerde workspace.

De praktische workflow:

1. Maak voor elke feature een worktree aan: git worktree add ../auth-feature feature/auth
2. Open een Claude Code-sessie in elke worktree
3. Geef elke sessie zijn taak en laat ze onafhankelijk werken
4. Review en merge zodra elke feature klaar is

Ik draai meestal drie parallelle sessies. Meer dan dat en de review-overhead begint de tijdwinst op te slokken. Drie is voor mij het ideale aantal: elke sessie krijgt voldoende aandacht zonder dat het een context-switching-nachtmerrie wordt.

De mentale omslag hier is aanzienlijk. Je stopt met denken als een ontwikkelaar die met AI-hulp codeert. Je begint te denken als een engineering manager die een team van AI-ontwikkelaars aanstuurt. Je taak is niet om code te schrijven — maar om werk te plannen, toe te wijzen aan de juiste sessies, output te reviewen en architecturale beslissingen te nemen. De daadwerkelijke codegeneratie gebeurt parallel, over meerdere onafhankelijke werkstromen.

Wil je een volledige deep dive in het opzetten van worktrees met Claude Code — inclusief de subtiele valkuil waarbij commits op main terechtkomen terwijl je denkt dat ze naar een feature branch gaan — ik heb een complete walkthrough geschreven die elk edge case behandelt die ik ben tegengekomen.

Wil je liever dat iemand dit soort multi-agent ontwikkelomgeving voor jouw team opzet? Ik neem workflow automation opdrachten aan. Bekijk wat ik heb gebouwd op fiverr.com/s/EgxYmWD.

Stap 7: Subagenten voor Geïsoleerde Subtaken

Parallelle sessies behandelen afzonderlijke features. Subagenten behandelen afzonderlijke aandachtspunten binnen één feature.

Een subagent is een lichtgewicht, geïsoleerde AI-agent die door je hoofd-Claudesessie wordt opgestart om een specifieke subtaak uit te voeren. Het sleutelwoord is "geïsoleerd" — elke subagent krijgt zijn eigen systeemprompt, eigen toolrechten en een eigen contextvenster. Hij voert zijn taak uit en rapporteert terug zonder de context van de hoofdessie te vervuilen.

Claude Code wordt geleverd met drie ingebouwde subagenttypes: Explore (alleen-lezen, geoptimaliseerd voor snelheid en kosten), Plan (verzamelt context voordat een strategie wordt gepresenteerd), en een algemene agent voor taken die zowel exploratie als modificatie vereisen.

Maar de echte kracht zit in aangepaste subagenten. Het voorbeeld van Maddy dat voor mij het kwartje deed vallen: het opstarten van een security-gerichte subagent die codewijzigingen door een beveiligingsbril bekijkt, terwijl de hoofdessie doorgaat met het bouwen van features. De security-agent heeft een eigen systeemprompt, gevuld met OWASP Top 10-checks en de beveiligingsrichtlijnen van jouw organisatie. Hij werkt onafhankelijk, signaleert problemen en zijn bevindingen vervuilen de context van de hoofdessie niet.

Zo gebruik ik subagenten in de praktijk:

• Security review agent: Draait parallel aan feature-ontwikkeling en controleert elke wijziging op kwetsbaarheden
• Documentatie-agent: Genereert en actualiseert documentatie naarmate de codebase evolueert, los van de implementatiecontext
• Testgeneratie-agent: Schrijft testcases voor afgeronde features terwijl ik met de hoofdessie al aan de volgende taak begin

De isolatie is wat subagenten fundamenteel anders maakt dan simpelweg Claude vragen om "ook op security-issues te letten" in je hoofdprompt. Die aanpak vreet context. Het verdeelt Claude’s aandacht. En het levert oppervlakkige security-analyses op omdat het model implementatie en review tegelijk moet combineren. Een toegewijde subagent focust zich volledig op zijn toegewezen aandachtspunt, met een systeemprompt die geoptimaliseerd is voor die specifieke taak.

Eén ding dat ik heb geleerd door te experimenteren: subagenten werken het best voor taken die duidelijk los te koppelen zijn van de hoofdworkflow. Als de subtaak veel heen-en-weer vereist met de hoofdessie — "wacht, check dit bestand voordat ik verder ga" — kun je het beter in de hoofdessie afhandelen. Subagenten komen het best tot hun recht bij fire-and-forget-taken.

Stap 8: Skills — De Kennis van je Team Coderen

Slash-commando’s handelen enkelvoudige acties af. Skills behandelen meerstaps workflows.

Het onderscheid is belangrijk. Een slash-commando zegt: “doe deze ene taak.” Een skill zegt: “hier is een volledige procedure voor het oplossen van dit type probleem, inclusief beslissingsbomen, randgevallen en kwaliteitscriteria.” Ik heb uitgebreid over deze architectuur geschreven in mijn gids over agent skills, maar de korte versie: skills zijn de manier waarop je institutionele kennis omzet in herbruikbare, door AI uitvoerbare draaiboeken.

Maddy vergelijkt het met het verschil tussen iemand een snelkoppeling geven en iemand trainen. Beide zijn nuttig. Training is wat zich opstapelt.

Een skill is een Markdown-bestand (opgeslagen in .claude/skills/) dat een meerstaps workflow bevat. Hier is een verkort voorbeeld van een code review skill:

# Uitgebreide Code Review
---

## Stap 1: Architectuurbeoordeling
- Controleer of wijzigingen aansluiten bij bestaande patronen in de codebase
- Verifieer of nieuwe bestanden in de juiste mappen staan volgens de projectconventies
- Markeer architecturale beslissingen die gedocumenteerd moeten worden

## Stap 2: Logica Controleren
- Volg het happy path door de nieuwe code
- Identificeer randgevallen die niet worden afgehandeld
- Controleer de volledigheid van de foutafhandeling

## Stap 3: Prestatiecontrole
- Signaleer N+1-querypatronen
- Controleer op onnodige her-renderingen in React-componenten
- Verifieer dat er database-indexen bestaan voor nieuwe querypatronen

## Stap 4: Beveiligingsscan
- Controleer invoervalidatie op alle door gebruikers aangeleverde gegevens
- Verifieer authenticatie-/autorisatiecontroles
- Controleer op injectiekwetsbaarheden

## Stap 5: Beoordeling van Testdekking
- Verifieer dat kritieke paden testdekking hebben
- Controleer of randgevallen uit Stap 2 overeenkomende tests hebben
- Markeer alle niet-geteste foutafhandelingspaden

## Uitvoerformaat
Voor elk bevinding:
- **Bestand:** [pad]
- **Regel:** [nummer]
- **Ernst:** Kritiek | Hoog | Medium | Laag | Info
- **Bevinding:** [beschrijving]
- **Aanbeveling:** [specifieke oplossing]

Wanneer je deze skill aanroept, voert Claude niet zomaar een snelle scan uit. Het voert een gestructureerd, vijfstappen beoordelingsproces uit dat categorieën van problemen opspoort die een oppervlakkige review zou missen. En omdat de skill versiebeheerde Markdown is, profiteert je hele team van elke verfijning.

Het cumulatieve effect dat Maddy beschrijft — en dat ik uit eerste hand heb ervaren — is dat skills de met moeite verworven kennis van je team in de loop der tijd verzamelen. Elk edge case dat je ontdekt, wordt toegevoegd aan de relevante skill. Elke fout wordt een controlepunt. Zes maanden na het starten van deze werkwijze bevatten je skills de gedestilleerde expertise van elk project waar je aan hebt gewerkt. Nieuwe teamleden erven die kennis direct.

Ik onderhoud momenteel ongeveer twintig skills verspreid over mijn projecten. De skills die het meeste waarde leveren: code review (vijfstappenproces), API endpoint scaffolding (genereert route, controller, validatie, tests en documentatie in één keer), database migratieplanning (analyseert het bestaande schema, suggereert migratiestappen, signaleert risico’s voor dataintegriteit), en deployment checklist (loopt alle omgevingsvariabelen, secrets, DNS, SSL en monitoring na vóór elke productie-release).

## Stap 9: MCP-servers — Claude uitbreiden buiten je codebase

Het laatste onderdeel van Maddy’s workflow verbindt Claude met de rest van je ontwikkelomgeving.

MCP (Model Context Protocol) servers zijn zelfstandige programma’s die tools en resources beschikbaar maken voor Claude Code via een gestandaardiseerd protocol. Het concept is eenvoudig: Claude leest al bestanden en voert commando’s uit. MCP-servers zorgen ervoor dat Claude ook kan communiceren met GitHub, Slack, databases, API’s en elke andere externe dienst waar je workflow van afhankelijk is.

De [praktische setup is eenvoudiger dan het klinkt](https://alexop.dev/posts/understanding-claude-code-full-stack/). Je voegt MCP-servers toe via scope-configuratie — `user` scope voor servers die in alle projecten beschikbaar zijn, `local` scope voor tools per project, en `project` scope (opgeslagen in `.mcp.json`) voor tools die je via Git met je team deelt.

Wat mij verraste toen ik voor het eerst MCP-servers koppelde: Claude Code laadt niet elke tool van elke server direct in de context. Het gebruikt tool search om tools on demand te ontdekken en haalt schema’s alleen op wanneer dat nodig is. Dit vermindert het contextgebruik met ongeveer 95% vergeleken met clients die alle tooldefinities vooraf laden. Een slimme ontwerpkeuze die het draaien van meerdere MCP-servers praktisch maakt in plaats van context-onhaalbaar.

De MCP-servers die ik dagelijks gebruik:

- **GitHub MCP:** Claude kan PR-comments lezen, issues aanmaken, diffs reviewen en feedback posten — allemaal zonder de terminalsessie te verlaten
- **Filesystem MCP:** Uitgebreide bestandsbewerkingen, verdergaand dan wat Claude Code standaard ondersteunt
- **Slack MCP:** Notificaties wanneer taken klaar zijn, foutmeldingen en statusupdates direct gepost in projectkanalen

Maddy’s punt over MCP-servers raakte bij mij een snaar: ze transformeren Claude van een code-assistent tot iets dat meer lijkt op een semi-autonome engineer die over je hele ontwikkelomgeving opereert. Wanneer Claude een GitHub-issue kan lezen, de implementatie kan plannen, de code kan schrijven, de tests kan draaien, de PR kan aanmaken en een samenvatting in Slack kan posten — verschuift de menselijke bottleneck van code schrijven naar het nemen van beslissingen.

Dat is precies de juiste bottleneck om te hebben.

## Het Samengestelde Effect: Waarom Alle Negen Stappen Samen Belangrijk Zijn

Ik wil ergens direct over zijn: het implementeren van één enkele stap uit deze workflow zal je Claude Code-ervaring al verbeteren. Alleen planmodus is de moeite van het lezen waard. Alleen validatiehooks verminderen je debugtijd. Alleen slashcommando’s maken je dagelijkse workflow consistenter.

Maar de echte transformatie vindt plaats wanneer alle negen stappen als één systeem samenwerken.

Zo versterken ze elkaar. `CLAUDE.md` geeft Claude projectinzicht. Planmodus geeft architecturaal bewustzijn. `/clear` voorkomt contextdegradatie. Slashcommando’s zorgen voor consistente inputkwaliteit. Validatiehooks bieden geautomatiseerde feedbackloops. Parallelle sessies verhogen de doorvoersnelheid. Subagents leveren gespecialiseerde, geïsoleerde analyses. Skills coderen institutionele kennis. MCP-servers vergroten het bereik buiten de codebase.

Haal je één onderdeel weg, dan werkt het systeem nog steeds. Maar het werkt zoals een auto met een lekke band — technisch functioneel, maar merkbaar minder goed. De onderdelen zijn ontworpen om elkaars beperkingen op te vangen. Planmodus vangt architecturale fouten op die `CLAUDE.md` alleen niet kan voorkomen. Validatiehooks vangen implementatiefouten op die planmodus niet kan voorzien. Context wissen voorkomt het soort progressieve kwaliteitsafname waardoor alles minder betrouwbaar wordt na verloop van tijd.

De workflow waar ik na een maand oefenen op ben uitgekomen:

1. Begin elk project met een beknopte `CLAUDE.md` (onder de 150 regels)
2. Begin elke taak met planmodus — reviewen en goedkeuren vóór uitvoering
3. Laat validatiehooks automatisch fouten opvangen tijdens de uitvoering
4. Wis de context na elke voltooide taak
5. Gebruik slashcommando’s voor elke herhaalde workflow
6. Draai 2-3 parallelle sessies op onafhankelijke features via worktrees
7. Start subagents voor security review en het genereren van tests
8. Onderhoud skills voor meerstapsworkflows die het team deelt
9. Koppel MCP-servers voor GitHub, Slack en alle project-specifieke integraties

De leercurve is echt. De eerste week van bewust oefenen voelde trager dan mijn oude workflow. Ik was voortdurend planmodus aan het wisselen, slashcommando’s aan het schrijven, hooks aan het instellen — overhead die geen direct zichtbaar resultaat opleverde. In de tweede week werd die overhead automatisch. In de derde week leverde ik in één ochtend meer op dan ik vroeger op een hele dag.

## Wat Ik Verkeerd Deed — En Wat Ik Nu Anders Zou Doen

Ik ben eerlijk over de fouten die ik maakte bij het implementeren van deze workflow, omdat ze jou tijd zullen besparen als je vanaf nul begint.

**Fout 1: Alles tegelijk implementeren.** Ik las Maddy’s volledige methodologie en probeerde op dag één alle negen praktijken toe te passen. De cognitieve belasting was enorm. Ik was zo gefocust op het proces dat ik nauwelijks nog code schreef. Betere aanpak: begin met `CLAUDE.md` + planmodus + `/clear`. Voeg validatiehooks toe in week twee. Voeg slashcommando’s en parallelle sessies toe in week drie. Bewaar subagents, skills en MCP voor week vier.

**Fout 2: Slashcommando’s te ingewikkeld maken.** Mijn eerste reeks slashcommando’s waren in feite essays. Driehonderd woorden instructies per stuk. Ze werkten, maar verbruikten enorm veel context. Inmiddels heb ik ze net zo beknopt gemaakt als mijn `CLAUDE.md` — elk woord moet zijn plek verdienen. Een gefocust commando van 50 woorden presteert vrijwel altijd beter dan een omslachtig commando van 300 woorden.

**Fout 3: Te veel parallelle sessies draaien.** Ik raakte enthousiast en probeerde vijf sessies tegelijk te draaien. De overhead van het reviewen vernietigde de productiviteitswinst. Drie is voor mij het ideale aantal. Twee als de taken complex zijn. Vijf was pure chaos.

**Fout 4: Vergeten om de context te wissen.** Oude gewoontes slijten langzaam. Ik kwam in een flow, rondde drie taken af zonder te wissen, en vroeg me af waarom Claude’s suggesties steeds slechter werden. Uiteindelijk heb ik een fysieke post-it op mijn monitor geplakt: “Heb je /clear gedaan?” Onelegant. Effectief.

**Fout 5: Subagents gebruiken voor taken die hoofd-sessiecontext nodig hadden.** Ik probeerde een subagent te starten om een functie te refactoren die sterk afhankelijk was van het gesprek dat ik met de hoofd-sessie had gevoerd over architecturale beslissingen. De subagent had die context niet en leverde een refactor op die alles tegensprak wat we hadden besproken. Subagents werken voor onafhankelijke taken. Voor contextgevoelig werk, houd het in de hoofd-sessie.

Geen van deze fouten was rampzalig. Maar elke fout kostte me tijd die ik niet had hoeven verliezen. De workflow is echt krachtig — en het is het krachtigst als je de beperkingen respecteert in plaats van ze te proberen te omzeilen.

## De verschuiving in hoe je over je rol denkt

Er zit een groter idee onder alle negen stappen dat het even duurde voordat ik het goed kon verwoorden.

Wanneer je deze workflow volledig implementeert, verandert je rol. Je besteedt minder tijd aan het schrijven van code en meer tijd aan het nemen van beslissingen. Je plant architectuur in plaats van deze te implementeren. Je beoordeelt output in plaats van deze te genereren. Je ontwerpt systemen in plaats van ze te typen.

Sommige ontwikkelaars vinden dit ongemakkelijk. Voor velen van ons is coderen een deel van onze identiteit. Het gevoel om iets regel voor regel op te bouwen — die flow waarin je vingers en je brein perfect gesynchroniseerd zijn — is oprecht bevredigend. Dat (deels) opgeven voelt als een verlies.

Zo voelde ik me de eerste twee weken ook. Toen realiseerde ik me dat de beslissingen die ik nam — de architecturale keuzes, de prioriteitsafwegingen, de kwaliteitsbeoordelingen — moeilijker en waardevoller waren dan de code die ik vroeger schreef. De code was uitvoering. De beslissingen waren strategie. En strategie bepaalt uiteindelijk of software slaagt.

Het framework van Maddy vervangt geen technische vaardigheden. Het stuurt ze bij. Je kennis van algoritmes, datastructuren, design patterns en systeemarchitectuur wordt belangrijker, niet minder — omdat jij degene bent die een AI aanstuurt die op bovenmenselijke snelheid kan uitvoeren, maar zonder jou geen strategische beslissingen kan nemen.

De engineers die ik zie worstelen met deze workflow zijn degenen die het toetsenbord niet kunnen loslaten. Degenen die floreren zijn juist degenen die altijd al meer tijd wilden besteden aan architectuur en minder aan het typen van boilerplate. Deze workflow geeft je precies die ruil.

## Waar Dit Heen Gaat

Ik denk niet dat we er al zijn. Het verschil tussen wat Claude Code vandaag kan en wat het over twaalf maanden zal kunnen, is waarschijnlijk groter dan de meeste ontwikkelaars verwachten.

Het patroon dat ik in de gaten houd: elk van deze negen praktijken bestaat vanwege een huidige beperking. Planmodus bestaat omdat Claude soms correcte code op de verkeerde plek schrijft. Validatiehooks bestaan omdat Claude niet altijd zijn eigen werk intern kan verifiëren. Context opschonen bestaat omdat contextvensters een beperkte capaciteit hebben. Subagents bestaan omdat één enkele context niet alle aandachtspunten tegelijk kan bevatten.

Naarmate contextvensters groter worden, modellen beter worden in zelfverificatie en het gebruik van tools geavanceerder wordt, zullen sommige van deze praktijken minder cruciaal worden. Planmodus kan overbodig worden zodra het architectonisch redeneren van het model betrouwbaar genoeg is om die expliciete stap over te slaan. Validatiehooks kunnen overbodig worden zodra de interne verificatie van het model overeenkomt met de nauwkeurigheid van externe tests.

Maar de meta-praktijk — structuur bouwen rondom AI-capaciteiten — wordt alleen maar belangrijker. De modellen worden beter. De engineers die weten hoe ze workflows rondom die modellen moeten ontwerpen, zullen de meeste waarde halen. Dat is de echte vaardigheid die deze methodologie bijbrengt: niet hoe je Claude Code specifiek gebruikt, maar hoe je AI-ondersteunde ontwikkeling als een discipline benadert.

Maddy’s negen stappen zijn het beste startpunt dat ik heb gevonden om die discipline op te bouwen. Begin met `CLAUDE.md` en planmodus. Voeg elke week één praktijk toe. Over een maand heb je een workflow waardoor je huidige aanpak aanvoelt als rijden met de handrem erop.

De vraag waar je vanavond eens goed bij stil moet staan, is niet of deze workflow het implementeren waard is — het bewijs daarvoor is overweldigend. De vraag is welke van je huidige gewoonten zo comfortabel zijn geworden dat ze je ervan weerhouden de overstap te maken.

## Veelgestelde Vragen

### Hoe stel ik planmodus in bij Claude Code?

Schakel de planmodus in met `Shift+Tab` in de Claude Code CLI voordat je je taak beschrijft. Claude analyseert je codebase en genereert een implementatieplan ter beoordeling voordat er code wordt geschreven. Gebruik deze modus voor elke wijziging die meer dan één bestand raakt.

### Wat is het verschil tussen slash-commando’s en skills in Claude Code?

Slash-commando’s zijn enkelvoudige acties die als Markdown-bestanden worden opgeslagen in `.claude/commands/`. Skills zijn meerstaps-workflows die worden opgeslagen in `.claude/skills/` en complexe procedures vastleggen met beslissingsbomen en kwaliteitscriteria. Sinds 2026 gebruiken beide dezelfde slash-commando-interface.

### Hoeveel parallelle Claude Code-sessies moet ik draaien?

Begin met twee parallelle sessies en gebruik Git worktrees voor isolatie. Drie sessies is het praktische optimum voor de meeste ontwikkelaars. Meer dan drie sessies levert doorgaans extra review-werk op, waardoor de productiviteitswinst van parallelisatie teniet wordt gedaan.

### Vertragen Claude Code validatiehooks de ontwikkeling?

Hooks voegen na elke bewerking evenveel tijd toe als je build- en testduur. Voor projecten met test suites onder de 30 seconden is de overhead verwaarloosbaar vergeleken met de debuggingtijd die ze voorkomen. Bij langere test suites kun je overwegen om een relevante subset als hook te draaien en de volledige suite pas voor commits.

### Welke MCP-servers moet ik installeren voor Claude Code?

De meeste ontwikkelaars hebben twee tot drie MCP-servers nodig: GitHub (voor PR- en issuebeheer), een filesystem-extensie en één domeinspecifieke server. Voeg ze toe via scope-configuratie — `user` voor globale beschikbaarheid, `project` voor teamtools via `.mcp.json` in je repo.

## Laten We Samenwerken

Wil je AI-systemen bouwen, workflows automatiseren of je technische infrastructuur opschalen? Ik help je graag.

* **Fiverr** (maatwerk & integraties): [fiverr.com/s/EgxYmWD](https://www.fiverr.com/s/EgxYmWD)
* **Portfolio**: [mejba.me](https://www.mejba.me)
* **Ramlit Limited** (enterprise-oplossingen): [ramlit.com](https://www.ramlit.com)
* **ColorPark** (design & branding): [colorpark.io](https://www.colorpark.io)
* **xCyberSecurity** (beveiligingsdiensten): [xcybersecurity.io](https://www.xcybersecurity.io)
---