Hoe de maker van Claude Code het dagelijks gebruikt

Hoe de maker van Claude Code het dagelijks gebruikt

Boris Cherny heeft sinds november 2025 niet meer handmatig één regel code geschreven.

Laat dat even bezinken. De persoon die Claude Code gebouwd heeft — die het gereedschap heeft ontworpen dat honderdduizenden ontwikkelaars nu dagelijks gebruiken — stopte ruim vier maanden geleden met het handmatig typen van code. En zijn output daalde niet. Het versnelde. Hij levert dagelijks tussen de 10 en 30 pull requests op, draait tot 15 Claude Code-sessies tegelijkertijd in zijn terminal en browser, en start soms codeersessies vanaf zijn telefoon voor het slapengaan om het voltooide werk de volgende ochtend bij de koffie te reviewen.

Toen ik dit voor het eerst hoorde in zijn optreden in Lenny's Podcast, was mijn reactie scepsis. Dertig PR's per dag? Van iemand die geen code schrijft? Dat klinkt als LinkedIn-opschepperij verpakt in een productiviteitsgoeroekostuum.

Toen bestudeerde ik zijn daadwerkelijke workflow. En wat me verraste was niet het volume — het was de eenvoud. Boris' systeem is bijna agressief minimaal. Geen complexe promptbibliotheken. Geen uitgebreide scaffolding. Geen instructiebestanden van twintig pagina's. Zijn hele CLAUDE.md-configuratie is ruwweg 100 regels. Ongeveer 2.500 tokens. Dat is het.

Het verschil tussen mijn Claude Code-productiviteit en de zijne ging niet over een geheime techniek die ik nog niet had ontdekt. Het ging over zes principes die ik had genegeerd, te ingewikkeld had gemaakt, of achterstevoren deed. Nadat ik de afgelopen twee weken mijn eigen workflow had herstructureerd rond zijn aanpak, kan ik je vertellen — de resultaten zijn echt. Mijn debugtijd daalde met ruwweg de helft. Mijn sessies produceren bruikbare output bij de eerste poging ongeveer 3x vaker. En ik ben eindelijk gestopt met die frustrerende cyclus waarin Claude vol vertrouwen het verkeerde ding bouwt terwijl ik toekijk, te diep in sunk-cost om te onderbreken.

Hier is de volledige analyse van wat Boris Cherny daadwerkelijk doet — en nog belangrijker, waarom elk onderdeel meer uitmaakt dan het lijkt.

"Ga langzaam om snel te gaan" — Waarom 80% van de sessies in plan mode begint

Dit was het eerste dat mijn manier van werken veranderde, en eerlijk gezegd is het het principe waar ik het langst weerstand tegen bood.

Ik opende vroeger Claude Code en begon meteen te prompten. De feature beschrijven. Code zien verschijnen. Me productief voelen. Behalve dat ik niet productief was — ik was bezig. Er is een cruciaal verschil, en Boris formuleert het in één observatie: AI lost problemen snel op, maar niet noodzakelijkerwijs de juiste problemen. Zonder duidelijke planning zal Claude vol vertrouwen de verkeerde kant op sprinten en iets technisch indrukwekkends bouwen dat het daadwerkelijke doel volledig mist.

Boris begint ruwweg 80% van zijn sessies in plan mode. Als je er niet mee bekend bent: plan mode (geactiveerd door twee keer Shift+Tab te drukken in Claude Code) vertelt de AI om na te denken en te analyseren zonder code te schrijven of commando's uit te voeren. Het leest bestanden, stelt vragen, doet voorstellen — maar raakt niets aan totdat je het plan expliciet goedkeurt.

De specifieke techniek die Boris gebruikt is wat hij het "interviewprompt" noemt. Voordat er code wordt gegenereerd, vraagt hij Claude iets als dit:

Interview me about this. What core problems does this solve?
Who is this for? What does success look like? What should this
NOT do? Summarize it back to me before writing any code.

Die prompt veranderde mijn hele workflow. Dit is waarom het krachtiger is dan het lijkt.

