AI pair programming patronen

Pair programming is al decennia een bewezen techniek: twee ontwikkelaars werken samen aan dezelfde code. Met Claude Code krijg je een AI pair programmer die 24/7 beschikbaar is, nooit moe wordt, en een enorme kennisbasis heeft. Maar hoe werk je effectief samen? Daar zijn vier patronen voor.

Waarom patronen?

Zonder bewuste aanpak val je snel in een patroon van “ik typ, Claude doet alles.” Dat werkt voor simpele taken, maar bij complexere projecten verlies je overzicht, kwaliteit en leermoment. De vier patronen helpen je om de juiste samenwerkingsvorm te kiezen per situatie.

Patroon 1: Driver / Navigator

Het klassieke pair programming patroon, vertaald naar AI.

• Jij bent de navigator: je bepaalt de richting, architectuur en aanpak
• Claude is de driver: schrijft de daadwerkelijke code

Wanneer gebruiken?

• Je weet wat je wilt bouwen maar wilt sneller code produceren
• Je bent bekend met het domein maar wilt niet elke regel zelf typen
• Je wilt de architectuur bewaken terwijl Claude implementeert

In de praktijk

Jij:   "We bouwen een auth module. Gebruik JWT tokens met
        refresh tokens. De tokens slaan we op in httpOnly
        cookies. Begin met de login endpoint."

Claude: [schrijft src/auth/login.ts met JWT logica]

Jij:   "Goed, maar gebruik jose in plaats van jsonwebtoken.
        Dat is edge-runtime compatible. En voeg rate limiting
        toe op het endpoint."

Claude: [past de code aan met jose + rate limiting]

Jij:   "Nu de refresh token logica. Die moet in een aparte
        route, en de oude refresh token moet geïnvalideerd
        worden na gebruik."

Claude: [schrijft src/auth/refresh.ts]

Het verschil met “Claude doet alles”: jij maakt elke architectuurbeslissing. Claude voert uit. Je blijft 100% in control.

Patroon 2: Rubber Duck

Bij rubber duck debugging leg je je probleem uit aan een badeend (of collega) om het zelf beter te begrijpen. Claude is een badeend die terugpraat.

• Jij legt uit wat je denkt en wat het probleem is
• Claude stelt vragen en wijst op gaten in je redenering

Wanneer gebruiken?

• Je zit vast en weet niet waar de bug zit
• Je twijfelt tussen twee aanpakken
• Je wilt je eigen denken toetsen

In de praktijk

Jij:   "Ik heb een race condition in mijn checkout flow.
        Wanneer twee requests tegelijk binnenkomen voor
        dezelfde gebruiker, worden er soms dubbele orders
        aangemaakt. Ik denk dat het aan de database ligt."

Claude: "Interessant. Laat me een paar vragen stellen:
        1. Gebruik je transacties rond het order-aanmaakproces?
        2. Heb je een unique constraint op iets dat dubbele
           orders zou voorkomen?
        3. Op welk moment check je of er al een order bestaat?"

Jij:   "Hmm, we checken eerst of er een order is, en maken
        er dan een aan. Maar dat is niet atomisch..."

Claude: "Precies, dat is een classic TOCTOU (time of check,
        time of use) probleem. Twee opties:
        1. Wrap het in een database transactie met serializable
           isolation level
        2. Gebruik een unique constraint + INSERT ON CONFLICT
        Welke past beter bij je setup?"

Merk op: Claude schrijft hier geen code. Het helpt je denken. Dat is het punt.

De juiste prompt

Ik wil hardop nadenken over [probleem]. Stel me vragen
en wijs me op dingen die ik mis. Schrijf nog geen code,
ik wil eerst het probleem goed begrijpen.

Patroon 3: Brainstorm

Bij brainstormen genereer je samen ideeën zonder direct te oordelen. Claude is een oneindige ideeëngenerator.

• Jij geeft de richting en constraints
• Claude genereert opties met voor- en nadelen

Wanneer gebruiken?

• Begin van een nieuw project of feature
• Je zoekt de beste aanpak uit meerdere mogelijkheden
• Je wilt buiten je eigen ervaring denken

In de praktijk

Jij:   "Ik moet real-time notificaties bouwen voor onze app.
        Gebruikers moeten updates zien zonder te refreshen.
        We draaien op Cloudflare Workers. Wat zijn mijn opties?"

