Zes Niveaus van Claude Code Meesterschap Die Ik Eerder Had Willen Kennen
Drie maanden geleden zag ik hoe een van mijn Claude Code-sessies output produceerde die zo generiek was dat het van elke gratis chatbot op het internet had kunnen komen. Ik gebruikte de tool op dat moment al dagelijks, bijna een jaar lang. Ik had er klantprojecten mee gebouwd, productiecode mee uitgerold, er zelfs over geschreven op deze blog. En toch zat ik daar, starend naar standaardcode waar een eerstejaarsstudent informatica zich voor zou hebben geschaamd.
Dat moment dwong me iets ongemakkelijks onder ogen te zien: ik had Claude Code verkeerd gebruikt. Niet kapot-verkeerd. Niet crash-de-terminal-verkeerd. Verkeerd op de manier waarop iemand die een Ferrari in de eerste versnelling rijdt verkeerd bezig is -- technisch gezien bedien je de machine, maar je mist alles wat hem bijzonder maakt.
Wat volgde was een drie maanden durende diepduik in het begrijpen van de daadwerkelijke vaardigheidsontwikkeling binnen Claude Code. Niet de marketingversie waar alles op dag één klikt. De echte versie, waarin elk niveau vereist dat je gewoontes van het vorige niveau afleert, en waarin de valkuilen op elk niveau gevaarlijker zijn dan de uitdagingen.
Ik heb zes duidelijke niveaus geïdentificeerd. Ik heb me persoonlijk door elk ervan heen geworsteld, soms weken vastgezeten op een plateau voordat ik doorhad wat me tegenhield. Het verschil tussen Niveau 1 en Niveau 6 is niet alleen een productiviteitsverschil -- het is een fundamenteel andere relatie met AI als ontwikkelpartner.
Dit is wat niemand me vertelde toen ik begon: de moeilijkste overgang is niet het leren van nieuwe commando's. Het is het loslaten van de mindset die je naar het huidige niveau heeft gebracht.
Niveau 1: De Prompt Engineer (Waar Iedereen Begint en de Meesten Blijven Hangen)
Ik herinner me mijn eerste week met Claude Code nog levendig. Ik behandelde het zoals ik elk command-line tool behandel: typ een instructie, ontvang output, herhaal. "Bouw een REST API voor gebruikersauthenticatie." "Schrijf tests voor dit component." "Refactor deze functie naar async/await."
En het werkte. Min of meer. Claude genereerde code, ik plakte het in mijn project, repareerde een paar dingen en ging verder. De workflow voelde productief omdat ik het vergeleek met alles met de hand schrijven. Elke versnelling voelde als winst.
Het probleem was aanvankelijk onzichtbaar. Elke output had dezelfde kwaliteit -- adequaat maar onopvallend. De authenticatie-API werkte, maar gebruikte patronen die niet bij de rest van mijn codebase pasten. De tests dekten de happy paths maar misten edge cases die ik handmatig wel zou hebben gevonden. De gerefactorde functie was schoner, zeker, maar introduceerde een subtiele wijziging in de foutafhandeling die ik pas in productie opmerkte.
Dit is Niveau 1: de Prompt Engineer. Je schrijft commando's en ontvangt antwoorden. Eenrichtingsverkeer. Jij praat, de AI luistert, de AI produceert. Er is geen dialoog, geen iteratie binnen de sessie, geen samenwerking.
De valkuil op dit niveau heeft een naam die het perfect beschrijft: AI slop. Generieke, technisch-correcte-maar-karakterloze output die leest alsof het is samengesteld uit documentatiefragmenten. Je herkent het meteen -- het gebruikt variabelenamen als data en result, structureert code op de meest conventionele manier mogelijk, en voegt commentaar toe dat uitlegt wat de code doet in plaats van waarom.
Ik heb ongeveer zes weken op Niveau 1 gezeten. Mijn output was sneller dan handmatig coderen, maar vereiste zoveel bewerkingen dat de tijdwinst marginaal was. De doorbraak kwam toen ik besefte dat ik Claude Code als een typemachine behandelde, terwijl het gebouwd was om een gesprekspartner te zijn.
Wat me uiteindelijk voorbij dit niveau duwde, was een frustrerende dinsdagmiddag. Ik had Claude Code gevraagd een webhook handler te bouwen, en het produceerde iets functioneels maar volledig losgekoppeld van de patronen in mijn bestaande codebase. In plaats van de prompt te herschrijven met meer details, probeerde ik iets anders. Ik begon vragen terug te stellen.
Die ene verschuiving -- van bevelen naar converseren -- veranderde alles.
Niveau 2: De Planner (Waar Dialoog Dictaat Vervangt)
Plan Mode was de functie die Niveau 2 voor mij ontgrendelde. Als je het nog niet hebt gebruikt: het concept is simpel. In plaats van dat Claude Code je verzoek direct uitvoert, stelt het eerst een plan voor, stelt verduidelijkende vragen, en wacht op jouw input voordat het ook maar één regel code schrijft.
De eerste keer dat ik Plan Mode inschakelde voor een complexe taak, was het verschil verbluffend. Ik vroeg Claude om een notificatiesysteem te bouwen voor een klantproject. In plaats van meteen code te genereren, kwam het terug met vragen waar ik niet aan had gedacht: "Moeten notificaties worden opgeslagen in een database of als tijdelijke events worden afgehandeld? Wat is de leveringsprioriteit -- moet het systeem levering garanderen of is best-effort acceptabel? Ben je van plan meerdere notificatiekanalen naast e-mail te ondersteunen?"
Dit waren geen generieke vragen. Het waren precies de architecturale beslissingen die ik toch had moeten nemen -- maar waarschijnlijk impliciet zou hebben genomen, zonder er goed over na te denken, met herwerk als gevolg.
Plan Mode verandert je relatie met Claude Code fundamenteel. Je stopt met bevelen en begint met samenwerken. De AI duwt terug, stelt alternatieven voor, identificeert gaten in je specificatie. Het is het verschil tussen iemand een blauwdruk geven en samen met een architect gaan ontwerpen.
Dit is mijn daadwerkelijke workflow op Niveau 2. Ik begin elke niet-triviale taak met Plan Mode ingeschakeld. Ik beschrijf op hoog niveau wat ik wil. Claude stelt een aanpak voor en stelt vragen. Ik beantwoord de vragen en voeg beperkingen toe. Claude verfijnt het plan. Ik keur goed of pas aan. Pas dan begint de codegeneratie. De hele planningsfase duurt vijf tot tien minuten, maar bespaart uren aan herwerk.
De valkuil op Niveau 2 is subtieler dan die van Niveau 1. Op Niveau 1 is de valkuil overduidelijk -- slechte output. Op Niveau 2 is de valkuil passiviteit. Je raakt gewend aan Claude dat goede vragen stelt, waardoor je stopt met het inbrengen van je eigen expertise. Je wordt een vragenbeantwoorder in plaats van een meedenker.
Ik betrapte mezelf hierop bij een databasemigratieproject. Claude's plan was technisch solide, maar het stelde een migratiestrategie voor die downtime zou hebben veroorzaakt tijdens de deployment. Ik had het bijna goedgekeurd omdat het plan er "goed uitzag." De vragen die Claude stelde waren slim, maar het stelde niet de vraag die er het meest toe deed, omdat het niet wist van onze zero-downtime deployment-eis. Dat was kennis die ik zelf moest inbrengen.
De les: Plan Mode maakt Claude een betere samenwerkingspartner, maar het maakt Claude niet alwetend. Je moet nog steeds context injecteren die de AI niet kan afleiden. En weten welke context je moet injecteren -- dat is de vaardigheid die Niveau 3 definieert.
Niveau 3: De Context Engineer (Waar het Echte Vaardigheidsverschil Ontstaat)
Dit is het niveau waar casual Claude Code-gebruikers en serieuze beoefenaars uiteenlopen. Context engineering klinkt academisch, maar het is de meest praktische vaardigheid in de hele progressie. Het is de kunst om Claude precies de juiste informatie te geven op precies het juiste moment -- niet meer, niet minder.
Ik leerde dit op de harde manier tijdens een groot refactoringproject. Ik had een monolithische Express-applicatie die opgesplitst moest worden in microservices. Mijn aanpak was om de hele codebase in Claude's context te laden, het doel uit te leggen, en het zijn werk te laten doen. Leek logisch. Geef maximale informatie, krijg maximale kwaliteit output.
De resultaten waren verschrikkelijk. Niet meteen -- de eerste paar bestanden die Claude refactorde waren uitstekend. Maar tegen het derde uur werden de suggesties vreemd. Functiesignaturen die niet overeen kwamen met bestaande patronen. Importpaden die naar bestanden in de oude structuur wezen. Variabelenamen die halverwege de sessie overschakelden van camelCase naar snake_case. Het was alsof je iemand langzaam zag wegzakken tijdens een marathon-meeting.
Dat was mijn eerste ontmoeting met context rot, en het begrijpen ervan veranderde alles aan hoe ik Claude Code gebruik.
Context Rot: De Stille Prestatiekiller
Dit is de technische realiteit waar de meeste tutorials overheen glijden. Claude Code's context window heeft een capaciteit, en die capaciteit gaat niet alleen over het inpassen van informatie -- het gaat over het behouden van aandachtskwaliteit over die informatie heen. Zodra je context window voorbij ongeveer 50-60% gevuld raakt, begint de outputkwaliteit af te nemen op manieren die frustrerend subtiel zijn.
Ik heb dit systematisch getest over meerdere projecten. Dezelfde taken, dezelfde prompts, verschillende contextbelasting. Bij 20-30% contextbenutting was Claude's output precies, conventie-bewust en structureel consistent. Bij 50% begonnen kleine inconsistenties binnen te sluipen -- niets dat de build zou breken, maar genoeg om handmatige opschoning te vereisen. Bij 70%+ werd de output wat ik alleen kan omschrijven als "zelfverzekerd fout." Syntactisch correcte code die architecturaal twijfelachtige beslissingen nam.
Het /compact commando werd mijn beste vriend in deze fase. /compact uitvoeren comprimeert de gesprekscontext, verwijdert afgeronde uitwisselingen terwijl de essentiële informatie behouden blijft die Claude nodig heeft voor continuïteit. Ik voer het nu proactief uit, niet reactief. Elke keer als ik een deeltaak afrond, compact ik voordat ik aan de volgende begin.
En /clear? Dat is de nucleaire optie, maar soms is het de juiste keuze. Een volledig verse context starten voor een nieuwe taak levert betere output op dan een opgeblazen sessie voortzetten, ook al voelt het alsof je het begrip "verspilt" dat Claude had opgebouwd. Het begrip voorbij 60% capaciteit is meer een last dan een voordeel.
Wat je de Context Moet Voeden (En Wat je Moet Achterhouden)
De andere helft van context engineering is curatie. Niet elk bestand is relevant. Niet elk stuk context helpt. Je hele package.json, al je configuratiebestanden en je complete testsuite laden "voor het geval dat" is het context-equivalent van je hele garderobe inpakken voor een weekendje weg.
Mijn aanpak is nu chirurgisch. Voor elke taak identificeer ik drie categorieën context:
Essentiële context -- bestanden die direct worden gewijzigd of die interfaces definiëren waaraan de gewijzigde code moet voldoen. Deze gaan er als eerste in.
Referentiecontext -- voorbeelden van vergelijkbare patronen in de codebase die Claude moet volgen. Ik laad typisch één of twee representatieve bestanden, niet elke instantie.
Perifere context -- dingen die relevant zouden kunnen zijn. Deze blijven buiten de initiële context. Als Claude ze nodig heeft, vraagt het ernaar -- en die vraag op zich is een signaal dat ik moet evalueren of de context werkelijk nodig is.
Ik begon ook screenshots van UI-componenten aan te leveren bij frontendwerk. Klinkt vanzelfsprekend, maar ik verzette me hier wekenlang tegen omdat het inefficiënt aanvoelde. Het blijkt dat een screenshot van de huidige componentstatus Claude meer bruikbare context geeft dan drie paragrafen beschrijving. Visuele context wordt onderschat.
Het CLAUDE.md-bestand in je projectroot is nog zo'n Niveau 3-tool die de meeste mensen ondergebruiken. De mijne bevat codeerconventies, architecturale beslissingen en expliciete regels zoals "gebruik altijd early returns" en "foutresponses moeten zowel een machineleesbare code als een mensleesbaar bericht bevatten." Het automatisch laden van deze conventies betekent dat Claude elke sessie al afgestemd begint op mijn patronen, zonder context te verbranden aan uitleg.
De valkuil op Niveau 3 is het overdenken van contextmanagement tot het punt waarop je meer tijd besteedt aan het cureren van input dan aan het genereren van output. Ik liep hier ongeveer twee weken tegenaan, obsessief contextbenuttingspercentages metend en twijfelend bij elk bestand dat ik laadde. Het balancepunt ligt dichter bij "goede curatie, snel" dan bij "perfecte curatie, langzaam."
Wat me uiteindelijk vooruit trok, was het besef dat contextkwaliteit meer uitmaakt dan contextvolume -- en dat bepaalde tools contextbeslissingen automatisch voor me konden nemen. Dat inzicht opende de deur naar Niveau 4.
Niveau 4: De Tool Integrator (Waar Claude Code Superkrachten Krijgt)
Niveau 4 is waar Claude Code stopt met alleen een code-assistent te zijn en begint een uitbreidbaar ontwikkelplatform te worden. Dit is het niveau van MCP-servers -- Model Context Protocol-servers en frameworks die Claude mogelijkheden geven die verder gaan dan tekstgeneratie.
MCP-servers zijn in de praktijk plugins die Claude laten communiceren met externe systemen. Databasequeries. API-aanroepen. Bestandssysteemoperaties. Browserautomatisering. Design tool-integratie. Elke MCP-server breidt uit wat Claude kan doen zonder dat jij handmatig data tussen tools hoeft te kopiëren.
Ik integreerde mijn eerste MCP-server -- een PostgreSQL-connector -- nadat ik een hele middag handmatig queryresultaten van pgAdmin naar Claude's context had zitten kopiëren zodat het me kon helpen trage queries te optimaliseren. De absurditeit van die workflow trof me midden in het plakken. Ik was het traagste onderdeel in mijn eigen pipeline, fungerend als een menselijk klembord tussen twee digitale tools.
Na het verbinden van de Postgres MCP-server kon ik simpelweg zeggen "analyseer de trage queries in de orders-tabel en stel indexverbeteringen voor." Claude zou de database direct queryen, de executieplannen onderzoeken en geoptimaliseerde indexes voorstellen met de daadwerkelijke SQL om ze aan te maken. Wat een middag copy-pasten kostte, werd een gesprek van vijf minuten.
Maar hier wordt Niveau 4 gevaarlijk.
De Tool Overload-Valkuil
Mijn MCP-servercollectie groeide snel na die eerste integratie. Postgres-connector. GitHub-integratie. Slack voor notificaties. Notion voor documentatie. Browserautomatisering voor testen. Linear voor projectmanagement. Figma voor designspecificaties.
Binnen twee weken had ik elf MCP-servers geconfigureerd. En Claude's prestaties kelderden.
Niet omdat de servers buggy waren -- ze werkten individueel prima. Het probleem was cognitieve overhead aan Claude's kant. Met elf verschillende tools beschikbaar, greep Claude soms naar de verkeerde, of besteedde tokens aan het evalueren welke tool te gebruiken voordat het eigenlijke werk begon. Erger nog, te veel mogelijkheden maakten Claude's antwoorden trager en soms verward over welke tool welke taak kon afhandelen.
Ik leerde deze les tijdens een code review-sessie. Ik vroeg Claude om een pull request te controleren op beveiligingsproblemen. In plaats van de code direct te analyseren, probeerde het de GitHub MCP-server te gebruiken om PR-metadata op te halen, vervolgens de browserautomatisering om de diff te renderen, en daarna de Postgres-connector om te controleren op SQL-injectiepatronen -- een Rube Goldberg-machine van tool-aanroepen die slechtere analyse produceerde dan gewoon de code lezen zou hebben opgeleverd.
De oplossing was chirurgische selectie. Ik stripte mijn MCP-configuratie terug naar vijf servers die ik daadwerkelijk dagelijks gebruikte: GitHub, Postgres, een file system watcher, Notion en een op maat gemaakte API-testtool die ik zelf had gebouwd. Al het andere werd verwijderd.
Het principe dat ik nu volg: voeg een tool pas toe als je dezelfde handmatige workflow-frictie minstens drie keer bent tegengekomen. Als je niet actief geïrriteerd bent door de afwezigheid van een mogelijkheid, heb je de plugin niet nodig. Mogelijkheden en prestaties zijn niet hetzelfde -- meer tools betekent niet betere output.
Frameworkselectie doet er ook toe. Ik heb geprobeerd Claude Code te integreren met verschillende automatiseringsframeworks, en het patroon is consistent: degene die het best werken, zijn degene die één ding goed doen en schone, voorspelbare interfaces hebben. Degene die alles proberen te zijn -- uitgebreide AI-ontwikkelplatforms met zeventien functies -- veroorzaken doorgaans meer verwarring dan ze oplossen.
Eerlijke bekentenis: ik betrap mezelf nog steeds af en toe op het installeren van een glimmende nieuwe MCP-server omdat het nuttig klinkt, om het een week later weer te verwijderen als ik besef dat het latency toevoegt zonder waarde. De drang tot toolintegratie is moeilijk te beheersen zodra hij eenmaal is geactiveerd.
De echte opbrengst van Niveau 4 is niet een individuele tool. Het is de mentale verschuiving van "Claude verwerkt tekst" naar "Claude orkestreert workflows." Zodra je Claude ziet als een workflow-hub in plaats van een tekstgenerator, begin je anders over automatisering na te denken. En dat denken leidt direct naar Niveau 5.
Niveau 5: De Skills-Ontwikkelaar (Waar Herhaling Sterft)
Ik ga eerlijk zijn: Niveau 5 is waar ik het langst mee heb geworsteld, en het is ook waar ik de grootste duurzame productiviteitswinst heb gezien. Skills development in Claude Code is de praktijk van het omzetten van repetitieve prompt-workflows in herbruikbare, één-commando-automatiseringen.
Een skill, in Claude Code-termen, is in essentie een tekstgebaseerde prompt-workflow. Zie het als een macro, maar slimmer -- het is een gestructureerde instructieset die Claude volgt wanneer deze wordt geactiveerd, inclusief welke context te verzamelen, welke stappen uit te voeren en welk outputformaat te produceren.
Hier een concreet voorbeeld. Voordat ik skills maakte, zag mijn code review-workflow er zo uit: laad de gewijzigde bestanden, leg mijn reviewcriteria uit, vraag Claude om te controleren op beveiligingsproblemen, vraag dan naar prestatie-issues, dan naar patroon-compliance, dan naar testdekkingsgaten. Zes aparte prompts, elke keer weer. Soms vergat ik een stap. Soms formuleerde ik de criteria anders en kreeg ik inconsistente resultaten.
Mijn code review-skill comprimeerde dat tot één enkele trigger. Het laadt automatisch de diff, past mijn reviewcriteria toe in een consistente volgorde, controleert tegen mijn CLAUDE.md-conventies, en produceert een gestructureerd rapport met ernstclassificaties. Dezelfde kwaliteit elke keer. Nul vergeten prompts.
Skills Bouwen Die Daadwerkelijk Werken
De Skill Creator-tool binnen Claude Code helpt bij het bootstrappen van nieuwe skills, maar ik heb gemerkt dat de beste skills voortkomen uit organische evolutie in plaats van vooraf ontwerpen. Mijn proces:
Ten eerste voer ik een workflow drie of vier keer handmatig uit, waarbij ik noteer welke prompts ik gebruik en in welke volgorde. Ten tweede identificeer ik welke delen consistent zijn over alle runs en welke delen variëren. Ten derde bouw ik een skill die de consistente delen automatisch afhandelt en de variabele delen als parameters accepteert.
Mijn meestgebruikte skills op dit moment:
Project Bootstrap -- neemt een projectbeschrijving en genereert de bestandsstructuur, configuratiebestanden, CLAUDE.md-conventies en initiële boilerplate. Bespaart ongeveer 45 minuten per nieuw project.
API Endpoint Builder -- neemt een endpointspecificatie (route, methode, request/response-vormen) en genereert de handler, validatie, foutafhandeling, tests en documentatie. Volgt mijn vastgestelde patronen exact omdat de skill verwijst naar mijn architectuurconventies.
Deployment Preflight -- doorloopt een checklist van omgevingsvariabelen, databasemigraties, dependency audits en security scans voordat ik naar productie push. Deze heeft drie problemen gevangen die productie-incidenten zouden zijn geworden.
Bug Investigation -- neemt een foutmelding of bugreport, verzamelt relevante logs en codecontext, en produceert een gestructureerde analyse met waarschijnlijke oorzaken gerangschikt op waarschijnlijkheid.
Elk van deze skills kostte ongeveer een uur om te bouwen en te verfijnen. Ze verdienen dat uur binnen de eerste gebruiksweek terug.
De Skill Sprawl-Valkuil
Dit is de Niveau 5-valkuil, en ik ben er recht in gelopen: te veel skills maken.
Op mijn piek had ik drieëntwintig custom skills geconfigureerd. Drieëntwintig. Sommige overlapten in functionaliteit. Sommige waren zo specifiek dat ze op precies één project van toepassing waren. Een paar spraken elkaar op subtiele manieren tegen -- mijn "snelle API-endpoint"-skill gebruikte andere foutafhandelingsconventies dan mijn "productie API-endpoint"-skill, en ik kon me niet herinneren welke welke was.
Claude zelf raakte in de war. Als ik een taak triggerde die bij meerdere skills kon passen, daalde de outputkwaliteit omdat het systeem tegenstrijdige instructies probeerde te verzoenen. Het is hetzelfde principe als de MCP-overload in Niveau 4 -- meer is niet beter. Precies is beter.
Ik snoeide terug naar acht skills. Acht goed geteste, frequent gebruikte, niet-overlappende workflows die ongeveer 80% van mijn repetitieve taken dekken. De overige 20% handel ik af met ad-hoc prompts, en dat is prima. Niet alles hoeft geautomatiseerd te worden.
De snoei-criteria die ik gebruik: als ik een skill twee weken niet heb geactiveerd, wordt het gearchiveerd. Als twee skills meer dan 50% van hun stappen delen, worden ze samengevoegd. Als een skill output produceert die ik regelmatig moet bewerken, wordt het herschreven of verwijderd.
Skills zijn waar Claude Code de overgang maakt van "tool die ik gebruik" naar "systeem dat ik heb gebouwd." Ze zijn gepersonaliseerd, eigenwijs en gevormd door mijn specifieke ontwikkelpatronen. Niemand anders' skills zouden perfect voor mij werken, en de mijne zouden niet perfect voor iemand anders werken. Die personalisatie is het hele punt.
Maar zelfs met geweldige skills ben je nog steeds beperkt tot één Claude Code-instantie die één ding tegelijk doet. Die beperking doorbreken is waar Niveau 6 over gaat -- en eerlijk gezegd is het het niveau waar ik nog steeds actief mee aan het uitzoeken ben.
Niveau 6: De Claude Code Orchestrator (Waar het Echt Los Gaat)
Ik moet vooraf eerlijk zijn over iets: Niveau 6 is waar mijn vertrouwen daalt en mijn enthousiasme in gelijke mate stijgt. Het orkestreren van meerdere Claude Code-instanties tegelijkertijd is de frontier van wat mogelijk is, en het is oprecht krachtig, maar het is ook oprecht rommelig. Ik heb sessies gehad waar alles klikte en ik het gevoel had een ontwikkelteam aan te sturen vanuit één terminal. Ik heb ook sessies gehad waar drie agents conflicterende wijzigingen produceerden en ik meer tijd besteedde aan mergen dan ik aan coderen zou hebben besteed als ik het alleen had gedaan.
Dit is het concept. In plaats van één Claude Code-instantie die één taak tegelijk afhandelt, draait Niveau 6 om het parallel runnen van meerdere instanties, elk werkend aan een ander deel van het project. Eén agent handelt de backend-API af. Een andere bouwt de frontendcomponenten. Een derde schrijft tests. Ze werken gelijktijdig, in geïsoleerde omgevingen, en jij coördineert de resultaten.
De belangrijkste technische enabler is Git worktrees. Als je er niet bekend mee bent: een Git worktree laat je meerdere branches van dezelfde repository tegelijkertijd uitchecken in aparte mappen. Elke map is een volledig onafhankelijke werkkopie. Wijzigingen in de ene worktree beïnvloeden de andere niet totdat je ze expliciet merget.
Dit past perfect bij multi-agent workflows. Ik maak een worktree aan voor elke agent, wijs elke agent een specifiek werkgebied toe, en laat ze parallel draaien. Agent A werkt aan de API in worktree-api/. Agent B werkt aan de UI in worktree-ui/. Agent C werkt aan tests in worktree-tests/. Geen conflicten tijdens ontwikkeling omdat ze in aparte mappen zitten. Mergen als het klaar is.
Mijn Orkestratiewerkflow (Met Alle Onvolkomenheden)
Zo werkt een multi-agent sessie in de praktijk voor mij. Ik gebruik een recent project als voorbeeld -- het bouwen van een realtime dashboard met WebSocket-updates.
Stap 1: Ik maak drie Git worktrees aan vanuit de main branch.
git worktree add ../dashboard-api feature/api
git worktree add ../dashboard-ui feature/ui
git worktree add ../dashboard-tests feature/tests
Stap 2: Ik open drie terminalsessies, elk gericht op een andere worktree, elk met een eigen Claude Code-instantie.
Stap 3: Ik geef elke instantie een gerichte opdracht. De API-agent krijgt de WebSocket-serverspecificatie, de datamodellen en het eventschema. De UI-agent krijgt de componentontwerpen, de WebSocket-clientvereisten en de state management-aanpak. De test-agent krijgt het API-contract en het verwachte gedrag.
Stap 4: Ik laat ze draaien en check periodiek in. Dit is het deel dat voelt als het managen van een team. Je schrijft geen code -- je reviewt plannen, beantwoordt vragen en neemt architecturale beslissingen over drie parallelle stromen.
Stap 5: Als alle drie klaar zijn, merge ik. Dit is waar de realiteit rommelig wordt.
Het Merge-Probleem (En Waarom Ik Er Eerlijk Over Ben)
Het mergen van parallel agentwerk is de grootste uitdaging op Niveau 6. Zelfs met duidelijke scope-scheiding maken agents aannames. De API-agent kan een response-payload anders structureren dan wat de UI-agent verwacht. De test-agent kan assertions schrijven tegen een interface die tijdens de ontwikkeling is verschoven.
Mijn merge-slagingspercentage -- merges die nul handmatige conflictoplossing vereisten -- is ongeveer 60%. Vier van de tien keer besteed ik dertig minuten tot een uur aan het oplossen van integratieproblemen die niet zouden hebben bestaan als één agent alles sequentieel had gedaan.
Is de parallelle snelheid het waard? Voor grote features, ja. Het dashboardproject dat ik hierboven beschreef zou ongeveer twaalf uur hebben gekost met een enkele agent. De drie-agent-aanpak was klaar in ongeveer vijf uur wandtijd, inclusief een uur merge-oplossing. Netto besparing van zes uur. Voor dat project klopte de rekening.
Voor kleinere features? Eerlijk gezegd niet. De overhead van het opzetten van worktrees, het schrijven van aparte briefs en het afhandelen van merges vreet de tijdwinst op. Mijn vuistregel: als de taak minder dan drie uur zou kosten met een enkele agent, is multi-agent orkestratie de coördinatiekosten niet waard.
Sub-Agents en Agent Teams
Claude Code ondersteunt ook sub-agents -- het spawnen van een secundaire agent vanuit een primaire agentsessie om een deeltaak af te handelen. Dit heeft minder overhead dan volledige worktree-orkestratie maar is beperkter in scope. Ik gebruik sub-agents voor taken als "ga deze library's API onderzoeken en kom terug met een samenvatting" of "genereer de TypeScript types voor dit JSON-schema terwijl ik doorwerk aan de handler."
Agent teams zijn het meest experimentele deel van Niveau 6. Het concept is meerdere agents met gedefinieerde rollen -- een planner, een coder, een reviewer -- die werken in een gecoördineerde pipeline. Ik heb deze opzet drie keer getest. Twee keer produceerde het oprecht indrukwekkende resultaten, waarbij de reviewer-agent problemen vond die de coder-agent had gemist. Eén keer produceerde het een oneindige feedbackloop waarbij de reviewer steeds wijzigingen bleef vragen en de coder ze steeds bleef doorvoeren, tokens verbrandend zonder te convergeren.
Ik noem dit omdat ik vind dat het belangrijk is om eerlijk te zijn: agent teams zijn krachtig in theorie en onvoorspelbaar in de praktijk. De tooling verbetert snel. Maar op dit moment, begin 2026, behandel ik agent teams als experimenteel. Ik zou ze niet gebruiken voor klantwerk waar voorspelbaarheid telt. Voor persoonlijke projecten waar ik me kan veroorloven te experimenteren en af en toe een middag te verliezen aan een feedbackloop? Absoluut.
De Token-Realiteit
Multi-agent orkestratie verbrandt tokens. Snel. Drie agents die parallel draaien verbruiken drie keer de tokens van een enkele agent, uiteraard, maar de echte kosten zijn minder voor de hand liggend. Elke agent heeft zijn eigen context-setup nodig, zijn eigen CLAUDE.md-laden, zijn eigen oriëntatie op het project. Die gedupliceerde context-initialisatie telt op.
Ik volg mijn tokenverbruik per project, en multi-agent sessies kosten doorgaans 2,5-3x wat een single-agent sessie kost voor dezelfde feature. Niet 1x (de droom) en niet 3x (de naïeve aanname). De besparingen komen van gedeelde CLAUDE.md-bestanden en gefocuste, kleinere contexten per agent.
Of die kosten-prestatieverhouding werkt, hangt volledig af van je tijdseconomie. Voor klantwerk dat per uur wordt gefactureerd, rechtvaardigt de snelheidsverbetering de tokenkosten ruimschoots. Voor persoonlijke projecten met een beperkt budget ben ik selectiever over wanneer ik meerdere agents opstart.
De Mindsetverandering Die Alle Zes Niveaus Verbindt
Terugkijkend op mijn progressie doen de technische vaardigheden op elk niveau er minder toe dan de mindsetverandering die ze mogelijk maakt. En er loopt één enkele rode draad door alle zes overgangen: de verschuiving van bevelen naar samenwerken.
Op Niveau 1 beveel je Claude om output te produceren. Op Niveau 2 plan je samen. Op Niveau 3 cureer je context samen. Op Niveau 4 bouw je toolchains samen. Op Niveau 5 codificeer je workflows samen. Op Niveau 6 orkestreer je teams samen.
Elk niveau vereist dat je een beetje meer controle opgeeft en het systeem een beetje meer vertrouwt -- terwijl je tegelijkertijd geavanceerder wordt in hoe je het stuurt. Dat is de paradox. Je doet tegelijkertijd minder handmatig werk en past meer strategisch denken toe.
De ontwikkelaars die ik op Niveau 1 of 2 zie vastzitten, zitten daar bijna altijd vast vanwege een controleprobleem, niet een vaardigheidsprobleem. Ze willen niet investeren in context engineering omdat het als overhead voelt. Ze willen geen tools integreren omdat ze elke stap willen begrijpen. Ze willen geen meerdere agents draaien omdat ze niet persoonlijk elke regel output kunnen reviewen.
Deze instincten zijn niet fout -- het is professionele discipline die je goed dient wanneer je met de hand code schrijft. Maar ze worden beperkingen wanneer je rol verschuift van "persoon die code schrijft" naar "persoon die AI-systemen orkestreert die code schrijven." De vaardigheden zijn anders, en de mindset moet meeverschuiven.
Wat Er Daadwerkelijk Veranderde in Mijn Dagelijks Werk
De praktische impact van de overgang van Niveau 1 naar Niveau 6 is moeilijk te overschatten. Mijn projectopleveringstermijnen zijn met ongeveer 40% ingekort. Niet omdat elke individuele taak 40% sneller gaat -- sommige zijn sneller, sommige kosten evenveel tijd -- maar omdat de dode tijd tussen taken bijna is verdwenen. Contextwisselkosten daalden toen ik worktrees ging gebruiken. Herwerk daalde toen ik context goed begon te engineeren. Repetitieve taken verdwenen toen ik skills bouwde.
Mijn CLAUDE.md-bestanden zijn enkele van de meest waardevolle bestanden in mijn projecten geworden. Ze vertegenwoordigen gekristalliseerde architectuurkennis -- beslissingen die vroeger in mijn hoofd leefden, leven nu in een bestand dat elke Claude Code-sessie automatisch absorbeert. Nieuwe teamleden (mens of AI) kunnen het CLAUDE.md lezen en direct de conventies van het project begrijpen.
De /compact en /clear commando's zijn nu reflexmatig. Ik voer /compact uit op de manier waarop ik vroeger Cmd+S indrukte -- frequent, bijna onbewust, als hygiënegewoonte. Context rot is niet langer iets dat ik ervaar omdat ik het proactief voorkom in plaats van erop te reageren nadat de kwaliteit afneemt.
En mijn relatie met Claude Code zelf is veranderd. Ik denk er niet meer over als een tool. Tools zijn dingen die je oppakt en neerlegt. Claude Code is meer als een ontwikkelomgeving -- iets dat je configureert, aanpast en waarin je werkt. De investering in aanpassing rendeert steeds meer over tijd. Elke skill die ik bouw, elke CLAUDE.md-conventie die ik documenteer, elke MCP-server die ik integreer maakt elke toekomstige sessie productiever dan de vorige.
Dat samengestelde effect is de echte opbrengst van het doorlopen van alle zes niveaus. Niveau 1-productiviteit is lineair -- je krijgt eruit wat je erin stopt, elke keer. Niveau 6-productiviteit is exponentieel -- eerder werk versterkt toekomstig werk.
Jouw Zet
Ik ga niet doen alsof deze progressie snel of makkelijk is. Het kostte me ongeveer vier maanden om van Niveau 1 naar Niveau 6 te gaan, en ik verfijn mijn orkestratievaardigheden nog wekelijks. Sommige niveaus waren in dagen te klaren. Niveau 3 kostte drie weken. Niveau 6 is waarschijnlijk doorlopend -- ik denk niet dat iemand multi-agent orkestratie al volledig heeft beheerst, omdat de tooling sneller evolueert dan wie dan ook expertise kan opbouwen.
Maar je hoeft niet Niveau 6 te bereiken om enorme verbeteringen te zien. De overgang van Niveau 1 naar Niveau 3 -- van basale prompting naar context engineering -- zal je Claude Code-ervaring meer transformeren dan elke andere transitie. Als je na het lezen van dit artikel maar één ding doet, doe dan deze drie dingen in je volgende sessie:
Schakel Plan Mode in voor je volgende niet-triviale taak. Merk op hoe het gesprek verandert wanneer Claude met je plant in plaats van alleen maar uitvoert.
Maak een CLAUDE.md-bestand aan in je projectroot met tien specifieke codeerconventies. Kijk hoe Claude's output onmiddellijk aansluit bij jouw patronen.
Voer /compact uit na elke afgeronde deeltaak. Let op of het volgende antwoord scherper aanvoelt dan de antwoorden aan het einde van een lange, niet-gecomprimeerde sessie.
Die drie wijzigingen kosten vijftien minuten om te implementeren. Ze besparen je uren binnen de eerste week.
De vraag is niet of Claude Code op Niveau 6 kan opereren. Dat kan het -- de mogelijkheid is er al. De vraag is of jij bereid bent je workflow te laten meegroeien. En van iemand die die klim heeft gemaakt: het uitzicht van hier is elke ongemakkelijke overgang waard.
Laten We Samenwerken
Wil je AI-systemen bouwen, workflows automatiseren of je tech-infrastructuur opschalen? Ik help je graag.
- Fiverr (maatwerk builds & integraties): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (enterprise-oplossingen): ramlit.com
- ColorPark (design & branding): colorpark.io
- xCyberSecurity (beveiligingsdiensten): xcybersecurity.io
