AI-vraagstuk

We hebben onszelf in een hoek gevibecoded

Eerst voelde het alsof je superkrachten had, met iedere avond een nieuwe feature. Toen kwam het punt waarop de AI vooral nieuwe manieren vond om oude problemen te verplaatsen. Vaak hoeft niet alles opnieuw.

Herken je dit?

Vibe coding loopt meestal niet ineens vast. Eerst stapelen kleine technische problemen zich op, totdat steeds meer prompts nodig zijn om nog iets te veranderen.

  1. Eén fix breekt iets anders

    Een ogenschijnlijk kleine wijziging zorgt ineens voor fouten op plekken waar je niet aan hebt gezeten.

  2. De AI stelt steeds grotere refactors voor

    Voor simpele wijzigingen lijkt volgens de codingtool telkens een flinke verbouwing van de code nodig.

  3. Niemand weet meer wat leidend is

    Er bestaan meerdere implementaties, oude bestanden en half vervangen oplossingen naast elkaar.

  4. Je durft werkende code nauwelijks aan te raken

    Het project werkt nog, maar iedere verandering voelt alsof je iets belangrijks kunt omgooien.

Waar wil je naartoe?

Je wilt niet stoppen met AI-assisted development. Je wilt weer kunnen bouwen zonder dat iedere wijziging een nieuw technisch risico introduceert.

Weer grip op de codebase

Je begrijpt hoe de belangrijkste onderdelen samenhangen en waar je veilig wijzigingen kunt doen.

Veranderen zonder roulette

Nieuwe features hoeven niet meer onverwacht andere delen van de applicatie kapot te maken.

Zelf weer verder kunnen

De technische basis en werkwijze zijn duidelijk genoeg om daarna opnieuw zelfstandig met AI-tools door te bouwen.

Waarom gebeurt dit?

AI-codingtools zijn heel goed in momentum. Maar zonder duidelijke architectuur, tests en technische grenzen kan dat momentum uiteindelijk tegen je werken.

Bekijk hoe we dit aanpakken

Lokale oplossingen stapelen zich op

Iedere prompt lost het probleem van dat moment op, maar houdt niet automatisch rekening met de architectuur van het geheel.

Technische feedback ontbreekt

Zonder goede tests, types, conventies en deploymentchecks merkt de AI pas laat dat een verandering ergens anders schade veroorzaakt.

De codebase wordt zelf de bottleneck

Steeds meer context is nodig om een wijziging goed te doen. Daardoor wordt snel bouwen langzaam weer traag en onvoorspelbaar.

Waarom 9to5 hierbij?

Hier maakt senior software engineering het verschil: een bestaande codebase begrijpen, technische risico's terugbrengen en zorgen dat het eigen team daarna weer zelfstandig verder kan.

Bekijk cases

We zijn niet tegen vibe coding

Zelf bouwen met AI kan juist heel effectief zijn wanneer de technische basis goed genoeg blijft.

We beginnen niet automatisch opnieuw

Eerst bepalen wat bruikbaar is, daarna pas besluiten wat echt veranderd moet worden.

De bedoeling is dat jij weer bouwt

Rescue is geslaagd wanneer je 9to5 daarna niet voor iedere volgende feature nodig hebt.

Wat past nog meer bij je situatie?