Claude: "Er zijn vier hoofdopties voor jouw setup:

        1. Server-Sent Events (SSE)
           ✅ Simpel, native browser support
           ⚠️ Cloudflare Workers ondersteunen streaming
           maar met beperkingen

        2. WebSockets via Durable Objects
           ✅ Echte bidirectionele communicatie
           ⚠️ Complexer, hogere kosten

        3. Polling met lange intervals
           ✅ Simpelst, werkt overal
           ⚠️ Niet echt real-time, meer load

        4. Cloudflare Pub/Sub
           ✅ Gebouwd voor dit use case
           ⚠️ Beperkte docs, check de huidige status

        Gegeven dat jullie al op Workers zitten, zou ik
        beginnen met optie 1 (SSE) en upgraden naar
        optie 2 als je bidirectionele communicatie nodig hebt."

Jij:   "Optie 1 klinkt goed. Maar hoe zit het met meerdere
        tabs open? En wat als de connectie wegvalt?"

Patroon 4: Code Review

Claude reviewt jouw code, of code die Claude zelf heeft geschreven in een eerdere stap.

• Jij levert de code aan (of wijst naar gewijzigde bestanden)
• Claude reviewt op kwaliteit, bugs, security en best practices

Wanneer gebruiken?

• Voor je code commit of merged
• Na een grote refactoring
• Wanneer je twijfelt over je eigen implementatie

In de praktijk

Jij:   "Review mijn staged changes. Focus op security
        issues en performance."

Claude: [leest git diff --staged]

Claude: "Ik zie drie aandachtspunten:

        ❌ SECURITY, src/api/users.ts:34
        Je sanitized de user input niet voor de SQL query.
        Dit is kwetsbaar voor SQL injection.

        ⚠️ PERFORMANCE, src/utils/transform.ts:12
        Je maakt in een loop steeds een nieuw array aan met
        de spread operator. Bij grote datasets is dit O(n²).
        Gebruik push() of pre-allocate.

        💡 SUGGESTIE, src/components/UserCard.tsx:8
        Deze component rendert altijd, ook als de props
        niet veranderen. Overweeg React.memo()."

Jij:   "Fix het security issue. De performance laat ik
        voor nu, dat is een kleine dataset."

Review-prompt template

Review de volgende code/changes. Let op:
- Security vulnerabilities
- Performance issues
- Error handling
- Code style en consistency
- Mogelijke edge cases

Wees specifiek: noem bestand, regelnummer, en een concrete fix.

Wanneer welk patroon?

Situatie	Patroon	Waarom
Feature implementeren	Driver/Navigator	Jij bepaalt richting, Claude codeert
Bug oplossen	Rubber Duck	Eerst begrijpen, dan fixen
Nieuw project starten	Brainstorm	Opties verkennen
Voor een commit	Code Review	Kwaliteit waarborgen
Onbekende technologie	Rubber Duck, dan Brainstorm	Leren + opties
Deadline druk	Driver/Navigator	Maximale snelheid
Complexe architectuur	Brainstorm, dan Driver/Navigator	Eerst denken, dan doen

Tips voor effectief samenwerken met AI

1. Wees expliciet over het patroon

# Minder effectief
"Help me met de database"

# Meer effectief
"Ik wil brainstormen over de database-architectuur.
 Geef me 3 opties met voor- en nadelen. Nog geen code."

2. Houd de regie

Claude is je pair programmer, niet je baas. Als je het ergens niet mee eens bent:

"Nee, ik wil geen ORM gebruiken. We schrijven raw SQL
 met prepared statements. Pas je aanpak aan."

3. Stel grenzen

"Schrijf alleen de functie-signatures, ik vul de
 implementatie zelf in."

"Geef me pseudocode, geen echte code."

"Review alleen, verander niets."

4. Reflecteer na elke sessie

Vraag jezelf af:

• Heb ik het juiste patroon gebruikt?
• Had ik meer of minder aan Claude moeten overlaten?
• Heb ik iets geleerd, of alleen code geproduceerd?

De patronen combineren: een praktijkdag

09:00  BRAINSTORM, "Hoe pakken we de nieuwe search feature aan?"
09:30  DRIVER/NAVIGATOR, implementatie van de gekozen aanpak
11:00  RUBBER DUCK, "Waarom zijn de zoekresultaten langzaam?"
11:30  DRIVER/NAVIGATOR, performance fix implementeren
12:00  CODE REVIEW, review van alle ochtend-changes