Zo bouw je een coding workflow die bij je brein past
Het echte probleem met AI coding assistants
Als je developers met AI-tools bezig ziet, valt me één ding op: de meesten halen misschien tien procent van wat er mogelijk is.
Ze openen ChatGPT, plakken wat code, stellen een vraag, krijgen antwoord, sluiten de tab. En dan weer opnieuw. Eigenlijk is het gewoon een snellere Google-zoektocht met een leuker uiterlijk.
Maar wil je iets complex bouwen — een startup, een side project, een productiesysteem — dan zijn sessies zonder geheugen een probleem. Elke keer begin je op nul. Je besteedt meer tijd aan context uitleggen dan aan echte problemen oplossen.
Voor developers die al moeite hebben met executieve functies is dit extra vervelend. En laten we eerlijk zijn: dat zijn we bijna allemaal. Dat romantische beeld van de programmeur die acht uur lang in flowstate zit? Klopt vrijwel nooit met de werkelijkheid.
Wat wél werkt: systemen met persistente context
De doorbraak komt wanneer je stopt met AI als chatbot en het gaat zien als een vaste ontwikkelpartner. Dat betekent systemen die:
- Onthouden waar je gebleven was, zelfs tussen verschillende sessies
- Je eigen kwaliteitsstandaarden afdwingen zonder dat jij ze hoeft te onthouden
- Samenvattingen genereren waarmee je binnen een minuut weer kunt opstarten
- Beslissingen, mislukkingen en lessen automatisch bijhouden
Dit gaat niet over lui zijn of je hersenen vervangen. Het gaat over de administratieve rompslomp van softwareontwikkeling uitbesteden, zodat je cognitieve energie naar echt probleemoplossen gaat.
Het systeem dat ik voor mezelf bouwde
Na jaren van projecten vol enthousiasme starten en ze in de war achterlaten, ontwikkelde ik een eenvoudig maar krachtig workflow met Claude Code. De kern: elk project krijgt een contextbestand dat in de repository leeft en automatisch wordt gelezen aan het begin van elke sessie.
Zo werkt het:
Projectcontextbestand
In de root van je project maak je een bestand — noem het bijvoorbeeld CLAUDE.md — dat beschrijft wat je bouwt, wie het bouwt en waar je in het proces zit. Als je een nieuwe coding-sessie start, leest Claude dit bestand eerst. Geen "wat was ik ook alweer aan het doen?" meer.
Het bestand heeft vier hoofdgedeeltes:
Context en doel
Wat doet dit project eigenlijk? Wat is de tech stack? Wie zijn de gebruikers? Dit is je liftpitch naar jezelf voor wanneer je na twee weken terugkomt.
Regels en standaarden
Je persoonlijke coderingsstandaarden. Bestandsnaamgeving. Testvereisten. Wat je ook automatisch wilt afdwingen, je schrijft het hier. Claude volgt deze regels zonder dat jij ze hoeft te onthouden.
Sessie-briefings
Voor elke coding-sessie schrijf je wat je wilt bereiken. Dit kost ongeveer twee minuten. De winst: als je wordt onderbroken of je momentum verliest, kun je precies daar verdergaan waar je stopte. Geen frictie.
Asynchrone checkpoints
Aan het einde van elke sessie schrijft Claude een samenvatting terug naar het bestand. Wat heb je bereikt? Wat komt hierna? Welke blokkades zijn er? Als je morgen — of volgende week — terugkomt, wacht de context op je.
Waarom dit belangrijk is voor je snelheid
Het ding over context-switching: het kost veel. Onderzoek wijst uit dat het twintig tot dertig minuten duurt om diepe focus na een onderbreking terug te krijgen. Voor developers met aandachtsuitdagingen kan dat getal hoger liggen.
Door persistente context te onderhouden, verlaag je de kosten van schakelen. Je wordt misschien nog steeds weggeroepen voor een vergadering, maar opnieuw opstarten kost zestig seconden in plaats van dertig minuten. Over een week zijn dat uren aan teruggewonnen focustijd.
Er is ook een psychologisch aspect. Elke keer dat je naar je project kijkt en je je verloren voelt, koppel je het aan frictie. Na verloop van tijd ontstaat er vermijding. Een systeem dat je begroet met "hier was je, dit werkte, dit is hierna" haalt die frictie volledig weg.
Kwaliteitspoorten toevoegen
Een van de grootste risico's bij solo-ontwikkeling is code verschepen die "af voelt" maar dat niet is. Tests slagen? Dan shippen we. Behalve... heb je de linter gedraaid? Gecontroleerd op beveiligingsproblemen? Geverifieerd dat de build nog werkt?
Je kunt deze checks als "bewijs-poorten" in je contextbestand coderen. Voordat Claude je helpt iets als af te merken, verifieert het automatisch jouw eigen criteria. Het is als een nauwgezette code reviewer die de checklist nooit vergeet.
Voorbeeld:
Voordat iets als af wordt gemarkeerd:
- Draai de volledige test suite
- Controleer dat er geen console.log-statements in productie staan
- Check dat de build zonder warnings compileert
Claude dwingt dit automatisch af. Jij hoeft het niet te onthouden. Het systeem doet dat voor je.
Praktische implementatie
Aan de slag gaan is eenvoudiger dan je zou denken:
- Maak één bestand in je project root
- Schrijf je context: beschrijf het project, je standaarden, huidige staat
- Begin elke sessie met het updaten van je sessie-briefing
- Eindig elke sessie door te vragen om een checkpoint-samenvatting
- Blijf itereren: voeg lessen toe, update regels, verfijn het systeem
De installatie kost ongeveer dertig minuten. De samengestelde opbrengsten beginnen direct en groeien na verloop van tijd.
Voor teams en startups
Dit is niet alleen voor solo-developers. Teams kunnen gedeelde contextbestanden gebruiken om nieuwe developers sneller in te werken, consistentie tussen bijdragers te behouden en de "bus-factor" te verlagen door impliciete kennis expliciet te maken.
Stel je voor: nieuw teamlid komt erbij, clonet de repo, en begrijpt meteen de projectstructuur, coderingsstandaarden en huidige prioriteiten. Ze hadden geen twee uur durende overdrachtsvergadering nodig. Het contextbestand deed het werk.
Het grotere plaatje
We bevinden ons op een interessant keerpunt in softwareontwikkeling. AI-tools worden echt nuttig, maar de meeste mensen hebben hun workflows nog niet aangepast. Ze denken nog steeds in termen van "vraag stellen, antwoord krijgen" terwijl de echte kans ligt in het bouwen van persistente, slimme systemen die menselijke capaciteiten versterken.
Voor developers — vooral degenen die anders werken — is de verschuiving van stateless naar stateful AI-interactie transformerend. Het gaat niet om minder werken. Het gaat om slimmer werken. Systemen bouwen die meewerken met de natuurlijke neigingen van je brein in plaats van ertegen te vechten.
Je beste code ontstaat wanneer je niet uitgeput bent van contextmanagement. De tools bestaan om dat mogelijk te maken. De vraag is of je ze用到 hun volledige potentieel gebruikt.