BRAND: mejba.me TITLE: 10 Claude Code Features Most Developers Never Find SLUG: claude-code-hidden-features-guide PRIMARY KEYWORD: Claude Code features SECONDARY KEYWORDS: Claude Code commands, Claude Code tips, Claude Code automation META DESCRIPTION: 10 powerful Claude Code features most developers miss -- from /insights reports to parallel agent teams. Real tests, real workflows, real results. TAGS: Claude Code, AI Development, Developer Productivity, Automation, Guide CONTENT TYPE: Deep Dive CONTENT CLUSTER: Claude Code & AI Agents TRANSFORMATION GOAL: After reading, the reader will know how to use 10 advanced Claude Code features that dramatically change their daily workflow -- from automated code reviews to multi-agent orchestration.
Ik dacht dat ik Claude Code kende. Zes maanden dagelijks gebruik, honderden sessies, een complete contentoperatie die erdoorheen draaide. Ik had een gids met 50 tips geschreven die alles behandelde, van sneltoetsen tot context engineering. Ik was degene aan wie andere ontwikkelaars het vroegen als ze vastliepen.
Toen liet iemand me /insights zien en realiseerde ik me dat ik de helft van de tool onbenut had gelaten.
Het rapport dat het genereerde was geen generieke samenvatting. Het was een forensische analyse van mijn laatste dertig dagen -- elke dubbele inspanning, elke verspilde tokenlus, elk patroon waarbij ik steeds opnieuw iets uitlegde dat Claude al had moeten weten. Eén bevinding raakte me bijzonder hard: ik had handmatig hetzelfde driestaps code review-proces op elke PR uitgevoerd, terwijl één enkel commando het automatisch had kunnen doen met betere dekking. Die ontdekking alleen al bespaarde me ruwweg vier uur per week.
Wat volgde was een twee weken durende diepe duik in elk commando, elke modus en elke mogelijkheid die ik op de een of andere manier had gemist. Sommige van deze functies waren stilletjes uitgerold in updates waarvan ik de changelogs niet had gelezen. Andere waren er altijd al geweest, verborgen achter slash-commando's die ik nooit had geprobeerd. Een paar waren zo krachtig dat ik oprecht niet kon geloven dat ik zonder had gewerkt.
Hier zijn tien functies die veranderden hoe ik Claude Code gebruik. Geen tips. Geen snelkoppelingen. Complete mogelijkheden waarvan de meeste ontwikkelaars ofwel niet weten dat ze bestaan, ofwel niet hebben uitgevogeld hoe ze ze goed moeten gebruiken. Ik heb ze allemaal getest op echte projecten, en ik vertel je precies wat werkte, wat me verraste, en waar de ruwe randjes nog zitten.
De eerste herschreef mijn workflow al binnen twintig minuten na het uitvoeren.
1. Het Insights-rapport dat je blinde vlekken blootlegt
De meeste ontwikkelaars hebben nul zicht op hoe ze Claude Code daadwerkelijk gebruiken. Je weet ruwweg hoeveel sessies je draait. Je hebt een vaag idee van je tokenverbruik. Maar de specifieke patronen -- waar je tijd verspilt, welke taken je onnodig herhaalt, welke gewoontes je geld kosten -- blijven onzichtbaar.
Het /insights commando verandert dat. Het leest je sessiedata van de laatste dertig dagen en stelt een gedetailleerd HTML-rapport samen over je gebruikspatronen, kostenanalyse, toolgebruik en workflow-inefficienties. Zie het als een functioneringsgesprek, behalve dat de beoordelaar toegang heeft tot elke interactie die je met de tool hebt gehad.
Toen ik het voor het eerst uitvoerde, bracht het rapport drie patronen aan het licht die ik zelf nooit zou hebben ontdekt.
Het eerste was duplicatie. Ik had Claude steeds gevraagd om dezelfde test-boilerplate op te zetten voor verschillende projecten -- identieke Vitest-configuraties, identieke mock-setups, identieke assertiepatronen. Het insights-rapport markeerde dit en suggereerde een aangepaste skill te maken die het in één commando zou afhandelen. Ik bouwde die skill in vijftien minuten. Hij draait nu automatisch bij elk nieuw project.
De tweede bevinding was foutclustering. Ongeveer 40% van mijn sessiefouten kwamen van dezelfde oorzaak: uitputting van het contextvenster tijdens grote bestandsbewerkingen. Het rapport identificeerde niet alleen het probleem -- het deed specifieke aanbevelingen voor hooks om context automatisch te compacten voordat het plafond werd bereikt. Ik implementeerde de hook diezelfde middag, en die fouten daalden tot bijna nul.
De derde was degene die pijn deed: het rapport toonde aan dat ik gemiddeld twaalf minuten per sessie besteedde aan het opnieuw uitleggen van projectconventies die in mijn CLAUDE.md-bestand hadden moeten staan. Twaalf minuten. Verspreid over vijf tot zes sessies per dag. Dat is meer dan een uur dagelijkse verspilling aan iets dat een toevoeging van twintig regels aan mijn configuratiebestand zou oplossen.
Het insights-rapport splitst ook je uitgaven uit per modeltier, toont welke tools je het meest gebruikt (en welke je nooit aanraakt), en identificeert sessies waarin je een goedkoper model had kunnen gebruiken zonder kwaliteitsverlies. Voor iedereen die serieus geld uitgeeft aan Claude Code -- Max-abonnees die tokens verbranden op complexe projecten -- verdient deze data zich onmiddellijk terug.
Voer /insights één keer uit. Lees het volledige rapport. Voer het daarna maandelijks uit. De patronen die het oppikt zijn niet zichtbaar vanuit individuele sessies. Je hebt het dertigdagenoverzicht nodig om ze te zien.
Maar inefficienties identificeren is slechts de helft van de vergelijking. De volgende functie laat je precies bepalen hoe hard Claude over je problemen nadenkt -- en de meeste mensen laten het op de verkeerde instelling staan.
2. Effort Control: stop met te veel betalen voor eenvoudige taken
Hier is iets dat ik maandenlang fout deed: ik voerde elke prompt uit met dezelfde verwerkingsintensiteit. Een simpele variabele hernoemen kreeg dezelfde diepe redeneerketen als een complexe architectuurrefactoring. Dat is alsof je een constructie-ingenieur inhuurt om een schilderij op te hangen.
Het /effort commando laat je de redeneerintensiteit van Claude omhoog of omlaag schalen over vijf niveaus: low, medium, high, max en auto. Elk niveau verandert hoe diepgaand Claude je verzoek analyseert voordat het reageert -- en cruciaal, hoeveel tokens het daarbij verbruikt.
Per maart 2026 heeft Anthropic het standaard effort-niveau voor Max- en Team-abonnees gewijzigd van high naar medium. Als je die wijziging niet had opgemerkt, heb je misschien het gevoel gehad dat Claude recentelijk iets minder grondig werd. Dat klopt. Met opzet. Omdat medium de meerderheid van ontwikkelingstaken prima afhandelt, en high onnodig tokens verbrandde op eenvoudig werk.
Hier is hoe ik mijn gebruik heb gekalibreerd na uitgebreid testen van elk niveau:
Low effort werkt voor bestandszoekopdrachten, simpele hernoemingen, opmaakcorrecties en snelle opzoekingen. Claude scant het verzoek en reageert snel. Tokenkosten zijn minimaal. Ik gebruik dit ongeveer 20% van de tijd.
Medium effort handelt de meeste coderingstaken af: goed gedefinieerde features implementeren, tests schrijven tegen bestaande code, refactoren met duidelijke patronen. Dit is mijn standaard, en het is de juiste standaard voor waarschijnlijk 60% van het ontwikkelwerk.
High effort is waar Claude echt diep begint na te denken. Complexe bugonderzoeken over meerdere bestanden. Architectuurbeslissingen met afwegingen. Beveiligingsreviews. Code die begrip vereist van subtiele interacties tussen systemen. Ik schakel over naar high voor kritieke reviews, productiedeployments en alles waarbij een gemiste randcase duur zou zijn. Ongeveer 15% van mijn werk.
Max effort activeert de diepste beschikbare redenering -- uitgebreid denken met volledige gedachteketen. Ik reserveer dit voor echte moeilijke problemen: race conditions debuggen, systemen ontwerpen vanuit vage requirements, beveiligingskritieke code reviewen. Het gebruiken voor routinetaken is verspilling. Ongeveer 5% van mijn sessies.
Auto laat Claude beslissen op basis van de complexiteit die het detecteert in je prompt. Ik heb dit uitgebreid getest, en het is verrassend accuraat in het matchen van effort aan taakcomplexiteit. Als je niet wilt nadenken over effort-niveaus, is auto een solide hands-off keuze.
De praktische impact is echt. Na het overschakelen van een impliciet high als standaard naar bewust effort-management, daalde mijn tokenverbruik met ruwweg 30% zonder meetbaar kwaliteitsverlies voor routinetaken. De dure redenering wordt alleen geactiveerd wanneer het echt nodig is.
Eén workflowpatroon dat bijzonder goed werkt: begin een complex onderzoek op high, krijg de diagnose, schakel dan over naar medium voor de implementatie. Het zware denkwerk gebeurt één keer. De uitvoering loopt lean.
Effort-management gaat over precisie. Maar de volgende functie gaat over vrijheid -- specifiek de vrijheid om weg te lopen van je bureau zonder een sessie te verliezen.
3. Remote Control: je terminalsessie, overal
Ik schreef een uitgebreide deep dive over Remote Control toen het in februari 2026 werd gelanceerd, dus ik ga hier niet elk detail herhalen. Maar het hoort op deze lijst omdat de meeste ontwikkelaars die ik spreek het ofwel niet hebben geprobeerd, ofwel verkeerd begrijpen wat het eigenlijk doet.
De korte versie: typ /rc in een actieve Claude Code-sessie. Er verschijnt een QR-code. Scan deze met de Claude-app op je telefoon. Je hebt nu volledige bidirectionele controle over die terminalsessie vanaf je mobiele apparaat. Berichten lezen, bestandsbewerkingen goedkeuren, nieuwe instructies sturen -- allemaal terwijl je lokale omgeving precies blijft draaien zoals het was.
De architectuur is belangrijk. Je sessie blijft lokaal. Je bestandssysteem, MCP-servers, projectconfiguratie, aangepaste tools -- niets verhuist naar de cloud. Remote Control opent een beveiligd venster naar je bestaande sessie via TLS, met kortlevende credentials die beperkt zijn tot die verbinding. Het is geen cloud IDE. Het is een remote viewport.
Waar dit mijn workflow veranderde: langlopende taken. Ik start een complexe refactoring of een volledige testsuite, en loop dan weg om te lunchen, de hond uit te laten, of naar een andere kamer te gaan. Vanaf mijn telefoon kan ik de voortgang monitoren, wijzigingen goedkeuren of afwijzen, en vervolginstructies sturen. Als ik terugkom aan mijn bureau, staat de sessie precies waar ik hem had achtergelaten.
De beperking is wel echt. Je machine moet aan blijven staan en je terminal moet open blijven. Klap je laptop dicht, en de sessie eindigt. Dit is niet "start een taak en kom morgen terug." Het is "loop weg van je bureau zonder de flow te breken." Dat onderscheid laat mensen struikelen.
Remote Control vereist een Max-abonnement en werkt via claude.ai/code en de Claude iOS/Android-apps. Als je een Pro-abonnement hebt, heeft Anthropic aangegeven dat bredere toegang eraan komt, maar per maart 2026 is het nog steeds alleen voor Max.
Voor degenen die wel toegang hebben, elimineert het stilletjes een van de meest frustrerende patronen in AI-ondersteunde ontwikkeling: de gedwongen keuze tussen productief zijn en aanwezig zijn aan je bureau. Ik gebruik het bijna dagelijks, en de vrijheid die het creëert is moeilijk te overschatten.
Weglopen van je bureau is één soort vrijheid. De volgende functie geeft je een ander soort -- de mogelijkheid om enorme hoeveelheden werk tegelijk naar Claude te gooien.
4. Batch Command: parallelle uitvoering op schaal
Het /batch commando is waar Claude Code stopt met aanvoelen als een codeerassistent en begint aan te voelen als een deployment-pipeline.
Hier is het scenario dat me de kracht ervan deed begrijpen. Ik had een codebase met 23 React-componenten die gemigreerd moesten worden van een oude stylingaanpak naar een nieuw design token-systeem. Elk component was onafhankelijk -- geen gedeelde state, geen kruisafhankelijkheden. In de oude workflow zou ik ze sequentieel hebben gedaan: component openen, het migratiepatroon uitleggen, Claude laten refactoren, reviewen, door naar de volgende. Met misschien tien minuten per component is dat bijna vier uur saai, repetitief werk.
Met /batch beschreef ik het migratiepatroon één keer en vertelde Claude het toe te passen op alle 23 componenten in parallel. Het ontleedde het werk in onafhankelijke eenheden, startte geïsoleerde worktree-agents voor elk, en voerde de migraties gelijktijdig uit. Elke agent werkte in zijn eigen git worktree, dus er was nul risico op conflicterende bewerkingen. Toen de batch klaar was, had ik 23 pull requests -- één per component -- klaar voor review.
Totale tijd: ongeveer achttien minuten. Geen vier uur. Achttien minuten.
Het commando ondersteunt zowel parallelle als sequentiële uitvoeringsmodi. Parallel is voor onafhankelijke taken zoals de migratie hierboven. Sequentieel is voor taken met afhankelijkheden -- waar stap 2 de output van stap 1 nodig heeft. Je specificeert de modus, beschrijft het werk, en Claude handelt de orchestratie af.
Voor contentmakers is batchverwerking even krachtig. Ik heb het gebruikt om meerdere blogpostconcepten tegelijkertijd te genereren, elk gericht op een ander trefwoordcluster, met aparte onderzoekscontexten voor elk. De agents delen geen context, dus er is geen kruisbesmetting tussen onderwerpen.
De GitHub-integratie is het onderdeel dat het productierijp maakt. Elke batch-eenheid kan automatisch een branch aanmaken, wijzigingen committen en een PR openen. Voor een migratie die tientallen bestanden beïnvloedt, betekent dit dat je een schone PR krijgt per logische werkeenheid in plaats van één massief, onreviewbaar pull request. Code reviewers waarderen dit meer dan je misschien denkt.
Batchverwerking heeft ruwe randjes. Complexe taken met subtiele onderlinge afhankelijkheden hebben soms handmatige interventie nodig wanneer Claude's afhankelijkheidsdetectie een verbinding mist. En de tokenkosten schalen lineair -- 23 agents starten betekent betalen voor 23 agents. Maar voor werk dat echt parallelliseerbaar is, zijn de tijdbesparingen transformatief.
Batch handelt kwantiteit af. De volgende functie handelt kwaliteit af -- en doet dat door drie critici tegelijkertijd op je code los te laten.
5. Simplify: drie-agent code review in één commando
Ik deed code reviews vroeger op de handmatige manier: door wijzigingen lezen, controleren op duplicaties, zoeken naar bugs, nadenken over performance. Het vergde echte cognitieve inspanning, en ik zal eerlijk zijn -- ik miste dingen. Dat doet iedereen. Menselijke aandacht is inconsistent, vooral bij de derde review van de dag.
/simplify vervangt dat proces met een drie-agent pipeline die gelijktijdig draait. Elke agent heeft een apart focusgebied:
Agent 1: Duplicatiedetectie. Scant op herhaalde logica, gekopieerde patronen en mogelijkheden om gedeelde functies te extraheren. Deze agent ontdekte iets in mijn codebase waar ik wekenlang langs was gelopen -- drie aparte API-routehandlers die elk hun eigen rate-limiting logica implementeerden in plaats van de middleware te gebruiken die ik al had gebouwd.
Agent 2: Bug- en foutanalyse. Zoekt naar logicafouten, randgevallen, null reference-risico's en onjuiste aannames. Het werkt meer als een beveiligingsgerichte reviewer dan als een linter -- het controleert geen syntax, het controleert redenering. Bij een recent project markeerde het een race condition in mijn databasetransactie-handler die zich alleen zou manifesteren bij gelijktijdige schrijfbewerkingen. Dat had ik nooit ontdekt in een handmatige review.
Agent 3: Efficiëntiereview. Evalueert performancekenmerken, identificeert onnodige berekeningen, signaleert N+1-queries en suggereert structurele verbeteringen. Deze agent adviseerde om een synchrone bestandsverwerkingspipeline om te zetten naar streaming, wat het geheugengebruik bij grote uploads met ruwweg 70% verminderde.
De drie agents draaien parallel, verzamelen hun bevindingen, en dan -- dit is het kernpunt -- past /simplify automatisch de fixes toe. Niet alleen suggesties. Daadwerkelijke codewijzigingen. Je reviewt de diffs achteraf, wat veel efficiënter is dan een lijst met aanbevelingen lezen en ze zelf implementeren.
Ik heb /simplify geïntegreerd in mijn pre-PR workflow. Voordat ik een pull request open, voer ik het één keer uit. De agents vinden consequent problemen die ik had gemist. Niet altijd kritieke -- soms is het gewoon een helperfunctie die geëxtraheerd kon worden, of een variabelenaam die misleidend is. Maar het cumulatieve effect is schonere, beter onderhoudbare code die naar productie gaat.
Eén kanttekening: /simplify is ontworpen als een kwaliteitspoort vóór PR's, niet als een tool tijdens de ontwikkeling. Het uitvoeren tijdens de implementatie creëert onnodige ruis omdat het code reviewt die nog niet af is. Wacht tot je klaar bent om te committen, en voer het dan uit. De bevindingen zijn zinvoller tegen voltooid werk.
Drie agents die je code reviewen is indrukwekkend. De volgende functie gaat verder met automatisering -- het verandert Claude Code in een geplande werker die zonder jou draait.
6. Loop: cron jobs in je terminal
Het /loop commando veranderde Claude Code van een tool die ik gebruik in een tool die voor mij werkt terwijl ik andere dingen doe.
Het concept is simpel: je geeft Claude een prompt en een tijdsinterval, en het voert die prompt herhaaldelijk uit op schema zolang je sessie actief blijft. Het is in wezen een cron job die in je Claude Code-terminal draait.
/loop 3h check my email inbox via the Gmail MCP and summarize any new messages from clients
Dat draait elke drie uur. Claude controleert op nieuwe e-mails, vat ze samen en presenteert de resultaten. Ik zet dit op maandagochtenden op en het vangt klantberichten op die ik anders uren niet zou bereiken.
Maar de krachtigere use cases zijn ontwikkelingsgericht. Hier zijn de loops die ik regelmatig draai:
Deployment-monitoring: /loop 30m check the production error logs for any new 500 errors and summarize the stack traces. Dit draait elke dertig minuten tijdens kantooruren. Wanneer een fout productie bereikt, weet ik het voordat klanten het melden.
PR review-herinnering: /loop 2h check our GitHub repo for any open PRs that have been waiting for review for more than 24 hours and list them. Dit voorkomt dat onze reviewwachtrij stagneert. Het team is merkbaar sneller geworden met reviewen sinds ik dit heb opgezet.
Afhankelijkheidscontroles: /loop 6h scan package.json for any dependencies with known security vulnerabilities using the npm audit tool. Eén keer per dag is waarschijnlijk genoeg voor de meeste teams, maar ik draai het vaker bij projecten met snelle afhankelijkheidswijzigingen.
De kritieke beperking: loops draaien alleen terwijl je sessie actief is. Sluit de terminal, en de loop stopt. Dit is geen achtergrondservice. Het is een sessie-gebonden automatisering. Voor persistente geplande taken heb je echte cron jobs nodig of een tool zoals het /schedule commando voor remote triggers. Maar voor werkdagautomatisering -- de acht tot tien uur dat je actief ontwikkelt -- is /loop opmerkelijk nuttig.
Ik heb ook loops gekoppeld aan hooks (die we hierna behandelen) om geautomatiseerde workflows te creëren. Een loop controleert op een voorwaarde, en wanneer de voorwaarde is vervuld, triggert een hook een actie. Loop detecteert een nieuwe PR, hook draait /simplify er automatisch op. Die combinatie veranderde code review van een handmatig proces in een semi-geautomatiseerd proces.
Er is één gedrag om op te letten: loops verbruiken tokens bij elke uitvoering. Een prompt die 5.000 tokens per keer gebruikt, elke dertig minuten over een werkdag van acht uur, kost 80.000 tokens. Dat telt op. Ik houd mijn loop-prompts mager en gefocust om verrassingsrekeningen te voorkomen.
Loops automatiseren op schema. De volgende functie automatiseert op events -- en het is een van de meest ondergewaardeerde mogelijkheden in het hele platform.
7. Hooks: de automatiseringslaag die de meeste mensen negeren
Hooks zijn configureerbare acties die worden uitgevoerd voor of na het gebruik van specifieke tools door Claude Code. Ze worden gedefinieerd in je .claude/settings.json-bestand en kunnen fundamenteel veranderen hoe je hele workflow opereert.
Zie hooks als Git hooks, maar dan voor AI-toolgebruik. Je kunt shell-commando's triggeren, regels afdwingen, validaties uitvoeren of geautomatiseerde acties uitvoeren telkens wanneer Claude een bestand leest, code schrijft, een commando uitvoert of interactie heeft met een van de negentien ondersteunde tool-events.
Hier is een praktisch voorbeeld. Ik heb een hook die draait voor elke bestandsschrijfactie:
{
"hooks": {
"preToolUse": [
{
"matcher": "write",
"command": "echo 'Checking file size and backup...'"
}
]
}
}
Dat is een vereenvoudigde versie. Mijn daadwerkelijke hook controleert de grootte van het doelbestand, maakt een back-up met tijdstempel in een .backups-directory, en valideert dat de schrijfactie een geconfigureerde maximale bestandslengte niet overschrijdt. Dit alles gebeurt automatisch voordat Claude ook maar één regel schrijft.
De hooks die ik in de praktijk het meest waardevol heb gevonden:
Merkstemafdwinging. Voor mijn contentworkflow heb ik een post-write hook die gegenereerde content scant op verboden zinnen (de AI-achtig klinkende zoals "in today's fast-paced world" of "it's important to note") en ze markeert voordat het bestand wordt opgeslagen. Dit vangt stijlinconsistenties op die anders handmatige bewerking zouden vereisen.
Tokenkostenbeheer. Een pre-tool hook die de tokenkosten van de huidige operatie inschat en me waarschuwt als het een drempel overschrijdt. Dit voorkomt ongecontroleerd tokenverbruik tijdens grote batchoperaties. Ik heb de drempel ingesteld op 50.000 tokens per enkele toolaanroep -- alles daarboven krijgt een bevestigingsprompt.
Automatische opmaak. Een post-write hook die Prettier draait op elk TypeScript- of JavaScript-bestand dat Claude wijzigt. De code wordt opgemaakt geleverd zonder dat ik erover nadenk.
Testvalidatie. Een post-write hook op testbestanden die automatisch de relevante testsuite draait nadat Claude tests schrijft of wijzigt. Als de tests falen, stuurt de hook de foutoutput terug naar het gesprek zodat Claude het probleem onmiddellijk kan oplossen. Dit creëert een strakke schrijf-test-fix lus zonder handmatige interventie.
De zelfverbeterende systeemsbenadering waarover ik eerder schreef, kan gedeeltelijk worden geïmplementeerd met alleen hooks. Een hook die de kernbeslissingen van elke sessie logt, gekoppeld aan een loop die die logs periodiek reviewt op patronen, creëert een lichtgewicht feedbacksysteem dat continu je workflow verbetert.
Hooks zijn krachtig juist omdat ze onzichtbaar zijn tijdens normaal gebruik. Eenmaal geconfigureerd draaien ze stil op de achtergrond, handhaven je regels en automatiseren je processen zonder dat het enige aandacht vereist. De setupkosten zijn een eenmalige investering. Het rendement is permanent.
Over onzichtbaar gesproken -- de volgende functie is zo subtiel dat de meeste ontwikkelaars niet eens weten dat het commando bestaat.
8. Rewind Mode: ongedaan maken zonder paniek
Elke ontwikkelaar die AI-ondersteund codeert heeft dit moment meegemaakt: Claude brengt een reeks wijzigingen aan over meerdere bestanden, je realiseert halverwege dat de aanpak verkeerd is, en nu staar je naar een puinhoop van gewijzigde bestanden terwijl je probeert uit te zoeken wat waar is veranderd.
Git kan helpen. Maar individuele commits terugdraaien wanneer Claude wijzigingen heeft aangebracht over één gespreksturn is vervelend. En als je nog niet hebt gecommit, wordt git checkout een bot instrument dat dingen ongedaan kan maken die je wilde behouden.
Rewind Mode biedt een chirurgisch alternatief. Druk twee keer op Esc om het rewind-menu te openen, en je krijgt twee opties:
Alleen gesprek terugdraaien -- draait het gesprek terug naar een eerdere staat terwijl alle codewijzigingen behouden blijven. Handig wanneer Claude een verkeerd verklaringspad insloeg maar de daadwerkelijke codewijzigingen in orde waren.
Alleen code terugdraaien -- draait bestandswijzigingen terug terwijl de gespreksgeschiedenis behouden blijft. Dit is degene die ik het meest gebruik. Claude probeerde een aanpak, de code werkte niet, maar de gesprekscontext (de probleembeschrijving, de beperkingen, de mislukte poging) is waardevol voor de volgende poging. Ik draai de code terug, houd de context, en stuur bij: "Die aanpak had X probleem. Probeer Y in plaats daarvan."
De combinatie is krachtig voor experimenteel ontwikkelen. Ik vertel Claude om een riskante refactoring te proberen, wetende dat als het niet werkt, ik de codewijzigingen in seconden kan terugdraaien. Dit verandert hoe je speculatief werk benadert -- de kosten van iets proberen dalen tot bijna nul wanneer ongedaan maken instant is.
Voordat rewind bestond, deed ik dit handmatig: committen voor elke grote Claude-operatie, en dan cherry-picken of reverten als het fout ging. Dat werkte, maar het vervuilde mijn git-geschiedenis met checkpoint-commits die daar niets te zoeken hadden. Rewind houdt experimenten volledig buiten je versiegeschiedenis.
Eén ding om te begrijpen: rewind werkt op gespreksturen, niet op individuele bestandswijzigingen. Als Claude vijf bestanden wijzigde in één turn, draait rewind alle vijf terug. Je kunt niet selectief bestand drie terugdraaien terwijl je bestanden een, twee, vier en vijf behoudt. Daarvoor heb je nog steeds git nodig.
Maar voor het veel voorkomende geval -- "die hele aanpak was fout, laten we iets anders proberen" -- is rewind precies de juiste tool. Snel, schoon en veel minder stressvol dan handmatige rollbacks.
Rewind handelt fouten af nadat ze zijn gebeurd. De volgende functie handelt vragen af die opkomen terwijl je midden in iets anders zit.
9. Het /btw commando: zijvragen zonder je sessie te ontsporen
Dit werd gelanceerd op 10 maart 2026, met Claude Code v2.1.72, en het loste een frustratie op waar ik maandenlang mee leefde zonder te beseffen dat er een oplossing was.
Het scenario: je zit diep in een debugsessie. Claude volgt een complexe keten van functieaanroepen over meerdere bestanden. Je hebt vijftien beurten context opgebouwd, en het gesprek is gefocust en productief. Dan schiet er een gedachte door je hoofd -- "wacht, hoeveel contexttokens heb ik nog over?" of "wat is de aanbevolen aanpak voor X?" -- maar die vraag stellen in de hoofdthread zou de hele debugflow ontsporen.
Vóór /btw had je twee slechte opties. De vraag stellen en accepteren dat Claude's aandacht zou verschuiven naar het beantwoorden ervan, met het risico de draad van de debugsessie te verliezen. Of een nieuwe terminal openen, een nieuwe sessie starten en daar vragen -- context verliezen en betalen voor een hele nieuwe sessie-initialisatie.
/btw creëert een zijkanaal. Je stelt je vraag, Claude beantwoordt hem, en het hoofdgesprek gaat verder vanaf precies waar het was. De zijvraag wordt geen onderdeel van de hoofdthread. Het beïnvloedt Claude's redenering over de hoofdtaak niet. Het is een echte tussenvoeging -- erkend, beantwoord en terzijde gelegd.
/btw how many context tokens are remaining in this session?
Claude antwoordt. Dan gaat je volgende prompt verder met de debugsessie alsof de zijvraag nooit is gesteld.
Ik gebruik /btw consequent voor drie dingen:
Contextmonitoring. Resterende tokens checken midden in een sessie zonder de flow te verstoren. Dit is vooral belangrijk tijdens lange sessies waar ik moet weten of ik moet compacten of doorgaan.
Snelle verduidelijkingen. "Wat is de syntax voor X in dit framework?" wanneer ik een snel antwoord nodig heb maar de probleemoplossende keten niet wil breken.
Metavragen over de sessie. "Houd je de drie beperkingen bij die ik eerder noemde?" -- een sanity check dat Claude's context intact is, zonder de hoofdthread te vervuilen met metadiscussie.
Het is een kleine functie. Het soort dat geen koppen haalt. Maar het neemt een echt wrijvingspunt weg uit lange sessies, en lange sessies zijn waar het meest waardevolle werk plaatsvindt. Alles wat de integriteit van een diep, gefocust gesprek beschermt, is de moeite waard om te weten.
We hebben negen functies behandeld tot nu toe. De tiende is de grootste. Het is geen commando -- het is een paradigmaverschuiving in hoe Claude Code werkt. En als je Claude als solo-assistent hebt gebruikt, zal dit je mentale model volledig veranderen.
10. Parallelle agentteams: van solo-assistent naar compleet dev-team
Alles tot nu toe behandelt Claude Code als een enkele entiteit. Eén agent, één gesprek, één stroom werk. Parallelle agents breken dat model volledig.
Wanneer je agentteams opstart, draait Claude Code niet slechts één sessie. Het lanceert meerdere onafhankelijke sessies -- elk met een eigen contextvenster, een eigen rol en een eigen deel van het werk. Een lead-agent coördineert het team, delegeert taken en synthetiseert resultaten. Teamgenoot-agents voeren onafhankelijk uit, rapporteren terug en communiceren zelfs met elkaar.
Dit is niet hetzelfde als sub-agents. Het onderscheid is belangrijk, en ik raakte er aanvankelijk door in de war, dus laat me precies zijn.
Sub-agents opereren binnen een enkele Claude Code-sessie. De bovenliggende agent start ze om specifieke taken af te handelen, maar ze delen de algehele context van de sessie en opereren binnen de beperkingen ervan. Ze zijn handig voor het parallelliseren van werk binnen een begrensde scope -- zoals de agent swarm-architectuur die ik eerder behandelde.
Parallelle agentteams zijn fundamenteel anders. Elke teamgenoot is een volledig onafhankelijke Claude Code-sessie met een eigen contextvenster van 200K tokens. Ze delen geen context met de lead-agent of met elkaar -- ze communiceren door expliciete berichtuitwisseling. Dit betekent dat een teamgenoot een hele codebase aan context kan vasthouden voor zijn specifieke domein zonder tokens te verbruiken uit het venster van iemand anders.
Ik testte dit op een project dat drie dingen tegelijk nodig had: een backend API-herontwerp, een frontend component-refactoring en een uitgebreide testsuite-update. In het oude model zou ik deze sequentieel aanpakken -- API eerst, dan frontend, dan tests -- omdat een enkele agent niet genoeg context kon vasthouden voor alle drie tegelijkertijd.
Met parallelle agents startte ik drie teamgenoten:
- Backend Agent: Volledige context over de API-laag, databaseschema's en routehandlers
- Frontend Agent: Volledige context over de React componentboom, state management en UI-patronen
- Test Agent: Volledige context over de bestaande testinfrastructuur, mock-setup en dekkingsvereisten
De lead-agent coördineerde: "Backend is het user endpoint aan het herontwerpen. Frontend, wacht op het nieuwe API-contract voordat je het user profile-component bijwerkt. Test agent, begin met het schrijven van integratietest-stubs op basis van de huidige specificatie -- we vullen de assertions in zodra de API is afgerond."
Elke agent werkte in zijn eigen worktree. Geen merge conflicts. Geen contextcontaminatie. De backend-agent kon de hele API-laag in zijn contextvenster laden omdat het niet ook frontend-code vasthield. De test-agent kon de volledige testsuite analyseren zonder de implementatiecontext te verdringen.
Het resultaat was ruwweg 3x de doorvoer vergeleken met sequentieel single-agent werk. Niet omdat elke individuele agent sneller was, maar omdat drie agents die gelijktijdig werken met volledige context in hun respectieve domeinen categorisch anders is dan één agent die tussen domeinen wisselt.
Het communicatiemodel is wat het laat werken. Teamgenoten hebben geen directe toegang tot elkaars context, maar ze kunnen gestructureerde berichten sturen via de lead-agent. Toen de backend-agent het nieuwe API-contract afrondde, stuurde het de endpointspecificaties naar de lead, die ze doorstuurde naar de frontend- en test-agents. Elke agent incorporeerde de informatie in zijn eigen context zonder het domeinspecifieke kennis te verliezen dat het al had opgebouwd.
Dit is de functie die me deed heroverwegen wat Claude Code eigenlijk is. Het is geen assistent meer. Het is een platform voor het draaien van AI-ontwikkelteams. De mentale modelverschuiving -- van "ik heb een heel slimme helper" naar "ik manage een team van specialisten" -- verandert hoe je werk plant, hoe je problemen ontleedt en wat je als haalbaar beschouwt voor een enkele ontwikkelsessie.
Als je liever iemand hebt die dit soort multi-agent workflow helemaal opzet, neem ik Claude Code automatiserings- en agentarchitectuuropdrachten aan. Je kunt zien wat ik heb gebouwd op fiverr.com/s/EgxYmWD.
De tokenkosten schalen met het aantal agents, uiteraard. Drie teamgenoten betekent ruwweg drie keer het tokenverbruik. Maar voor complexe projecten waar het alternatief toch sequentieel werk over meerdere sessies is, zijn de totale kosten vaak vergelijkbaar -- je geeft ze alleen parallel uit in plaats van verspreid over dagen.
Wat deze functies gemeen hebben: een filosofie van samengesteld rendement
Individueel lost elk van deze tien functies een specifiek probleem op. Insights toont waar je inspanning verspilt. Effort control voorkomt overbesteding aan simpele taken. Remote Control bevrijdt je van je bureau. Batchverwerking paralleliseert repetitief werk. Simplify vangt bugs die je zou missen. Loop automatiseert terugkerende controles. Hooks handhaven regels stil. Rewind elimineert de kosten van experimenteren. /btw beschermt diepe focus. Parallelle agents vermenigvuldigen je doorvoer.
Gestapeld transformeren ze Claude Code van een slimme autocomplete naar iets dat meer lijkt op een engineeringafdeling.
Het samengestelde effect is waar de echte waarde leeft. Hooks triggeren op door loop gedetecteerde condities. Insights-data informeert je effort-kalibratie. Batchoperaties profiteren van simplify als naverwerkinsstap. Parallelle agents gebruiken rewind onafhankelijk wanneer individuele aanpakken falen. Elke functie versterkt de andere.
De meeste ontwikkelaars die ik spreek gebruiken misschien drie of vier Claude Code-commando's regelmatig. Ze weten hoe ze moeten promoten, reviewen en bewerkingen goedkeuren. Dat is alsof je een professionele camera koopt en alleen de automatische modus gebruikt. De mogelijkheden zijn er. De investering om ze te leren wordt gemeten in uren. Het rendement wordt gemeten in weken teruggewonnen tijd.
Mijn uitdaging aan jou: kies één functie van deze lijst die je niet hebt gebruikt. Probeer het bij je volgende project. Niet op een speelgoedvoorbeeld -- op echt werk. Geef het één eerlijke poging en kijk wat er verandert.
Op basis van wat ik heb gezien uit mijn eigen workflow -- en uit het insights-rapport waarmee deze hele reis begon -- ga je niet meer terug naar werken zonder.
Veelgestelde vragen
Hoe voer ik het Claude Code insights-rapport uit?
Typ /insights in een actieve Claude Code-sessie. Het analyseert je gebruik van de laatste 30 dagen en genereert een HTML-rapport over patronen, kosten, toolgebruik en workflow-inefficienties. Geen configuratie nodig -- het leest automatisch je bestaande sessiegeschiedenis.
Wat is het verschil tussen Claude Code sub-agents en parallelle agentteams?
Sub-agents opereren binnen een enkele sessie en delen context met de bovenliggende agent. Parallelle agentteams lanceren volledig onafhankelijke sessies, elk met een eigen contextvenster van 200K tokens, die communiceren via expliciete berichtuitwisseling. Teams zijn geschikt voor grotere, complexere projecten waar domeinisolatie belangrijk is.
Werkt Claude Code Remote Control op mobiel?
Ja. Remote Control werkt via claude.ai/code en de Claude iOS- en Android-apps. Je sessie blijft lokaal draaien op je machine terwijl je via de mobiele interface interactie hebt. Het vereist een Max-abonnement per maart 2026.
Hoeveel kosten parallelle agents aan tokens?
Tokenkosten schalen lineair met het aantal agents. Drie parallelle agents verbruiken ruwweg drie keer de tokens van een enkele agent. De totale projectkosten zijn echter vaak vergelijkbaar met sequentieel werk, aangezien je consolideert wat anders meerdere aparte sessies zouden zijn.
Kan ik /loop commando's permanent op de achtergrond draaien?
Nee. Loop-commando's worden alleen uitgevoerd terwijl je Claude Code-sessie actief is. Het sluiten van de terminal stopt alle loops. Voor persistente geplande automatisering, gebruik het /schedule commando dat remote triggers creëert die op een cron-schema draaien, onafhankelijk van je lokale sessie.
Let's Work Together
Looking to build AI systems, automate workflows, or scale your tech infrastructure? I'd love to help.
- Fiverr (custom builds & integrations): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (enterprise solutions): ramlit.com
- ColorPark (design & branding): colorpark.io
- xCyberSecurity (security services): xcybersecurity.io