Toen ik het voor het eerst probeerde, stelde Claude me vijf verduidelijkende vragen over een feature waarvan ik dacht dat ik die duidelijk had beschreven. Twee van die vragen onthulden aannames die ik had gemaakt die ronduit fout waren. Eén ervan — "Moet dit het bestaande gebruikersrecord wijzigen of een nieuw activiteitenlogboek aanmaken?" — zou geleid hebben tot een databasearchitectuurfout die uren had kunnen kosten om te ontwarren als Claude gewoon was begonnen met bouwen.

Boris deelde een specifiek voorbeeld dat me bijbleef: een bugfix voor een klant waarbij Claude, zonder planning, rechtstreeks databasewaarden ging wijzigen in plaats van de UI-weergavelogica te repareren. De "fix" loste technisch het gemelde symptoom op maar brak drie andere features die afhankelijk waren van die databasewaarden. Het soort bug dat een snelle handmatige test doorstaat en dan twee dagen later in productie ontploft.

Plan mode had het in zestig seconden gevangen. Het interview had aan het licht gebracht dat het probleem alleen de weergave betrof. Claude zou een UI-laag fix hebben voorgesteld. Geen databasewijzigingen. Geen cascade van breakage.

Ik gebruik deze interview-first aanpak nu twee weken, en het patroon is consistent: ongeveer 4-5 minuten planning bespaart 20-40 minuten aan herwerk. De wiskunde is niet eens in de buurt.

Een detail dat makkelijk te missen is — plan mode is ook aanzienlijk sneller en goedkoper per interactie. Omdat Claude geen tools uitvoert, geen bestanden schrijft en geen commando's draait tijdens het plannen, komen de antwoorden razendsnel terug en verbruiken ze minder tokens. Je krijgt in feite het beste denkwerk van de AI met korting voordat je investeert in de dure uitvoeringsfase.

Nadat Claude zijn plan heeft gepresenteerd, reviewt Boris het, bewerkt het soms rechtstreeks met Ctrl+G (waarmee het plan in je teksteditor opent), en schakelt dan pas over naar auto-accept mode om Claude te laten uitvoeren. In de meeste gevallen, zegt hij, one-shot Claude de implementatie na een goede planningssessie. Eén poging. Geen iteraties. Geen "dat is bijna maar eigenlijk bedoelde ik..." correcties.

Dat alleen al maakt de planningsoverhead waard. Maar het volgende principe is wat de planning over sessies heen laat werken.

De CLAUDE.md van 100 regels — Waarom minder context meer oplevert

Hier is waar Boris' aanpak rechtstreeks in tegenspraak was met wat ik maandenlang deed.

Ik had een CLAUDE.md-bestand dat richting de 500 regels ging. Gedetailleerde architectuurdocumentatie. Codeerstandaarden met voorbeelden. Historische context over waarom bepaalde beslissingen waren genomen. Patroonbibliotheken. Het voelde grondig. Professioneel. Als een degelijk engineeringdocument.

Het at ook stilletjes 30% van mijn beschikbare contextvenster bij elk verzoek. Elke keer dat ik Claude een vraag stelde — zelfs een simpele — werden die 500 regels eerst geladen. Tokens verbruikt voordat het eigenlijke werk überhaupt begon.

Boris' CLAUDE.md is ongeveer 100 regels. Rond de 2.500 tokens. En het presteert beter dan elk opgeblazen instructiebestand dat ik ooit heb gebouwd.

Zijn filosofie is bijna zen-achtig in zijn terughoudendheid: het bestand mag alleen regels bevatten die terugkerende fouten corrigeren. Geen documentatie. Geen architectuuruitleg. Geen codeerstandaarden die Claude al kent uit zijn trainingsdata. Alleen correcties. Vangrails. De specifieke dingen die Claude fout doet in jouw project die het niet zou weten zonder dat het wordt verteld.

