Vibe-coden worde steeds populairder: werken met een AI-hulp in de editor die meeschrijft, meedenkt en uitlegt. Daarmee wordt het model waarmee je dit doet een volwaardig onderdeel van je toolchain. Het bepaalt hoe snel je kunt itereren, hoe netjes de code blijft, hoe goed regels en tests worden gevolgd en hoe veilig je met gevoelige snippets omgaat. Niet elk model blinkt in hetzelfde uit, en blind wisselen kost tijd. In deze tekst leg ik uit wanneer en waarom het een goed idee is om een switch te overwegen.
Voor de meeste developerwerkzaamheden is één standaard LLM meer dan voldoende. Modellen verschillen wel degelijk: het ene verwerkt moeiteloos lange stukken code en documentatie, het andere reageert bliksemsnel of volgt regels en tests strikter. Dat betekent niet dat je steeds moet wisselen. Het betekent vooral dat een gerichte keuze soms merkbaar voordeel oplevert wanneer je buiten de comfortzone van je vaste model komt.
Blijf dus bij je default voor alledaagse taken zoals kleine scripts, boilerplate en korte vragen waarbij je snel wilt itereren. Overweeg pas een ander model als de taak daar duidelijk om vraagt. Denk aan situaties waarin je veel context moet vasthouden: bijvoorbeeld een uitgebreide code-review of architectuurverkenning waarbij meerdere bestanden, designkeuzes, en tickets tegelijk relevant zijn. Ook wanneer naleving van stijlgidsen, linters en tests echt leidend is, helpt een strenger model dat bij twijfel liever weigert dan gokt. Tijdens debuggen of het uitpluizen van stacktraces is juist een model prettig dat tussenstappen uitlegt en hardop redeneert. En als je met privacygevoelige of risicovolle code werkt, wil je een behoudende aanpak: secrets herkennen, diffs expliciet tonen en geen creatieve aannames.
Het kan helpen om in je hoofd een paar “types” te hanteren. Een snel en licht model is ideaal voor util-scripts en scaffolding, omdat de wachttijd laag is en de prompts kort zijn. Een lang-context en analytisch model houdt overzicht over grote repos en legt verbanden tussen code en specificaties. Een strikt en conformistisch model volgt regels en tests nauwgezet en zegt “nee” bij onduidelijkheid. Een didactisch model legt helder uit, wat fijn is voor debuggen en onboarding. En een security-bewust model kiest veilige defaults en markeert twijfelgevallen.
Elke keuze kent voor- en nadelen. Meer context en consistent redeneren kan de responstijd en kosten verhogen, terwijl striktere modellen minder creatief zijn. Snelle modellen voelen heerlijk vlot, maar lezen minder diep. Meer tooling en agents vergroten je mogelijkheden, maar maken je ontwikkelketen complexer.
Maak daarom geen keuzes op gevoel, maar toets eerst of het nodig is. Formuleer een eenvoudige hypothese waarom een ander type model hier beter past dan je standaard. Test vervolgens een klein setje representatieve taken in een sandbox of aparte CI-stage, log wat er gebeurt en meet kwaliteit, snelheid en kosten. Blijven, wisselen of terug: kies wat aantoonbaar beter presteert. Start zo’n proef alleen als de aanleiding sterk is: je context is echt te groot, je moet strenger aan regels voldoen, een snelle check laat duidelijk kwaliteitswinst zien, je haalt je latency-eis niet of privacy- en risicokaders zijn doorslaggevend. De kern blijft nuchter: één default is vaak het snelst, af en toe wisselen voegt waarde toe als de taak het rechtvaardigt.
Wil je beginnen met Vibe-coden? Bij Perrit leveren wij CodeChat, ons eigen vibe-codingplatform dat op verschillende LLM’s gedraaid kan worden. Zodat als je toch wilt wisselen van model dat altijd kan.
