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 uit de volledige review van dit platform kwam:
Kernoordeel: dit is een technisch volwassen, ongewoon goed geëngineerd platform.
Over alle vier de technische invalshoeken, engineering, architectuur, security en front-end, komt hetzelfde beeld terug: de fundamenten die er voor een multi-tenant platform dat namens gebruikers live wijzigingen wegschrijft naar externe systemen écht toe doen, zoals transactionele integriteit, idempotentie, tenant-isolatie, audit-trail en auth, zijn aantoonbaar geïmplementeerd in code, niet alleen in documentatie geclaimd. De engineering-discipline (docs-first BMAD-werkwijze, blocked paths, dubbele review, smoke-evidence) ligt ruim boven het gangbare niveau voor een product van deze omvang.
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 prompt waarmee ik een volledige codebase-review uitvraag:
Bekijk alle .md's in de project-folder. Doe daarna een uitgebreide analyse van wat er nu al staat qua codebase. Maak geen edits, ik wil een rapport.
Belangrijke uitgangspunten: security, schaalbaarheid, architectuur en algehele opzet, legal / compliance-gereedheid, UX optimaal.
Bekijk eerst de belangrijke docs: CLAUDE.md, AGENTS.md, SECURITY.md, PROGRESS.md, tasks/lessons.md, docs/architecture/, docs/ADR/, docs/requirements/, control/manifest.yaml, en de docs die daarin gelinkt worden.
Bekijk daarna alle code en logica.
Bekijk het vanuit verschillende invalshoeken met gespecialiseerde agents: Software Engineer, Software Architect, Senior Security Officer, Senior Compliance Officer, UX Expert, Front-end developer.
Maak er een rapport van voor een Product Owner, met bijlages die de details bevatten (volledig, mag technisch). En lever een samenvatting met conclusie op.
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.
