Vibe coding of agentic engineering: wat is het verschil?

Wat is vibe coding?

Vibe coding is software laten schrijven door AI op basis van een beschrijving, zonder de code zelf te lezen of te toetsen. Je zegt wat je wilt, accepteert wat er komt en kijkt alleen of het resultaat lijkt te werken. Hoe het anders kan, lees je in wat agentic engineering is.

De term komt van Andrej Karpathy, die hem op 2 februari 2025 op X⁠↗ introduceerde:

In dezelfde post beschrijft hij hoe dat er bij hem uitzag. Hij klikt altijd op “Accept All”, leest de diffs niet meer en plakt foutmeldingen zonder commentaar terug in de chat. Als het model een bug niet oplost, werkt hij eromheen of vraagt hij om willekeurige wijzigingen tot het probleem verdwijnt. Zijn eigen oordeel: “It's not too bad for throwaway weekend projects”.

Je ziet soms 6 februari als datum, onder meer bij Simon Willison, maar de post zelf is van 2 februari 2025. In het Nederlands heet het ook wel vibecoden⁠↗. Collins Dictionary koos vibe coding in november 2025 tot woord van het jaar⁠↗.

Wat is het verschil met agentic engineering?

Het verschil zit in de controle. Bij vibe coding leest en test niemand de code, bij agentic engineering wel: met afgebakende taken, tests en een review voordat iets live gaat. De AI-tools kunnen precies dezelfde zijn.

Simon Willison trekt de grens op dezelfde plek. In maart 2025⁠↗ schreef hij: “When I talk about vibe coding I mean building software with an LLM without reviewing the code it writes.” Wie de code van een LLM wel reviewt, test en begrijpt, doet volgens hem gewoon softwareontwikkeling.

Karpathy zag het verschil zelf ook. Een jaar later⁠↗ schreef hij dat je vibe coding destijds vooral gebruikte voor “fun throwaway projects, demos and explorations”, en dat professionals nu met agents werken, “except with more oversight and scrutiny”. Voor die tweede manier stelde hij de naam agentic engineering voor.

Dezelfde tools, een andere werkwijze

Met Claude Code, Codex of Cursor kun je vibe coden, en je kunt er agentic engineering mee doen. Het verschil zit in wat je eromheen inricht. Coding agents kunnen code schrijven én uitvoeren. Bij agentic engineering gebruik je dat om ze hun eigen werk te laten testen, en laat je het resultaat daarna door een ander beoordelen. Bij vibe coding sla je die stappen over en accepteer je wat er komt.

Wanneer is vibe coding prima?

Vibe coding is prima als een fout weinig kost: bij een prototype, een demo, een interne proef of een project dat je na een weekend weggooit. Je wilt dan snel zien of een idee werkt, en de houdbaarheid van de code doet er nog niet toe.

• Een klikbaar prototype om een idee aan gebruikers voor te leggen.
• Een eenmalig script voor jezelf, zonder gevoelige gegevens.
• Een demo om te laten zien wat er kan, voor mensen die weten dat het een demo is.
• Leren hoe een framework of API werkt door ermee te spelen.

Wees eerlijk tegen jezelf over wat je hebt gebouwd. Een prototype dat goed valt, verandert verleidelijk snel in een product, en dan gelden er andere eisen.

Karpathy keek er een jaar later nuchter op terug: “It was good fun and it almost worked.” Bijna werken is genoeg voor een demo, maar niet voor een app waar mensen elke dag op rekenen.

Wanneer wordt het riskant?

Vibe coding wordt riskant zodra de software echte gebruikers, persoonsgegevens, betalingen of koppelingen met andere systemen raakt. Een fout die niemand zag, kost dan geld, vertrouwen of data.