Het proces is reactief, niet proactief. Boris en zijn team bij Anthropic volgen een simpele regel: "Telkens wanneer we Claude iets verkeerd zien doen, voegen we het toe aan CLAUDE.md zodat het de volgende keer niet herhaald wordt." Het bestand is ingecheckt in git, gedeeld met het hele team, en wordt meerdere keren per week bijgewerkt. Maar dingen worden ook verwijderd. Naarmate modellen verbeteren, worden regels die zes maanden geleden nodig waren overbodig. Claude leerde ze vanzelf.

Dit sluit aan bij iets dat ik behandelde in mijn gids met 50 Claude Code-tips — je CLAUDE.md is óf je superkracht óf je knelpunt, en de scheidslijn is lengte. Maar Boris gaat verder dan ik deed. Hij raadt niet alleen aan om het kort te houden. Hij raadt aan om het te verwijderen en helemaal opnieuw op te bouwen wanneer het opgeblazen of tegenstrijdig wordt, in plaats van te proberen het chirurgisch op te schonen.

De redenering: opgestapelde instructies ontwikkelen na verloop van tijd interne tegenstrijdigheden. Regel 7 zegt "gebruik altijd async/await" maar Regel 43 zegt "gebruik callbacks voor databaseoperaties." Een mens die het bestand leest zou het conflict misschien opmerken. Claude misschien niet — of erger, het probeert misschien aan beide tegelijkertijd te voldoen, met bizarre hybride code als resultaat.

Opnieuw beginnen elimineert de tegenstrijdigheden, de dubbele instructies, en de regels geschreven voor modelcapaciteiten die niet langer van toepassing zijn. Het is de Marie Kondo-aanpak van AI-configuratie: als een regel geen momenteel actief probleem oplost, hoort het niet in het bestand.

Ik probeerde dit vorige week. Mijn CLAUDE.md van 500 regels verwijderd en helemaal opnieuw opgebouwd met alleen de regels die ik kon rechtvaardigen uit de afgelopen twee weken gebruik. Eindigde met 87 regels. Mijn tokenverbruik daalde merkbaar, en — dit is het deel dat ik niet had verwacht — Claude's codekwaliteit verbeterde daadwerkelijk. Minder conflicterende context betekende meer coherente output.

Er is een structureel detail dat het vermelden waard is. Boris maakt gebruik van CLAUDE.md-hiërarchie: een bestand op rootniveau voor projectbrede regels en bestanden op directoryniveau voor subsysteemspecifieke context. Je /api-directory krijgt zijn eigen gerichte regels zonder het rootbestand op te blazen. Dit is iets dat ik zelf ook intensief gebruik, en het schaalt prachtig bij monorepo's.

Als je daar zit met een CLAUDE.md die voorbij de 200 regels is gegroeid, raad ik Boris' nucleaire optie sterk aan. Verwijder het. Bouw opnieuw op vanuit alleen recente pijnpunten. Het bestand dat je overhoudt zal kleiner en beter zijn.

Verificatielussen — De 2-3x kwaliteitsvermenigvuldiger die niemand gebruikt

Dit is het principe dat me, eerlijk gezegd, het gevoel gaf dat ik mezelf voor de gek had gehouden door het niet eerder te implementeren.

Boris' bewering is specifiek: Claude de mogelijkheid geven om zijn eigen werk te verifiëren verbetert de outputkwaliteit met 2-3x. Niet "een beetje beter." Niet "enigszins betrouwbaarder." Twee tot drie keer beter. En na het implementeren van zijn aanpak geloof ik dat het getal klopt.

Het concept is eenvoudig. De meeste mensen gebruiken Claude Code in een genereer-en-review cyclus: Claude schrijft code, jij leest het, jij spot problemen, jij vraagt om fixes. Dit werkt, maar het legt de volledige kwaliteitslast bij jou. Jij bent de verificatielaag. En je bent een mens, wat betekent dat je dingen mist — vooral tijdens lange sessies wanneer de aandacht verslapt.

Boris' aanpak keert dit om. Hij geeft Claude de tools en instructies om zijn eigen output te controleren voordat het als klaar wordt gepresenteerd. Twee stappen:

1. Geef Claude een methode om zijn werk te verifiëren (een testsuite, een browserpreview, een lintingcommando, een typechecker)
2. Vertel Claude expliciet over die methode (in CLAUDE.md of in de prompt)

