Het begon snel. De eerste schermen stonden er binnen een middag en het voelde alsof de rest een kwestie van tijd was. Nu ben je weken verder, elke wijziging kost meer moeite dan de vorige en je twijfelt of doorgaan nog de kortste route is. Deze pagina helpt je die knoop doorhakken: wat er gebeurt als een AI-project langer doorloopt, welke signalen ertoe doen en wat iemand nodig heeft om het van je over te nemen.
De curve is bekend bij iedereen die met deze tools bouwt.
In een leeg project heeft een AI-assistent weinig om rekening mee te houden. Er is geen bestaande structuur, geen historie, geen afspraak die je per ongeluk kunt breken. Alles wat gegenereerd wordt, past per definitie. Dat verklaart het tempo van de eerste dagen.
Naarmate het project groeit, verandert dat. Elke nieuwe wijziging moet passen bij wat er al staat, en de assistent ziet niet altijd het volledige plaatje van hoe onderdelen samenhangen. Dan ontstaat een patroon dat je gaandeweg gaat herkennen: je vraagt om een aanpassing, krijgt code die er goed uitziet, en drie schermen verderop werkt iets niet meer dat gisteren nog prima was.
Onderzoek naar AI-ondersteund programmeren wijst in dezelfde richting. GitClear signaleerde in zijn analyse een duidelijke toename van gedupliceerde code in projecten waar veel met AI-assistentie wordt gewerkt. Dat is relevant omdat dubbele code betekent dat één wijziging op meerdere plekken moet gebeuren, en dat je die plekken maar net moet weten te vinden.
Niet elk ongemak is een reden om te stoppen. Deze vier wel.
Beide zijn goede keuzes. Het hangt af van waar je vastzit.
Hoe beter dit klaarstaat, hoe minder tijd er aan uitzoeken opgaat.
De repository, en als het kan de geschiedenis. Losse bestanden in een zipbestand kunnen ook, maar dan mist iemand hoe het gegroeid is.
Wat moet iemand doen om het op zijn eigen machine draaiend te krijgen? Welke sleutels, welke database, welke stappen. Dit kost anders zo een halve dag.
Een korte lijst van wat werkt, wat half werkt en wat je bewust hebt laten liggen. Dit voorkomt dat iemand iets repareert dat nooit klaar hoefde te zijn.
De foutmelding die terugkomt, het scherm dat het niet doet. Jouw zoekwerk is bruikbaar, ook als het niets opleverde.
Niet de technische opzet, maar het doel. Wie gaat het gebruiken en wat moet diegene kunnen. Daar volgen de keuzes uit.
Als er een moment is waarop het moet staan, is dat de belangrijkste informatie. Scope volgt uit tijd, niet andersom.
Meestal is het antwoord niet alles opnieuw, maar afbakenen wat er echt moet staan.
De reflex bij een vastgelopen project is opnieuw beginnen. Dat is zelden nodig en vaak duurder dan het lijkt, want je gooit dan ook alle keuzes weg die wel klopten. Wij kijken liever eerst wat er staat, wat daarvan bruikbaar is en welk deel echt in de weg zit.
Daarna komt de vraag die het meest oplevert: wat moet er precies werken. Niet de hele app, maar het stuk waarop je iets wilt kunnen laten zien of beslissen. Dat is bijna altijd kleiner dan mensen denken, en het is precies waar de scope-slicer voor bedoeld is.
Wil je eerst zelf inschatten of jouw geval haalbaar is, gebruik dan kan dit in één dag. Twijfel je meer in het algemeen tussen zelf doorgaan en uitbesteden, dan is zelf bouwen met AI of uitbesteden een logischer startpunt dan deze pagina.
Nee. Het is een gewone codebase in een gewone repository, dus een ander kan ermee verder. Wat je hebt gebouwd blijft bruikbaar, ook als er onderdelen worden herzien.
Zelden. Rommelige code is vervelend maar meestal niet fataal. Opnieuw beginnen is pas logisch als de basisopzet niet klopt met wat de app moet doen, want dan blijf je tegen dezelfde muur aanlopen.
Kijk naar waar je uren heen gaan. Zolang je aan functionaliteit werkt, ben je aan het opschieten. Gaat het merendeel naar uitzoeken waarom iets niet meer werkt, dan ben je aan het onderhouden zonder dat er iets bijkomt.
Meestal kan het gewoon verder in wat er staat. Dat is ook goedkoper. Alleen als de opzet fundamenteel niet past bij het doel, is het zinvol om onderdelen opnieuw op te zetten.
Dat is normaal bij AI-ondersteund bouwen en het is geen diskwalificatie. Het betekent wel dat je niet meer kunt beoordelen of een oplossing klopt, en dat is precies het punt waarop meekijken van iemand anders waarde toevoegt.
Dat hangt vooral af van hoe goed de opstart gedocumenteerd is. Als iemand het project binnen een uur draaiend krijgt, gaat de rest snel. Ontbreekt die informatie, dan gaat daar eerst tijd in zitten.
Stuur ons je project en waar je vastloopt. In een intake bepalen we samen wat er echt moet staan en wat daarvan in één werkdag te doen is.
Een korte intake volgt na je inschrijving. Daarna stemmen we scope en datum af.
We nemen contact op om de intake in te plannen.
We gebruiken cookies om je ervaring te verbeteren en het gebruik van de site te meten.