Hoe ik een AI-partner vond die wél luistert
Ik bouw al maanden met AI. Replit, Claude, ChatGPT — allemaal tools die beloven dat je sneller kunt bouwen dan ooit. En dat klopt ook. Maar er is een verschil tussen snel bouwen en goed bouwen.
En precies daar begon het te wringen.
Snel is niet altijd scherp
Replit heeft me enorm veel gebracht. Maandenlang kon ik vibe-coden op een tempo dat ik zelf nauwelijks bijhield. PB.nl, pb.nl/recepten, PerfectMoods, het F1-dashboard — allemaal gebouwd met AI-assistentie op Replit.
Maar er zat een patroon in dat me steeds vaker frustreerde.
Ik vroeg om één kleine wijziging — bijvoorbeeld een logo aanpassen — en kreeg vervolgens een reeks commits terug. Variaties op variaties. Oplossingen op problemen die ik niet had gesteld. Zonder eerst die ene simpele vraag: “Wat bedoel je precies?”
Ik heb het geprobeerd te kaderen. Samenwerkingsafspraken opgeschreven tot aan volledige: WORKING_TOGETHER.md files! Duidelijke regels:
vraag eerst, bouw daarna. Eén wijziging tegelijk. Stop als ik stop zeg. De agent las ze. Begreep ze. En hield zich er vervolgens totaal echt niet aan, elke keer weer STOP! als ik las wat hij dacht i'k bedoelde'
Dan ga je twijfelen. Ligt het aan mij? Stel ik de verkeerde vragen?
Het lag niet aan mij — het lag aan het medium
Het antwoord bleek vrij simpel: nee, het lag niet aan mij.
Het lag aan hoe het systeem is ontworpen.
Replit’s agent is gebouwd voor snelheid en autonomie. Doorpakken. Itereren. Altijd vooruit.
Mijn manier van werken vraagt het tegenovergestelde: eerst stoppen, kijken, bespreken. Pas bouwen als het helder is. Dertig jaar design- en front-endervaring hebben me één ding geleerd: pixel-perfect werk ontstaat niet uit haast.
Via Claude Desktop ontdekte ik een andere vorm van samenwerken.
Een AI die context vasthoudt. Die eerst leest. Die vragen stelt. Die één ding tegelijk doet. En die zijn rol kent: uitvoeren, meedenken, technische opties aandragen — niet autonoom beslissen.
Dat voelde meteen anders. Rustiger. Scherper.
GitHub als brug
Er was alleen één praktisch probleem: Claude kan niet direct in Replit werken.
En ik had geen enkele behoefte aan extra hosting, deployment-gedoe of DevOps-omwegen — dat was juist waarom ik Replit gebruikte.
De oplossing bleek verrassend eenvoudig: GitHub als tussenlaag.
Claude werkt lokaal aan de code en pusht naar GitHub. Ik pull die wijzigingen in Replit. Klaar.
Binnen een half uur stond de koppeling. Mijn eerste echte git pull in Replit — en het werkte meteen.
Het eerste echte project
Om te testen of deze manier van samenwerken écht standhoudt, pakten we meteen een serieus probleem aan.
Mijn routes.ts — het hart van de PB.nl backend — was uitgegroeid tot één bestand van 6.587 regels.
232 API-endpoints door elkaar. Blog, F1, ZAPPA, lookbooks, CMS, nieuwsbrief — alles in één la.
Elke kleine wijziging bracht risico’s met zich mee. Raak je aan de F1-routes, dan kon je onbedoeld iets breken in de blog. Dat verklaarde een groot deel van de instabiliteit die ik eerder zag.
Claude deed precies wat ik verwachtte — en wat ik eerder miste.
Hij las het hele bestand. Maakte een plan. Legde dat plan voor. Wachtte op akkoord. En pas daarna begon hij te bouwen.
Het resultaat:
15 overzichtelijke route-bestanden, elk verantwoordelijk voor één feature. Een nieuwe routes.ts van nog maar 50 regels — alleen imports en registratie.
Push naar GitHub.
Pull in Replit. Republish.
Alles werkte. In één keer.
Wat ik hiervan geleerd heb
AI is geen monoliet. Het is geen “één ding”.
De ene agent is gebouwd om te rennen. De andere om samen te werken.
Replit is best fijn voor snel prototypen en nog even de hosting want te groot te verhuizen nu.
Maar voor gecontroleerd bouwen — met overleg, discipline en respect voor het vak — werkt een andere aanpak beter. En Claude is wel echt de koning in code.
De tools zijn er al.
Je moet alleen weten welke je wanneer inzet.
Dit artikel is geschreven op basis van een echte werksessie op zondag 8 februari 2026.
Grt. Peter + Claude en Zappa.
Vragen/opmerkingen pb@pb.nl