De praktische implementatie verschilt afhankelijk van wat je bouwt. Voor een webapplicatie kan het betekenen dat je Claude vertelt: "Na het aanbrengen van wijzigingen, draai de testsuite en open de browser om visueel te bevestigen dat de UI overeenkomt met de vereiste." Voor een API-endpoint kan het zijn: "Na implementatie, draai de integratietest en bevestig dat de response-structuur overeenkomt met het schema." Voor contentgeneratie kan het zijn: "Na het schrijven, review tegen het merkrichtlijnendocument in /docs/style-guide.md."

Boris gaat een stap verder — hij voegt verificatieprompts rechtstreeks toe aan zijn CLAUDE.md-bestand. Zoiets als:

Before marking any task as complete, propose a verification plan.
Describe what you'll check and how you'll confirm correctness.
Then execute that plan.

Deze ene regel, toegevoegd aan je instructiebestand, dwingt Claude om na te denken over verificatie voordat het begint met bouwen. En het verandert de output dramatisch. Claude begint testcases voor te stellen waar je niet aan had gedacht. Het vangt edge cases tijdens de implementatie in plaats van erna. Het draait typechecks en linters proactief in plaats van te wachten tot jij erom vraagt.

Ik heb deze regel acht dagen geleden aan mijn eigen CLAUDE.md toegevoegd. In die tijd heb ik precies twee gevallen gehad waarin Claude code indiende met een bug die ik niet opving tijdens review. In de acht dagen voor het toevoegen van de regel lag het aantal dichter bij negen of tien. Kleine steekproef, zeker. Maar de richtingverandering is onmiskenbaar.

Het belangrijkste inzicht hier is dat Claude niet de mogelijkheid mist om te verifiëren — het mist de instructie om te verifiëren. Op zijn standaardinstellingen optimaliseert Claude voor snelheid en voltooiing. Het wil je een antwoord geven. Verificatie vertraagt dat, dus het slaat het over tenzij je het expliciet in de workflow inbouwt. Boris' genialiteit is het herkennen dat één regel in CLAUDE.md een capaciteit ontgrendelt die er altijd al was maar sluimerend.

Dit verbindt met iets breders over hoe ik denk over Claude Code agent skills — de beste configuraties voegen geen nieuwe capaciteiten toe aan de AI. Ze activeren capaciteiten die de AI al heeft maar standaard niet gebruikt. Verificatie is het meest impactvolle voorbeeld van dat patroon.

Vermenigvuldig jezelf — Parallelle sessies die daadwerkelijk werken

Boris draait 5 Claude Code-instanties lokaal in zijn terminal en nog eens 5-10 op de website van Anthropic. Tegelijkertijd. Op verschillende taken.

Toen ik dit voor het eerst hoorde, was mijn reactie "dat klinkt chaotisch." Meerdere AI-sessies die op dezelfde codebase werken? Dat is een recept voor merge-conflicten, tegenstrijdige wijzigingen en code die niet integreert.

Behalve dat Boris ze niet op dezelfde taak draait. Elke sessie krijgt een apart, onafhankelijk stuk werk. De ene bouwt misschien een nieuw API-endpoint. Een andere schrijft tests voor een bestaande feature. Een derde refactort een utility-module. Een vierde onderzoekt een bugreport. Ze overlappen nooit. Ze raken nooit dezelfde bestanden aan. Ze draaien parallel omdat dat kan — het werk is van nature opgedeeld.

De truc die dit op praktisch niveau laat werken: elke lokale sessie gebruikt zijn eigen git checkout in plaats van branches of worktrees binnen dezelfde repository. Dit elimineert bestandssysteemconflicten volledig. Elke Claude-instantie denkt dat het op een zelfstandig project werkt. Geen lock-bestanden die met elkaar vechten. Geen half-geschreven wijzigingen in gedeelde directories.

