Het grootste verschil zit niet in welke AI dev tool je gebruikt.
Het zit in hoe strak je je proces inricht, en in het laten samenwerken van meerdere AI's die elkaars blinde vlekken vinden.
Het is even stil geweest van mijn kant. Vooral omdat ik een full focus had, en heb, op de ontwikkeling van een volgende applicatie. De meest complexe tot nu toe. Maar daarover later meer.
Wat ik in dit stuk wél wil delen, is de manier waaróp ik bouw. Na een tijd werken met verschillende AI dev tools is me één ding het meeste bijgebleven: dat het grootste verschil niet in de tool zelf zit, maar in de discipline eromheen. Dat laatste is voor mij de echte winst geworden, en daar kom ik verderop op terug.
Eerst de ervaring, daarna de werkwijze
Door eerdere Proof-of-Concepts, Snuffl.app, een interne salespipeline-applicatie, AI Dev Tools en wat kleinere projecten zoals de Kijklijst-app, is inmiddels behoorlijk wat ervaring opgedaan met verschillende AI dev tools en tech stacks. Wat me vanaf het begin opviel: organisatie en proces moeten strak geregeld zijn om overzicht te houden en niet alle kanten op te vliegen. Dat moest vóór het generatieve AI-tijdperk ook al, maar je regelde het anders.
Mijn werkwijze volgt BMAD (Business Model Agile Delivery), met één kernprincipe: documentatie vóór code.
Elke wijziging begint met een requirements-document en, bij een architectuurkeuze, een ADR (Architectural Decision Record) die vastlegt wát we bouwen en wáárom. Pas daarna volgt de code, in diezelfde volgorde: eerst de docs-commit, dan de implementatie. Zo blijft niet alleen het resultaat bewaard, maar ook de redenering erachter. Agile, maar met een papierspoor dat klopt.
Daarnaast wordt voor elke ontwikkeling geautomatiseerde tests gemaakt om de kwaliteit te waarborgen. En ik werk met een combi van Claude (Cowork & Code) en Codex. Naast de documenten van de verschillende ontwikkelingen van het platform zijn er ook algemenere documenten over aanpak, lessen, architectuur en security. Die gebruiken de LLM's om zich in te lezen.
Mijn bijna standaard aanpak van een nieuwe ontwikkeling
- 1
Met Claude Cowork deel ik mijn visie op een te ontwikkelen onderdeel om Claude mee te laten denken, en verzamel ik input waar nodig om hem te voeden.
- 2
Claude Cowork leest zich in en start onderzoek, en put via sub-agents op verschillende vlakken uit zijn data.
- 3
Claude komt vervolgens met uitgebreide feedback waar verrassend vaak heel goede ideeën bij zitten waar ik zelf nog niet aan had gedacht, maar die perfect passen.
- 4
Als de visie voldoende is doordacht en naar ontwikkeling kan, deel ik het eerst met Claude Code, die de lead krijgt. Claude Code duikt er zelf eerst in en komt vaak met goede input gerelateerd aan de code en met wat er tot dan toe is geleerd van eerdere ontwikkelingen, ook een document dat wordt bijgehouden.
- 5
Na wat heen en weer overleg en na overeenstemming geef ik akkoord voor het opstellen van het requirements-document, en eventueel een architectuurdocument als dat nodig is.
- 6
Als de documentatie gereed is, deel ik die met Codex, met een promptbeschrijving door Claude Code, om een uitgebreide review te doen. Daar komen vaak nog bijzondere zaken naar boven waar Claude Code (en Fable 5 trouwens ook) overheen had gekeken.
- 7
De review gaat terug naar Claude Code, die de punten checkt tegen de code, conventies, database en security. Vaak zijn ze terecht. Heel vaak. Hier voel ik een enorme winst ten opzichte van werken met maar één LLM.
- 8
Na de aanpassingen gaat er nog een review van Codex overheen om te zien dat alles juist is verwerkt. Soms vaker dan één keer. In sommige gevallen draai ik het om: Codex in de lead, Claude Code als reviewer. En dan zie je hetzelfde beeld, Claude Code haalt er toch weer zaken uit die Codex over het hoofd zag.
Pas bij mijn goedkeuring op de documenten mag er gebouwd worden, volgens de strakke regels die er zijn. Het lijkt veel voorbereidend werk, en dat is het relatief ook: ik ben langer bezig met de documentatie en het samen bedenken van werking en implementatie dan dat de LLM's nodig hebben om de code te schrijven.
AI's die elkaars blinde vlekken vinden
Dit is het inzicht dat ik het meest wil meegeven. Of ik nu Claude Code of Codex in de lead zet, de ander haalt er consequent dingen uit die de eerste miste. Niet incidenteel, maar structureel. Twee sterke modellen tegen elkaar laten reviewen levert aantoonbaar scherpere code op dan één model, hoe goed dat ene ook is.
Tussendoor laat ik wel eens een volledige code-review doen door Gemini. Die heeft niet meegebouwd, maar kijkt op verzoek over de schouder mee. En wat opvalt bij die volledige codebase-reviews: alle drie (Codex, Claude Code, Gemini) komen tot hetzelfde oordeel, maar Gemini komt met de minste op te lossen punten. Codex en Claude Code zijn daar veel scherper op. Claude nog het meest.
Wat het oplevert
Een codebase die van top tot teen gedocumenteerd is, met deze uitgangspunten als basis bij elke ontwikkeling (uit het lessons-document):
Security en schaalbaarheid eerst
Data- en compute-zuinigheid als prioriteit bij het werken met data
Hergebruik boven herschrijven
UX verdient speciale aandacht
Volg bestaande conventies, los structureel op, geen quick fixes
Documentatie bijwerken bij elke ontwikkeling; AI-reviewers zijn meekijkers, geen autoriteit
En zo luidde het oordeel dat Claude Fable 5 velde na een uitgebreide code review van een uur op dit platform:
Dit is een verrassend volwassen pre-livegang platform.
De fundering is aantoonbaar sterk: tenant-isolatie op meerdere lagen, een afhandeling van externe writes die een gedeeltelijke mislukking nooit als succes maskeert, privacybescherming vóór elke AI-aanroep, strikte authenticatie en een stevige CI-pijplijn. In deze review vond ik geen exploiteerbare blocker — geen auth-bypass, geen cross-tenant lek, geen dataverlies.
Er komen ook altijd punten uit die er ondanks de zorgvuldigheid toch in zijn geslopen. En dat is precies het voordeel van deze werkwijze: doordat alles gedocumenteerd en gestructureerd is, zijn die punten makkelijk en gericht op te lossen.
De prompt die ik gebruik voor een volledige review
Voor wie het zelf wil proberen: dit is de volledige prompt waarmee ik de livegang-review door Claude Fable 5 liet uitvoeren, van doel tot rapportstructuur. Alleen de projectnaam en paden zijn geanonimiseerd.
Je werkt in de repository: `[pad naar de repository]` Doel: Maak een read-only, diepgaand livegang-gereedheidsrapport voor een Product Owner over het platform. Maak GEEN edits, commits, branches of bestanden aan. Je taak is uitsluitend analyseren en rapporteren. Taal: Schrijf het rapport in het Nederlands. Technische termen mogen Engels blijven. Belangrijke opdracht: 1. Lees eerst `AGENTS.md`, `control/manifest.yaml`, `docs/PROGRESS.md`, `docs/roadmap.md`, `docs/architecture/external-write-register.md`, `docs/architecture/docs-status-governance.md` en `docs/requirements/151-execution-coverage-contract.md`. 2. Inventariseer daarna alle `.md`-bestanden in de repo, exclusief `.git`, `node_modules`, build-output en dependency-folders. Gebruik de documentatie om te begrijpen wat het platform claimt te doen, wat vrijgegeven is, wat blocked paths zijn, en welke statusclaims canoniek zijn. 3. Analyseer daarna de daadwerkelijke codebase breed en diep: backend, frontend, database/migraties, auth, tenant-isolatie, externe write-paden, AI/prompts, sync/jobs, UX-flows, tests, CI/CD, configuratie, security headers, error handling en operational readiness. 4. Vergelijk documentatieclaims met de echte implementatie. Meld expliciet stale docs, conflicten, ontbrekende onderbouwing en claims die niet door code worden waargemaakt. 5. Maak geen aannames zonder bewijs. Onderbouw concrete bevindingen met `file:line` verwijzingen. Werkmethode: - Werk read-only. - Gebruik gespecialiseerde reviewpasses alsof je deze rollen inzet: - Software Engineer - Software Architect - Senior Security Officer - Senior Compliance Officer - UX/UI Expert - Als echte subagents beschikbaar zijn, gebruik ze. Zo niet, voer de analyse per rol zelf afzonderlijk uit. - Start met een brede inventaris, ga daarna naar kritieke paden. - Besteed extra aandacht aan kwetsbaarheden, privilege escalation, tenant data leaks, auth/session/CSRF/CSP, secret handling, externe writes, auditability, RLS, prompt injection, AI boundary controls, dependency/security posture en privacy/compliance-risico's. - Wees kritisch en onafhankelijk. Geef geen geruststellende conclusie als er onvoldoende bewijs is. - Als je iets niet kunt verifiëren, markeer het als "niet geverifieerd" en leg uit wat nodig is om het te verifiëren. Belangrijke invalshoeken: - Security - Schaalbaarheid - Architectuur en algehele opzet - Legal / compliance gereedheid - UX optimaal - Livegang readiness - Operationele beheersbaarheid - Test- en CI-volwassenheid - Data-integriteit en tenant-isolatie - Externe write-risico's - AI/LLM-risico's en prompt governance Output: Maak een rapport voor een Product Owner met technische bijlagen. Structuur van het rapport: # Livegang Readiness Rapport ## 1. Executive Summary - Algehele indruk - Livegangadvies: Go / No-Go / Conditional Go - Belangrijkste risico's - Belangrijkste sterktes - Top 10 acties vóór livegang ## 2. Readiness Scorecard Geef scores 1-5 met korte onderbouwing voor: - Productvolwassenheid - Codekwaliteit - Architectuur - Security - Privacy/compliance - Schaalbaarheid - UX/UI - Observability/operations - Testdekking - Documentatiebetrouwbaarheid ## 3. Belangrijkste Bevindingen Orden op severity: - Blocker - High - Medium - Low - Observatie Per bevinding: - Titel - Severity - Betrokken rol(len) - Impact - Bewijs met `file:line` - Waarom dit relevant is voor livegang - Aanbevolen oplossing - Eventuele test/validatie die nodig is ## 4. Analyse Per Rol ### 4.1 Software Engineer Beoordeel codekwaliteit, onderhoudbaarheid, foutafhandeling, tests, dependency management, CI, typing, backend/frontend consistentie. ### 4.2 Software Architect Beoordeel modulegrenzen, dataflow, multi-tenant architectuur, sync/jobs, externe write-choreography, AI-integratie, technische schuld, schaalbaarheid en evolueerbaarheid. ### 4.3 Senior Security Officer Beoordeel auth, JWT/refresh/cookies, CSRF, CSP, RLS, tenant-isolatie, secrets, externe writes, audit logs, SSRF, prompt injection, dependency risk, logging van gevoelige data en privilege boundaries. ### 4.4 Senior Compliance Officer Beoordeel AVG/GDPR, dataminimalisatie, retention, auditability, consent/legal basis, verwerkersrisico's, externe platformdata, AI-verwerking, logging, export/verwijderbaarheid en documentatie die nodig is voor livegang. ### 4.5 UX/UI Expert Beoordeel kernflows, foutmeldingen, loading/empty/error states, consistentie, toegankelijkheid, i18n, vertrouwen bij externe writes, demo/read-only signalering, onboarding en livegangwaardige polish. ## 5. Documentatie vs Code - Welke docs zijn betrouwbaar als bron? - Welke docs lijken stale of conflicteren? - Welke claims zijn niet aantoonbaar geïmplementeerd? - Welke livegangclaims ontbreken nog? ## 6. Livegang Gap Analysis Maak een concrete lijst: - Must fix before live - Should fix soon after live - Can defer - Needs PO decision - Needs legal/security owner decision ## 7. Aanbevolen Roadmap Naar Livegang Maak een gefaseerd plan: - Fase 0: bewijs verzamelen / verificatie - Fase 1: blockers oplossen - Fase 2: hardening - Fase 3: pilot/livegang - Fase 4: post-live monitoring ## 8. Residu-blinde-vlekken Noem expliciet wat je ondanks de analyse nog niet zeker weet, bijvoorbeeld omdat er geen staging toegang, secrets, CI-resultaten, productieconfiguratie of runtime logs beschikbaar zijn. ## 9. Overwogen-en-weerlegd Noem belangrijke risico's die je onderzocht hebt maar niet bevestigd vond, inclusief bewijs waarom je ze niet als bevinding opvoert. ## Bijlagen Voeg technische bijlagen toe met volledige details: ### Bijlage A: Markdown Inventaris Alle relevante `.md`-bestanden gegroepeerd naar type, met korte functie en betrouwbaarheid. ### Bijlage B: Architectuurkaart Beschrijf backend, frontend, database, auth, sync, AI, jobs en externe writes. ### Bijlage C: Security Checklist Gedetailleerde checklist met status: OK / Risk / Unknown / N.v.t. ### Bijlage D: Compliance Checklist Gedetailleerde checklist met status: OK / Risk / Unknown / N.v.t. ### Bijlage E: UX Flow Review Review van belangrijkste gebruikersflows en UX-risico's. ### Bijlage F: Test- en CI-analyse Welke tests bestaan, welke risico's worden afgedekt, welke gaten blijven open. ### Bijlage G: Bewijslijst Alle belangrijke `file:line` referenties overzichtelijk gegroepeerd. Voor je begint: Stel maximaal 5 verduidelijkende vragen als die echt nodig zijn. Als je zonder antwoord kunt starten, noteer je aannames en begin je direct met de read-only analyse.
De applicatie is nog niet live
Maar ik hoop binnen afzienbare tijd meer te kunnen vertellen en te laten zien. Stay tuned. Wil je in de tussentijd sparren over een docs-first AI-ontwikkelproces? We denken graag mee.
