AI Coderen: Wanneer het Wel en Niet Werkt

Als een vibe-coded product zes maanden na lancering voor 80 miljoen dollar wordt verkocht aan Wix, lijkt de conclusie simpel: AI coding tools zijn gewoon een winst. Zo simpel is het niet. Ze zijn een flinke winst op bepaald werk en een flinke kostenpost op ander werk. Teams die dat onderscheid snappen, zijn de teams die sneller bouwen zonder verborgen schuld op te bouwen.

Het Gevoelsprobleem

Een recent METR-onderzoek zette ervaren developers aan het werk met echte problemen in hun eigen grote codebases. Ze maten de werkelijke tijd mét en zonder AI-hulp. Vooraf schatten de deelnemers dat AI-tools hen zo'n 24% sneller maakten. Achteraf schatten ze 20%. De werkelijke meting? Ze waren 19% langzamer mét AI.

Die kloof tussen verwachting en realiteit is de belangrijkste bevinding in AI coding onderzoek. AI-hulp maakt het typen sneller en het reviewen langzamer. Mensen zijn er opmerkelijk slecht in om die reviewkost te zien, want het voelt gewoon als werk. Die 15 minuten die je bespaarde op scaffolding? Dat voelt als winst. Die 25 minuten die je kwijt was aan het debuggen van de "bijna goede" output? Dat voelt als je baan.

Waar de Snelheid Wél Echt Is

Het onderzoeksconsensus wijst duidelijk naar één categorie: nieuwe code in onbekend gebied. GitHub's gecontroleerde studie vond dat developers een webserver vanaf nul 55% sneller bouwden met Copilot. Veldstudies bij meerdere bedrijven zagen 26% meer taken afgerond, waarbij junior developers 27-39% meer output haalden op kortlopende taken. McKinsey's labwerk toont documentatie en greenfield code die roughly half de tijd kost.

Dat is het MVP-profiel. Een blanco project, een stack die je aan het leren bent, boilerplate die zichzelf voornamelijk kopieert, of een feature die je in een kort promptje kunt omschrijven. Op dat werk doen de tools precies wat de marketing belooft. De truc is om te herkennen dat dát niet alles is van software ontwikkelen.

Waar de Vertraging Insluipt

METR's vertraging gebeurde precies waar je zou verwachten: ervaren developers die codebases onderhielden die ze zelf jaren hadden geschreven. Het model produceerde plausibel klinkende code voor een systeem dat het niet begreep. De developer besteedde tijd aan het evalueren of het correct was. Die evaluatie kostte meer dan de functie gewoonweg schrijven.

Op schaal is dit waar teams in de problemen komen. Een startup die hard leunt op AI coding om zijn MVP te shippen, vindt product-market fit, begint te groeien, en ontdekt drie maanden later dat de "werkende code" rij-level security checks bevat die zijn uitgecommentarieerd, een admin panel toegankelijk voor elke geauthenticeerde gebruiker, en API keys die in de client-side bundle zijn beland. De AI schreef snel. De AI introduceerde ook een security review die niemand had gepland.

Het Faros AI onderzoek, dat meer dan 10.000 developers mat in echte teams, vond dat AI-assistentie teams daadwerkelijk vertraagde in 20-40% van de scenario's — vooral in codebases van meer dan 100.000 regels waar de context window niet het hele plaatje kan vasthouden. Dat is het brownfield probleem, en het is waar de meeste gevestigde teams het merendeel van de tijd zitten.

De Securityrekening Die Niemand Noemt

Elke week verschijnt er wel een verhaal: de AI-gegenereerde code van een startup legde gebruikersdata bloot, een AI-assisted deployment liet een databasepoort open, of prompt injection vond zijn weg naar een productiesysteem. Dit zijn geen exotische edge cases. Dit is de voorspelbare output van het richten van een tool die is geoptimaliseerd voor plausibele code op security-gevoelig werk, zonder dat een security expert het resultaat reviewt.

Het patroon is consistent. AI coding tools zijn getraind op publiek beschikbare code, en die code bevat veel code met bekende kwetsbaarheden, verkeerd geconfigureerde permissies, en hardcoded secrets. Als je zo'n tool vraagt om een gebruikersauthenticatiesysteem te bouwen of een payment integratie, krijg je vaak een plausibele versie van hoe dat eruitziet — wat niet per se een veilige versie is.

Voor startups die snel bewegen is dit het kritieke risico. Je bouwt niet alleen een MVP; je bouwt een reputatie en een compliance-oppervlak. Een datalek in je eerste jaar is geen technisch probleem. Het is een bedrijfsbeëindigend probleem.

Het Praktische Framework

Het onderzoek wijst naar een helder operationeel model:

Gebruik AI agressief voor greenfield werk. Nieuwe projecten, prototypes, scaffolding, onbekende stacks en goed afgebakende features — dat is waar de snelheidswinst echt en groot is. Dit is het meeste van wat een MVP live krijgt, en dit is waar deze tools hun abonnementskosten waard zijn.

Gebruik AI selectief voor brownfield werk. In een codebase die je goed kent, of op alles wat authentication, betalingen of gebruikersdata raakt, behandel AI output als een eerste concept dat een security review nodig heeft. De tijd die je budgetteert voor die review is de echte kost van de tool op dat werk. Laat het "voelt sneller"-signaal je niet verleiden om hem over te slaan.

Ship small, met tests. De instabiliteit in AI output toont zich het meest bij grote, complexe changes. Kleine incrementele changes met echte test coverage vangen de subtiele fouten die de review passeren en incidenten veroorzaken in productie. Dit is algemeen goede praktijk, maar het wordt kritiek wanneer AI in de loop zit.

Verhard voordat gebruikers het aanraken. Zet rij-level security checks aan. Verwijder secrets uit client-side code. Richt een AI agent niet op een productiedatabase. Dit zijn geen exotische security maatregelen — dit is de baseline voor elk systeem dat echte gebruikersdata verwerkt. AI coding verandert die baseline niet; het maakt het alleen makkelijker om te missen.

De Conclusie

AI coding tools zijn absoluut nuttig. Ze introduceren ook kosten die echt zijn, voorspelbaar, en vrijwel nooit worden genoemd in de marketing. De teams die het snelst shippen zijn niet degenen die AI voor alles gebruiken — het zijn degenen die het strategisch gebruiken, waar de snelheidswinst echt is, terwijl ze de delen van hun systeem beschermen waar correctheid belangrijker is dan snelheid.

Als je een MVP bouwt, gebruik AI tools dan om snel te bewegen op de delen die kunnen veranderen. Gebruik ze voorzichtig op de delen die goed moeten zijn. En als je niet zeker weet welke dat zijn — dat is waarschijnlijk je volgende vraag.