Voor remote sessies start Boris ze met & vanuit de CLI en gebruikt soms --teleport om sessies heen en weer te verplaatsen tussen zijn terminal en de browserinterface. Hij start een sessie voor het slapengaan, en het wacht met een voltooide pull request wanneer hij de volgende ochtend incheckt.

Ik heb opgeschaald naar drie parallelle sessies — mijn hardware en aandachtsspanne zijn nog niet helemaal op Boris-niveau — en zelfs op die bescheiden schaal is het productiviteitsverschil significant. Drie onafhankelijke taken die me elk 45 minuten zouden kosten in serie worden in totaal gedaan in ongeveer 50-55 minuten. Geen perfecte parallellisatie, maar dichtbij genoeg dat het fundamenteel verandert hoe ik mijn werkdag plan.

Er is een subtieler voordeel dat Boris noemt en dat ik uit ervaring heb bevestigd: verse sessies brengen verse perspectieven. Wanneer je diep in een sessie zit die al 30 minuten aan een probleem werkt, is het contextvenster vol met de aannames en eerdere mislukte benaderingen van dat probleem. Een tweede sessie starten om hetzelfde issue te bekijken — maar helemaal opnieuw — produceert soms in minder dan vijf minuten een betere oplossing omdat het niet de ballast van eerdere pogingen met zich meedraagt.

Ik doe dit nu routinematig voor lastige bugs. Als mijn eerste sessie het niet in 15 minuten heeft opgelost, open ik een verse sessie met een schone beschrijving van het probleem. De verse sessie lost het ongeveer de helft van de tijd op. Niet omdat het slimmer is — maar omdat het onbelast is.

Voor iedereen die geïnteresseerd is in de git worktree-aanpak voor parallelle Claude-sessies schreef ik hier meer over in mijn Claude Code git worktrees parallelle agents-gids. De korte versie: worktrees geven je geïsoleerde werkdirectories vanuit één repository, wat iets efficiënter is dan volledige clones maar hetzelfde doel bereikt dat Boris beschrijft.

Systematiseer innerlijke lussen — Slash commands als spiergeheugen

Hier is waar Boris' workflow verschuift van "productief individu" naar "productiesysteem."

Elke ontwikkelaar heeft innerlijke lussen — de taken die je meerdere keren per dag herhaalt. Tests draaien. Boilerplate genereren. Pull requests aanmaken. Code reviews formatteren. Commitberichten schrijven. Documentatie bijwerken. Deze taken zijn individueel niet complex, maar ze stapelen op. Als je 3 minuten aan elk besteedt en er twintig per dag doet, is dat een uur repetitief werk.

Boris automatiseert deze met Claude Code slash commands en skills. Niet af en toe. Obsessief. Elke workflow die hij meer dan twee keer uitvoert wordt een commando.

De analogie die hij gebruikt is perfect: reguliere prompts zijn als tegen een basketbalspeler zeggen "dribble de bal over het veld, zoek een vrije teamgenoot, en pas als je er een ziet." Slash commands zijn specifieke speelwijzen — precieze sequenties die elke keer op dezelfde manier worden uitgevoerd. "Pick and roll van de linkervleugel." Geen ambiguïteit. Geen variatie. Gewoon uitvoering.

In Claude Code leven slash commands in .claude/commands/ als markdown-bestanden. Elk bestand beschrijft een specifieke workflow. Wanneer je /mijn-commando typt, leest Claude het bestand en voert die workflow uit. Geen opnieuw uitleggen. Geen "dit is wat ik nodig heb dat je doet..."-inleiding. Gewoon de trigger en het resultaat.

Boris' echte power move is Claude zelf vragen om voor te stellen welke commando's hij zou moeten maken:

Based on this project, what Claude skills should I create?
Look at my recent git history, my CLAUDE.md, and the types
of changes I make most frequently. Suggest 5-7 slash commands
that would automate my most common workflows.

Ik draaide deze prompt op een van mijn projecten en Claude suggereerde zeven commando's. Vijf ervan waren workflows die ik elke dag handmatig uitvoerde. Twee waren workflows waaraan ik niet eens had gedacht om te automatiseren omdat ze meerdere stappen over verschillende tools omvatten. Ik bouwde alle zeven, en de tijdsbesparing groeit dagelijks.

