Van vibe-coding naar gecontroleerde agentische ontwikkeling
“Vibe-coding heeft een slechte naam. En dat is volledig terecht.”
We gebruiken AI, maar niet als improvisatie-machine. Het is een strak proces met planning, validatie en continue kwaliteitsbewaking.
- Per taak een uitgebreide, handgemaakte prompt (1171 regels, 11.960 woorden).
- Per module/feature een 15-staps planningspipeline.
- Per feature een vaste lus: implementatie → validatie → sanity check.
Navigatie: ←/→ of spatie.
Doel van deze deck
In één oogopslag laten zien waarom dit proces bewust anders is dan “vibe-coding”, wat het oplevert, en wat de echte bottlenecks zijn.
Wat bedoelen we met “vibe-coding”?
Eén prompt, en de agent probeert het direct “in de code” te duwen — zonder expliciete guardrails.
- Coder: “Ik wil dat de applicatie X doet.”
- Coding agent: probeert dat on-the-fly te implementeren.
- Daarna: fixen wat stuk gaat, hopen dat er niets stiekem regressie't.
Waarom het vaak fout gaat
- Onbedoelde regressies (onzichtbaar tot je het breekt).
- Agentic duplicatie: dezelfde logica op meerdere plekken.
- Orphaning: losse bestanden/flows die niemand meer “meeneemt”.
- Inconsistente UX en architectuur door ad-hoc beslissingen.
Snelheid is leuk, tot onderhoud en betrouwbaarheid instorten.
Vibe-coding
- Werkt vaak “genoeg” voor demos.
- Maar quality-control is impliciet en ad-hoc.
- Onderhoud wordt snel pijnlijk.
Dit project
- Custom framework vanaf nul gebouwd (runner + stages + actions + hooks).
- Per taak een handgemaakte prompt (1171 regels).
- Strikte design- en architectuurregels: klein, centraal, onderhoudbaar.
Kern: we optimaliseren niet alleen voor “snel code hebben”, maar voor “snel correct blijven veranderen”.
Wat betekent dit concreet?
- Niet “1 prompt → 1 grote diff”, maar: eerst scherpstellen wat we gaan bouwen, dan pas bouwen.
- Documentatie en tests ontstaan als bijproduct van het proces, niet als nagedachte.
- Architectuur blijft onderhoudbaar doordat duplicatie en “orphaning” actief worden tegengegaan.
Kleine maar belangrijke detail
De runner is expres dun: modules (stages/actions/hooks) bepalen de flow. Dat maakt het proces hackable en gecontroleerd tegelijk.
15-staps planningspipeline (per module/feature)
Voor we code schrijven, maken we het werk expliciet: doel, scope, risico’s, tests en integratie.
Waarom dit het verschil maakt
De agent krijgt per stap een concreet doel en een concreet toetsingskader. Dat voorkomt “slimme” maar onhoudbare shortcuts.
Per feature: implementeren, bewijzen, en pas dan door
- Implementatie: alleen wat op de planning/checklist staat (geen “extraatjes”).
- Validatie: controleren of het gedrag matcht met de featurelijst en randvoorwaarden.
- Sanity check: snelle check op grote regressies en rare bijwerkingen.
Belangrijk detail
De sanity check draait expliciet tegen de plannings-output. Dat is hoe we agentische “creativiteit” temmen.
Geen magie. Wel guardrails.
Het proces is bewust ontworpen om de bekende faalpatronen van agentische ontwikkeling te voorkomen.
Continu gegenereerde documentatie
Docs ontstaan mee met de code, zodat kennis niet wegdrijft.
Unit- & integratietests (continu)
Tests worden steeds opnieuw gemaakt, gedraaid en geëvalueerd.
Strikte designprincipes
Consistente UI/UX-richtlijnen en tokens, geen willekeurige stijlkeuzes.
Strikte architectuurconstraints
Kleine bestanden, centrale libraries, minimale duplicatie → beter onderhoudbaar.
Codebase awareness
Custom tooling (codemap, chatformat) houdt context en samenhang zichtbaar.
Prompt per taak
Een uitgebreide, handgemaakte prompt wordt per opdracht bijgewerkt (1171 regels, 11.960 woorden).
Waarom die “kleine bestanden / centrale libraries” zo belangrijk zijn
Dat voorkomt agentische duplicatie en weescode. Het resultaat is een veel schonere codebase, en onderhoud blijft haalbaar.
Sterktes
Snel prototypen zonder de gebruikelijke pijn
De volledige huidige intertest-omgeving is in weken uit de grond gestampt als prototype.
Voor dit type project is dat normaal gesproken werk voor een gespecialiseerd team en veel langere doorlooptijd.
- De huidige rewrite is het directe resultaat van die analyse: we konden snel zien wat er moest veranderen, zonder “vast te zitten” aan één ononderhoudbare codebase.
- De ontwikkeling is op dit moment vooral beperkt door rate limits (niet door complexiteit van de code).
- Het plan dat Dustin gisteren stuurde wordt nu al meegenomen in het redesign.
Kort gezegd: snelle omloopsnelheid + gecontroleerde kwaliteit = veel meer leerruimte met minder risico.
Knelpunten (nu)
Er zijn 3 grote beperkende factoren die het proces op dit moment afremmen.
1) Credits / budget
De grootste bottleneck is dat het proces razendsnel door credits heen gaat.
- Ontwikkeling is razendsnel, maar het creditverbruik ook.
- In de praktijk is het soms kiezen tussen snelheid en kwaliteit (“fix nu” vs “fix later”).
- Zonder dit limiet had ik hier vandaag waarschijnlijk het afgeronde project kunnen laten zien — inclusief de wijzigingen van gisteren.
(Met de kanttekening dat tooling eerst nog “onbeperkt” moet kunnen draaien.)
2) Verwerkingssnelheid
Cloud-modellen zijn snel, maar niet de snelste. En cloud-API’s moeten rate limits afdwingen.
- Veel iteraties = veel calls = wachttijd.
- De limiet is niet alleen geld, maar ook throughput.
3) De developer (ik)
De term “prompt engineer” voelt nogal knullig, maar het werk is wel echt: goede prompts kosten tijd en focus.
- De handgemaakte prompt per taak (Interlancing/AAJ) is 1171 regels en 11.960 woorden — en moet met elke nieuwe feedback mee-evolueren.
- Prompt schrijven en verfijnen kan dagen tot weken kosten (nog steeds veel sneller dan alles met de hand coderen).
- Dit moet zo uitgebreid zijn omdat modellen en tooling niet standaard op deze workflow zijn afgestemd: het is een training- en toolingprobleem.
Belangrijk: alle drie de limieten delen dezelfde resourcepool (alle projecten samen).
Oplossing: lokaal draaien
Alle 3 knelpunten kunnen sterk worden verminderd (of zelfs weggehaald) door lokale hardware in te zetten.
Nu (cloud)
- Rate limits op API’s.
- Credits als harde grens.
- Meeste taken lopen serieel.
Met eigen hardware (local-first)
- Locaal runnable models zijn zo goed geworden dat 80–90% van het proces lokaal kan.
- Kleine taken kunnen parallel in tientallen tegelijk draaien, in plaats van één voor één.
- Geen creditlimiet meer: de limiet is throughput van de hardware.
- Hardware is schaalbaar als de tijdsdruk stijgt.
Ook de “developer limit” kan omlaag
Met dezelfde lokale capaciteit kunnen we tooling en prompts iteratief verbeteren, en modellen beter laten aansluiten op de workflow.
Het slechte nieuws
Om dit proces echt “zonder limits” te laten draaien, heb je serieuze GPU-capaciteit nodig.
(Voor nu: een horizontale placeholder. Later kunnen we hier echte screenshots plaatsen.)
Op papier is de oplossing simpel
Meer lokale GPU’s = meer parallelisatie = minder wachttijd. Alleen…
- Het opzetten van de GPU’s en het finetunen van het framework kost een paar weken om echt goed “ingediald” te raken.
- Daarna is het voordeel blijvend: toekomstige projecten profiteren direct mee.
Tijdlijnen (conservatief)
Elke regel verschijnt per klik.
Traditionele ontwikkeling
- Topkwaliteit / marktleider: 2–4 jaar (met een volledig team)
- “Goed genoeg”: 1–2 jaar (met een volledig team)
- Prototype-gericht: 6–12 maanden (met een volledig team)
Huidige Interlancing/AAJ (conservatief)
- Topkwaliteit / marktleider: 3–6 maanden tot lancering
- “Goed genoeg”: 2–4 maanden
- Prototype-gericht: 1–3 weken (maar je betaalt later met kwaliteitschuld)
Met 1× RTX Pro 6000 Blackwell
- Topkwaliteit / marktleider: 2–4 maanden (incl. inrichten & prompt/tooling aanpassingen)
- “Goed genoeg”: 2–3 maanden (incl. inrichten & prompt/tooling aanpassingen)
- Prototype-gericht: 1–3 weken (meeste tijd: inrichten & prompt/tooling)
Met 2× RTX Pro 6000 Blackwell
- Topkwaliteit / marktleider: 1–2 maanden (incl. inrichten & prompt/tooling aanpassingen)
- “Goed genoeg”: 1–2 maanden (incl. inrichten & prompt/tooling aanpassingen)
- Prototype-gericht: 1–3 weken (meeste tijd: inrichten & prompt/tooling)
Dit zijn grove richtwaarden om de orde-grootte te laten zien. De bottleneck verschuift van “credits + rate limits” naar “doorvoersnelheid van de hardware”.
Kortom
- Geen vibe-coding: dit is een gecontroleerd proces met planning, checks en continue docs/tests.
- We leveren in weken/maanden wat normaal jaren kost — juist omdat we eerst leren (prototype) en daarna schoon herschrijven.
- De echte bottleneck is niet “kunnen we het?”, maar: credits, rate limits en throughput.
- Local-first hardware verschuift die bottleneck en maakt parallelisatie mogelijk.
Vraag voor vandaag
Willen we investeren in lokale GPU-capaciteit om de doorlooptijd sterk te verkorten en de kwaliteit hoog te houden?
Vragen / discussie 👋