• Beveiliging. Code die niemand las, kan een API-sleutel in de app bevatten, of een endpoint dat meer gegevens teruggeeft dan zou moeten.
• Onderhoud. Als niemand de opbouw kent, wordt elke wijziging gokken. Karpathy merkte het zelf: “The code grows beyond my usual comprehension”.
• Stille fouten. Iets werkt in de demo en faalt bij randgevallen: geen internet, een lege invoer, een gebruiker in een ander land.
• Claims zonder bewijs. “Het werkt op iOS” omdat de build slaagde, terwijl niemand het op een toestel heeft gezien.

Bij Plens, onze app die fietsers vertelt wanneer ze het droogst vertrekken, staan zulke risico's daarom als harde regels in het architectuurbesluit. Een daarvan: “Geen mobiel geheim, service-role of providerkey in de appbundle.” En toen we de native app op 24 september door een onafhankelijke review haalden, was de eerste blokkerende bevinding dat de hele app in één bestand van 317 regels zat, zonder deep links. Dat was snel gebouwd, maar je kon er niet op doorbouwen.

Hoe kom je van een vibe-coded prototype naar productie?

Behandel het prototype als een specificatie: leg vast wat het moet doen, laat de code beoordelen, voeg tests toe en bouw opnieuw op waar de structuur niet deugt. Soms is opnieuw bouwen sneller dan repareren.

1. Leg vast wat het moet doen. Schrijf de gedragsregels op die het prototype liet zien: wat ziet de gebruiker, wat gebeurt er bij een fout, wat mag nooit gebeuren.
2. Laat de bestaande code beoordelen. Een onafhankelijke review laat zien wat bruikbaar is en wat niet: opbouw, beveiliging, afhankelijkheden. Hoe wij dat doen, staat in AI-codereview door een council.
3. Voeg tests toe voor het gedrag dat telt. Eerst voor de kern, daarna voor de randgevallen.
4. Knip het verdere werk op in kleine taken. Geef elke taak een duidelijke controle, zodat een agent hem kan uitvoeren en jij kunt zien of hij af is.
5. Spreek af wie beslist. Wie keurt een release goed, en wat mag een agent nooit zelf, zoals naar productie deployen?

Repareren of opnieuw bouwen?

Of je het prototype repareert of opnieuw bouwt, hangt af van wat de review vindt.

• Opnieuw bouwen als er geen tests zijn en de opbouw niet te volgen is, als alles in een paar grote bestanden zit, of als er sleutels en wachtwoorden in de code staan.
• Repareren als de opbouw te volgen is en er vooral onderdelen ontbreken, zoals foutafhandeling, tests of toegangscontrole.

Opnieuw bouwen voelt als verspilling, maar het prototype heeft dan zijn werk al gedaan: het liet zien wat de software moet doen.

De native app van Plens begon op die manier. In de startopdracht voor Claude Code stond: “Gebruik Opus 5 eerst als kritische reviewer van wat Codex al heeft gebouwd.” Daarna volgden “kleine, aantoonbare verticale bouwlussen”. De eerste commit van de app was op 16 september 2026; op 27 september stond hij in een gesloten test op Google Play.

Heb je een idee, een plan of bestaande code en wil je weten wat er nodig is om het echt te bouwen? Forenta maakt er een ontwikkelplan van en controleert de uitgangspunten. Hoe wij zelf bouwen, lees je op de pagina Bouwen.

Checklist: welke aanpak past bij jouw project?

Antwoord je op een van de vragen hieronder ja, kies dan voor agentic engineering. Is het overal nee, dan is vibe coding prima.

• Gaan anderen dan jijzelf de software gebruiken?
• Verwerkt het persoonsgegevens, betalingen of bedrijfsgevoelige informatie?
• Koppelt het aan andere systemen, zoals een database, een betaalprovider of een API met jouw sleutel?
• Moet het over drie maanden nog werken, en moet iemand anders het kunnen aanpassen?
• Kost een fout meer dan een middag herstelwerk?
• Wil je het later uitbreiden tot een product?

Weet je niet zeker waar jouw project staat? Neem contact op, dan kijken we mee.