Het belangrijkste verschil tussen een slash command en een opgeslagen prompt is duurzaamheid. Prompts leven in je klembord of een notitiebestand. Ze raken zoek, worden inconsistent bewerkt en vergeten. Slash commands leven in je repository. Ze zijn versiebeheerd. Ze worden gedeeld met je team via git. Wanneer je een workflow verbetert, krijgt iedereen de verbetering bij hun volgende git pull.

Skills gaan een stap verder — het zijn niet alleen commando's die jij triggert, maar capaciteiten die Claude autonoom kan aanroepen tijdens het redeneren. Een skill met de juiste YAML-frontmatter activeert automatisch wanneer Claude een relevante situatie tegenkomt. "Wanneer de gebruiker om een statusrapport vraagt, gebruik deze workflow." "Wanneer je een API-endpoint genereert, volg deze template." Het is het verschil tussen een receptenboek hebben en een chef die alle recepten al kent.

Voor een diepere duik in het bouwen van effectieve Claude Skills behandelt mijn Claude Skills-gids de YAML-structuur, de vijf patronen die er echt toe doen, en de fouten die ik maakte tijdens mijn eerste week van het bouwen ervan. Boris' aanpak bevestigt wat ik onafhankelijk vond: begin met de workflows die je het vaakst herhaalt, automatiseer die eerst, en laat complexiteit organisch groeien.

Bouw voor de toekomst — De bittere les toegepast op je workflow

Dit is het principe dat alles bij elkaar brengt, en het is het meest filosofische van Boris' zes strategieën. Maar sla het niet over — het is het principe dat je behoedt voor een valkuil waar ik tientallen ontwikkelaars in heb zien lopen.

Boris verwijst naar Rich Sutton's beroemde essay uit 2019, "The Bitter Lesson," dat betoogt dat in de geschiedenis van AI-onderzoek, algemene methoden die rekenkracht benutten altijd uiteindelijk benaderingen overtroffen die gebaseerd waren op door mensen ontworpen, domeinspecifieke kennis. Elke keer dat onderzoekers probeerden intelligentie handmatig te coderen — schaakopeningen, spraakherkenningsregels, vertaalgrammatica's — werden ze uiteindelijk verslagen door systemen die simpelweg leerden van enorme hoeveelheden data.

Boris past dit toe op Claude Code-workflows: overengineer je prompts of scaffolding niet. Het model wordt snel beter. Die uitgebreide promptketen waar je drie dagen aan hebt besteed? Over zes maanden zal een simpele instructie van één zin betere resultaten opleveren omdat het model zoveel is verbeterd.

Ik heb dit zelf meegemaakt. Technieken die ik begin 2025 documenteerde om Claude schone TypeScript te laten produceren — specifieke opmaak­instructies, voorbeeldpatronen, expliciete type-annotaties in de prompt — zijn nu overbodig. Claude genereert standaard schone TypeScript. De uren die ik aan die prompts besteedde waren verspilde moeite, geïnvesteerd in infrastructuur die modelverbeteringen overbodig maakten.

Boris' praktische advies: richt je op het voeden van het model met kwalitatieve data en context in plaats van prompt engineering te optimaliseren. Je tijd is beter besteed aan een goed gestructureerde codebase met duidelijke naamconventies, uitgebreide tests en goede documentatie dan aan het perfectioneren van de zeventien-stappen megaprompt die Claude dwingt code te schrijven zoals jij het wilt. Want Claude zal leren code te schrijven zoals jij het wilt. Jouw taak is ervoor te zorgen dat het de juiste context heeft — niet de juiste beperkingen.

Dit verbindt terug met de filosofie van de minimale CLAUDE.md. Een instructiebestand van 500 regels is overengineering voor de beperkingen van het huidige model. Een bestand van 100 regels gericht op projectspecifieke correcties blijft relevant zelfs als het model verbetert, omdat het Claude dingen leert die het oprecht niet kan weten zonder dat het wordt verteld — de conventies van je team, de eigenaardigheden van je project, de specifieke vereisten van je zakelijke domein.

