Waarom ik AI-coderingen niet meer zomaar laat werken

Er was een moment dat alles veranderde in hoe ik met AI-agenten werk.

Ik zat drie uur diep in het debuggen van een "simpele" feature. Mijn agent had zelfverzekerd code geschreven, naar productie gepusht, en zelfs een vrolijk bericht achtergelaten dat de taak was voltooid. Eén probleem: de code was volledig fout. Niet buggy—fundamenteel verkeerd begrepen wat we probeerden te bouwen.

Dat moment brak iets in mijn denken. Ik had agenten altijd gezien als behulpzame junior ontwikkelaars die wat begeleiding nodig hebben. Maar junior ontwikkelaars pushen geen ongeteste code naar productie terwijl jij slaapt.

Dus ik veranderde de metafoor.

Het Onderaannemersmodel

In plaats van agenten te behandelen als medewerkers of assistenten, behandel ik ze nu als onderaannemers. Dit is wat dat in de praktijk betekent:

Een onderaannemer heeft geen sleutels van je gebouw. Ze duiken niet onuitgenodigd op. Ze leveren hun werk af en sturen een factuur—die jij controleert voordat je betaalt. Als hun werk onder de maat is, stuur je het terug.

Dit gaat niet over wantrouwen. Het gaat over het afstemmen van prikkels en verantwoordelijkheid. Wanneer een onderaannemer begrijpt dat hun rol is om een afgerond product op te leveren voor jouw review—niet om eenzijdige beslissingen te nemen—presteren ze beter. Ze zijn gefocust. Ze zijn productief binnen grenzen.

De Technische Laag

Dit denkmodel heeft technische tanden nodig. Voor mijn projecten betekent dat:

Token-scoping is Alles

Mijn agenten werken met afgebakende credentials die fysiek onmogelijk productie kunnen raken. Ze hebben lees-toegang tot de codebase en schrijf-toegang tot een aparte staging-repository. Dat is geen beleid—het is een cryptografische beperking. Zelfs als een agent rogue gaat of hallucinerende git-commando's produceert, kan het geen productiecode wijzigen. De tokens staan het simpelweg niet toe.

De Staging Repository is een Brievenbus

Niets gaat automatisch van staging naar productie. De default branch van de staging repo is letterlijk een zeroday—een branch genaamd "no-main" die alleen een README bevat met "gebruik de main branch van de originele repository."

Agenten pushen hun voltooide werk hierheen. Ze laten me weten wanneer branches klaar zijn. Dan review ik, cherry-pick wat werkt, en integreer ik handmatig. Dit voelt omslachtig tot je je realiseert: dit is precies hoe de Linux kernel al twintig jaar werkt. Bijdragers sturen patches. Maintainers passen ze toe.

Review is Niet Onderhandelbaar

Geen enkele agent voegt ooit zijn eigen code samen. Punt. Een branch wordt niet verwijderd totdat ik—onafhankelijk, programmatisch—heb geverifieerd dat de commits veilig binnen productie zitten. "Vertrouwen maar verifiëren" is niet genoeg wanneer verificatie gratis is.

Waarom Dit Werkt voor Solo Ontwikkelaars

Hier is het ding over solo ontwikkelaars of kleine teams: je bouwt niet alleen software. Je onderhoudt context die nergens in de codebase bestaat. Je incidentgeschiedenis. Je edge cases. De klant met een rare configuratie. De drie dingen die je probeerde en niet werkten.

Agenten hebben nul toegang tot deze context. Ze lezen bestanden, maar ze begrijpen jouw wereld niet. Dus het doel is niet om ze meer autonomie te geven—het is om het werk te maximaliseren dat ze veilig kunnen doen binnen je review-bandbreedte.

Dit is waar "vibe coding" een slechte naam krijgt. Verkeerd gedaan betekent vibe coding dat je agenten laat doen wat ze willen en hoopt dat het werkt. Goed gedaan betekent het AI gebruiken als krachtvermenigvuldiger voor jouw oordeel, niet als vervanging ervan.

De Praktische Voordelen

Zodra je de onderaannemer-relatie accepteert, gebeurt er iets onverwachts: je neemt meer risico's. Je durft die experimentele feature te starten omdat de downside begrensd is. De agent kan productie niet breken. Ze kunnen iets verrassends en verkeerd leveren, of iets verrassend goeds—maar hoe dan ook, je vangt het op voordat het ertoe doet.

Ik heb de afgelopen zes maanden meer side projects gestart dan in de vorige twee jaar. Niet omdat ik harder werk—omdat ik agressief delegeer binnen veilige grenzen.

Dit Inbouwen in Je Workflow

Als je AI-agenten gebruikt voor ontwikkeling, stel jezelf dan deze vragen:

1. Wat kan mijn agent op dit moment aanraken? Als het antwoord "productie" is, heb je een probleem.
2. Is er een technische beperking die verkeerde acties voorkomt, of alleen een beleid?
3. Wie voegt code samen? Als het geen mens is, waarom niet?

De tools bestaan. Token scoping, aparte staging repos, branch protection—dit zijn geen exotische Git workflows. Ze zijn het verschil tussen AI-assisted development en AI-accidental disasters.

Bij NameOcean denken we hier veel over na terwijl we vibe coding support inbouwen in onze hosting-omgeving. Het doel is niet om alles te automatiseren—het is om ruimtes te creëren waar AI echt nuttig kan zijn zonder nieuwe categorieën risico te creëren.

Jouw oordeel is nog steeds de bottleneck. Dat is geen beperking—dat is het punt. De agenten bestaan om te versterken wat jij kunt doen, niet om het oordeel te vervangen dat software daadwerkelijk laat werken voor echte gebruikers.

Bouw hier accordingly.