Vibe coding zonder technical debt: zo pak je het correct aan

Vibe coding is een manier van software ontwikkelen waarbij je met behulp van AI (large language models) snel functionaliteit bouwt door ideeën in natuurlijke taal te beschrijven, en de AI de code laat genereren. Dit gebeurt vaak iteratief en experimenteel, gestuurd door “gevoel” en directe feedback in plaats van vooraf uitgewerkte architectuur.

‍

Op het eerste gezicht klinkt vibe coding als iets chaotisch: wat prompten, wat aanpassen, nog een iteratie, en plots staat er “iets” dat werkt. En eerlijk? Zonder structuur is het ook chaotisch. Maar dat zegt meer over de gebruiker dan over de methode. Voor professionals met kennis van architectuur, codekwaliteit en onderhoudbaarheid is vibe coding geen gokspel, maar een versneller. Zij gebruiken AI niet als vervanging van hun expertise, maar als uitvoerende kracht binnen een duidelijk kader. De professional bepaalt de architectuur, bewaakt de consistentie en splitst verantwoordelijkheden correct op. In die context wordt vibe coding geen bron van technische miserie die achteraf moet worden rechtgezet, maar een hefboom: sneller bouwen, zonder controle te verliezen.

Indien correct toegepast is het dus ook jammer dat nog steeds de term "vibe coding" wordt gebruikt. AI assisted development zou een veel betere optie kunnen zijn.

Om de hulp van AI bij het ontwikkelen zijn er een aantal praktische tips die ingeschakeld kunnen worden om het allemaal meer bestuurbaar en meer gecontroleerd te houden.

Hier zijn een aantal concrete zaken die ons helpen om beter aan te pakken.

Kies een tool die gebonden is aan één project

Er zijn een hele hoop producten beschikbaar om te ontwikkelen met AI: OpenAI's Codex, Claude Code, Lovable, enz. Het probleem is hier vaak dat deze tools tot zeer veel bestanden toegang hebben, ingesteld zijn om op heel algemene vragen te kunnen antwoorden en niet gemakkelijk feedback of sturing toestaan.

Om die reden kan het veiliger te zijn om te werken met GitHub Copilot rechtstreeks geïntegreerd in je IDE. Zo blijf je netjes binnen een project werken en kan je met kleine gerichte vragen telkens de updates in de code stap per stap nakijken en goedkeuren of weigeren.

GitHub Copilot laat trouwens toe om elke wijziging meteen na te kijken.

Hoe je GitHub Copilot instelt voor Visual Studio code staat hier netjes beschreven.

Leg eerst je boilerplate vast

Als je ervoor kiest om eerst manueel de technologie en de frameworks in te stellen, help je de AI al enorm om je vragen binnen de juiste context op te lossen. Alleen al voor bijvoorbeeld front-end ontwikkeling zou er zonder een eerste manuele setup al de keuze zijn tussen vanilla Javascript, React, Vue, Flutter, enz. Als je manueel al bijvoorbeeld een React Typescript project instelt, zal de AI ook op die tech stack voortbouwen. Zo kan je ook zeker zijn dat je bouwt met technologieën die gedragen zijn binnen je bedrijf.

Geef voldoende context mee, maar op de juiste manier

Voldoende context meegeven met je vraag is cruciaal. Je zou bij elke prompt de volledige scope van je project kunnen uittypen. Gelukkig bestaat daar een betere manier voor. Door gebruik te maken van een AGENTS.md bestand, kan je in één tekstbestand de nodige context vatten, wat dan met elke prompt automatisch wordt meegestuurd. Kleine tip: ook dat document kan je met behulp van AI verder uitschrijven, want wie weet er beter wat een AI goed begrijpt dan de AI zelf?

Meer info kan je vinden via de URL die niemand kon voorspellen: agents.md

Start met kleine stappen vooraleer op te schalen

Ben je bezig met een nieuwe component in je project? Start dan met heel kleine stappen tot je ziet dat de AI mee is met hoe je het wil opbouwen. Pas zodra je de fundamenten in orde hebt gekregen, kan je grotere stappen nemen.

Vermijd vendor lock-in

Kies voor een oplossing die toestaat om een achterliggend model te kiezen. Het evolueert zo snel dat je de flexibiliteit moet kunnen behouden om met zo weinig mogelijk moeite te wisselen van model. Gepubliceerde benchmarks door de verschillende AI bedrijven blijven zeer onbetrouwbaar, omdat ze altijd ook bewust hun modellen hierop trainen. De beest betrouwbare bronnen om een juist model te kiezen zijn LM Arena (dit is puur gebaseerd op feedback van gebruikers) en voor open source modellen kan je simpelweg kijken welke modellen het vaakst worden gedownload. Lid worden van LocalLlama op Reddit brengt ook veel inzichten.

Zelfs een testen?

Je kan gratis aan de slag met een testversie van GitHub Copilot.

‍