Boris formuleert het als een vraag over waar je je marginale uur in investeert. Je zou het kunnen besteden aan:

• Optie A: Een prompt verfijnen totdat Claude op dit moment iets betere code genereert
• Optie B: Je codebase, je testdekking of je CLAUDE.md verbeteren met een correctie die maandenlang rendeert

Optie B wint altijd. En het wint met een grotere marge bij elke modelupdate, want hoe beter het model wordt, hoe minder prompt engineering uitmaakt en hoe meer contextkwaliteit uitmaakt.

Ik heb mijn eigen aanpak dienovereenkomstig herstructureerd. Wanneer ik mezelf voor de derde keer een prompt zie tweaken, stop ik en vraag: "Is dit een promptprobleem of een contextprobleem?" Bijna altijd is het context. De codebase is ambigu. De testsuite dekt de edge case niet. De CLAUDE.md mist een cruciale projectconventie. Los de context op, en de prompt kan simpel blijven.

Wat er veranderde in mijn eigen workflow

Na twee weken van het implementeren van Boris' zes principes, is dit wat verschoof.

Mijn sessies zijn korter. Niet omdat ik minder doe — omdat de planningsfase de valse starts elimineert die voorheen 30-40% van mijn sessietijd opaten. Ik besteedde vroeger 90 minuten aan een feature waarvan 30 minuten bestond uit "nee, dat is niet wat ik bedoelde, laat me het opnieuw uitleggen." Nu vangt het interviewprompt misalignment in de eerste vijf minuten.

Mijn CLAUDE.md is 87 regels. Gedaald van bijna 500. En mijn outputkwaliteit ging omhoog, niet omlaag. Minder instructies, minder verwarring, meer coherente code. Ik review het wekelijks en stel mezelf twee vragen: "Heeft Claude deze fout onlangs gemaakt?" en "Zou Claude deze fout maken zonder deze regel?" Als het antwoord op een van beide nee is, wordt de regel verwijderd.

Ik draai dagelijks drie parallelle sessies. Eén voor de primaire feature die ik bouw. Eén voor tests en documentatie. Eén voor bugonderzoek of refactoring. Ze interfereren niet. Ze delen geen context. En de gecombineerde doorvoer is ruwweg 2,5x wat ik deed in serie.

Elke workflow die ik drie keer heb herhaald is nu een slash command. Ik heb er veertien over mijn belangrijkste projecten. De tijdsbesparing voelt individueel klein — misschien 2-3 minuten per keer — maar bij twintig aanroepen per dag is dat bijna een uur teruggewonnen. Een uur dat ik besteed aan werk dat daadwerkelijk oordeelsvermogen vereist, niet uitvoering.

En ik ben gestopt met het optimaliseren van prompts. Wanneer Claude slechte output produceert, verbeter ik de context: CLAUDE.md bijwerken, de codebase verbeteren, een ontbrekende test toevoegen. Ik heb tien dagen geen "betere prompt" geschreven. Ik heb betere code geschreven. En de AI-output verbeterde als gevolg daarvan.

De ongemakkelijke implicatie

Er zit iets in Boris' aanpak waar het de moeite waard is om bij stil te staan — iets waar de meeste Claude Code-contentmakers (ikzelf incluis) omheen dansen.

De zes principes hierboven zijn niet complex. Plan voordat je bouwt. Houd instructies minimaal. Laat de AI zijn eigen werk verifiëren. Draai taken parallel. Automatiseer repetitieve workflows. Reken erop dat het model verbetert.

Niets hiervan vereist technische verfijning. Een junior ontwikkelaar kan alle zes op dag één implementeren. De barrière is geen kennis — het is ego. Plannen voelt traag wanneer je wilt beginnen met bouwen. Je zorgvuldig opgestelde CLAUDE.md van 500 regels verwijderen voelt als werk weggooien. Claude vertrouwen om zijn eigen output te verifiëren voelt als controle opgeven. Parallelle sessies draaien voelt als de draad verliezen.

Boris' resultaten suggereren dat de ontwikkelaars die zullen floreren met AI-ondersteund coderen niet degenen zijn met de slimste prompts. Het zijn degenen die bereid zijn te veranderen hoe ze over het werk zelf denken. Om AI niet te behandelen als een snellere typemachine maar als een medewerker die duidelijke richting, schone context en de autonomie nodig heeft om zijn eigen werk te controleren.

De persoon die de tool heeft gebouwd vertelt ons precies hoe we het moeten gebruiken. En zijn advies is niet "gebruik meer features" of "schrijf betere prompts." Zijn advies is: plan meer, configureer minder, verifieer alles, en vertrouw erop dat de tool beter zal blijven worden.

Ik ben twee weken bezig met deze aanpak. Mijn output is gestegen. Mijn frustratie is gedaald. En voor het eerst sinds ik Claude Code begon te gebruiken, heb ik het gevoel dat ik met de tool werk in plaats van het in bedwang te worstelen.

Als je vandaag één ding uit dit artikel probeert, maak het het interviewprompt. Open je volgende Claude Code-sessie in plan mode en plak dit voordat je iets anders doet:

Interview me about this. What core problems does this solve?
Who is this for? What does success look like? What should this
NOT do? Summarize it back to me before writing any code.

Beantwoord Claude's vragen eerlijk. Kijk hoe het je intentie terugvat. Vang de misalignment voordat er ook maar één regel code bestaat. En vertel me dan dat die vijf minuten het niet waard waren.

Veelgestelde vragen

Wie is Boris Cherny en wat is zijn rol bij Anthropic?

Boris Cherny is de maker en hoofd van Claude Code bij Anthropic. Hij bouwde het oorspronkelijke terminalgebaseerde prototype en leidt nu het team dat het ontwikkelt. Hij levert dagelijks 10-30 pull requests op zonder handmatig code te schrijven, en gebruikt zijn eigen tool voor al het ontwikkelwerk. Voor context over de tool zelf, zie mijn Claude Code-tutorial voor beginners.

Hoe activeer ik plan mode in Claude Code?

Druk twee keer op Shift+Tab in de Claude Code-terminal om plan mode te activeren. Claude zal dan bestanden analyseren en benaderingen voorstellen zonder code te schrijven of commando's uit te voeren. Je kunt ook het /plan-commando gebruiken in Claude Code v2.1.0 of later. Zie "Ga langzaam om snel te gaan" hierboven voor de volledige workflow.

Hoe lang moet mijn CLAUDE.md-bestand zijn?

Boris Cherny houdt het op ruwweg 100 regels (ongeveer 2.500 tokens). Het bestand mag alleen regels bevatten die terugkerende fouten corrigeren — geen documentatie, architectuuruitleg of codeerstandaarden die Claude al kent. Verwijder regels die de afgelopen twee weken niet relevant zijn geweest. Voor een volledig overzicht, zie mijn gids met 50 Claude Code-tips.

Kan ik meerdere Claude Code-sessies tegelijkertijd draaien?

Ja. Boris draait 5 sessies lokaal en 5-10 in de browser tegelijkertijd. De sleutel is elke sessie onafhankelijk werk geven op aparte git checkouts om bestandsconflicten te vermijden. Start remote sessies met & vanuit de CLI en gebruik --teleport om sessies tussen terminal en browser te verplaatsen.

Wat zijn Claude Code slash commands en hoe maak ik ze?

Slash commands zijn herbruikbare workflowtemplates opgeslagen als markdown-bestanden in .claude/commands/. Typ /commandonaam om ze te activeren. Maak er een door een markdown-bestand te schrijven dat de workflowstappen beschrijft en sla het op in de commands-directory. Vraag Claude: "Welke slash commands zou ik moeten maken voor dit project?" om te beginnen.

Laten we samenwerken

Op zoek naar het bouwen van AI-systemen, het automatiseren van workflows of het opschalen van je technische infrastructuur? Ik help graag.

• Fiverr (custom builds & integraties): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise-oplossingen): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (beveiligingsdiensten): xcybersecurity.io