AI is de Hubo voor de doe-het-zelf-programmeur

Er staat in mijn garage een boormachine die ik drie jaar geleden kocht bij Hubo. Een goede, trouwens. Hij heeft een prima motor, een handige snelheidsregelaar, en hij doet precies wat ik wil als ik een gat in de muur moet boren voor een schilderij of een kabelgoot. Ik ben er blij mee. Maar als mijn badkamer grondig verbouwd moet worden, bel ik een aannemer. Niet omdat ik te lui ben om het zelf te proberen, maar omdat ik weet dat het verschil tussen 'het lijkt gedaan' en 'het is goed gedaan' precies daar zit: in de kennis die je meebrengt naar het gereedschap, niet in het gereedschap zelf.

Die metafoor schoot me te binnen toen ik onlangs voor de derde keer in een week van een klant hoorde: 'Maar met AI kan dat toch veel goedkoper en sneller?' Het was niet kwaadwillig bedoeld. Integendeel. Ze hadden gelezen, gevolgd, geëxperimenteerd. Ze wisten dat tools zoals Claude, GitHub Copilot of Cursor razend krachtig zijn. Ze hadden misschien zelfs zelf wat code laten genereren en waren verrast hoe ver je daarmee geraakt.

En ze hebben gelijk. Gedeeltelijk.

De democratisering is echt

Laten we eerlijk zijn: AI-developmenttools zijn een echte gamechanger voor wie code schrijft. Een ervaren ontwikkelaar die Claude Sonnet gebruikt als pair programmer, werkt aantoonbaar sneller. Niet een beetje sneller. Significant sneller. Repetitieve basiscode die een middag opslokte, lever je nu in minuten. Documentatie schrijven, unit tests opzetten, een API-integratie uitwerken — het ritme van het werk is fundamenteel veranderd.

Dat is de Hubo-kant van het verhaal: AI heeft de drempel verlaagd. Mensen die vroeger dachten 'ik kan geen code schrijven' maken vandaag kleine scripts, automations, en eenvoudige webapplicaties. Dat is een goede zaak. Het geeft mensen autonomie over hun eigen processen, en het democratiseert toegang tot technologie op een manier die vijf jaar geleden ondenkbaar was.

Maar hier stopt de analogie niet. Ze begint er pas.

De vraag die niemand stelt

Tot voor kort was de vraag die we van bedrijven kregen glashelder: 'Bouw ons een AI-applicatie.' Inmiddels is die vraag stilaan aan het verschuiven. Wat we nu steeds vaker horen is: 'Hoeveel kan dit nog kosten, als AI het bouwen toch voor een groot deel overneemt?'

Dat is een begrijpelijke redenering. Het is ook een gevaarlijke.

Want wat AI-tools doen, is niet het elimineren van de kennis die nodig is om goede software te bouwen. Ze versnellen en vergemakkelijken het proces voor wie die kennis heeft. Voor wie die kennis niet heeft, doen ze iets anders: ze maken het makkelijker om iets te bouwen dat er professioneel uitziet, maar het niet is.

En dat brengt me bij een term die ik de voorbije maanden steeds vaker gebruik in gesprekken met klanten.

CRAPPS

CRAPPS. Niet het vriendelijkste woord, maar het is wel het eerlijkste. Het staat voor de applicaties die we steeds vaker beginnen te zien opduiken — toepassingen die gebouwd zijn met de hulp van AI, die doen wat gevraagd werd, die er netjes uitzien, en die bij de eerste demo iedereen enthousiast maken.

Tot de problemen beginnen.

Want CRAPPS zijn applicaties die tekortschieten op de dingen die je niet ziet totdat het te laat is. Schaalbaarheid is er eentje: de applicatie werkt prima voor vijf gebruikers, maar valt om bij vijftig. Veiligheid is een andere: er zijn geen goede authenticatielagen, gevoelige data wordt onversleuteld opgeslagen, API-sleutels staan hardcoded in de broncode. En dan is er nog de categorie die me persoonlijk het meest zorgen baart: onafhankelijkheid.

Een AI die code genereert zonder architecturale visie, trekt automatisch naar wat hij het vaakst gezien heeft in zijn trainingsdata. Dat zijn de grote, populaire frameworks en platforms. Dat zijn de cloud-diensten van de hyperscalers. Dat zijn de third-party API's die handig zijn maar die jou als bedrijf in een afhankelijkheidsrelatie plaatsen die je misschien niet bewust bent aangegaan.

Je hebt een applicatie gebouwd. Maar je hebt tegelijk ook een lock-in gecreëerd.

De no-code-parallel

Dit is ook het moment om even een zijsprongetje te maken naar no-code en low-code platformen, want die discussie loopt parallel en heeft al langer dezelfde spanningsvelden.

Bubble, Webflow, Zapier, Airtable, Glide — het zijn krachtige tools die echte waarde leveren in de juiste context. Voor een MVP, voor een intern prototype, voor een marketing landingspagina, voor een eenvoudige workflow-automatie: uitstekend. Ik zou ze zelf aanraden in die gevallen.

Maar ik zie ze ook ingezet worden voor bedrijfskritische applicaties. Voor systemen waar tientallen medewerkers dagelijks van afhangen. Voor data die niet zomaar in de handen van een extern platform mag liggen. En dan knijp ik mijn ogen samen.

Want no-code platformen verkopen vrijheid, maar leveren afhankelijkheid. De dag dat Bubble zijn prijsstructuur herziet, of dat Zapier zijn gratis tier schrapt, of dat het platform stopt — wat dan? Je hebt geen broncode. Je hebt geen controle over de infrastructuur. Je hebt een applicatie die bestaat zolang een derde partij beslist dat ze bestaat.

Dat is geen hypothetisch scenario. Het is al meerdere keren gebeurd.

De vraag die je als bedrijf moet stellen is niet: 'Kan ik dit bouwen met een no-code tool?' De vraag is: 'Wat zijn de consequenties als ik dit op een no-code tool gebouwd heb, over drie jaar?' En die vraag wordt te zelden gesteld voordat de keuze gemaakt wordt.

Terug naar de boormachine

Ik gebruik mijn Hubo-boormachine nog altijd. Ik gebruik AI-tools elke dag, professioneel, en ik zou er niet meer zonder willen. Ze maken ons team sneller, scherper, en in staat om meer waarde te leveren aan klanten in minder tijd. Dat is de realiteit van hoe we werken in 2026.

Maar het verschil tussen een boormachine in de handen van iemand die weet wat hij doet en diezelfde boormachine in de handen van iemand die voor de eerste keer een dragende muur tegenkomt — dat verschil is niet kleiner geworden nu het gereedschap beter is geworden. Het is groter geworden. Precies omdat het gereedschap zo krachtig is.

Een ervaren ontwikkelaar die AI gebruikt, bouwt sneller en beter. Een onervaren doe-het-zelver die AI gebruikt, bouwt sneller. Die twee zinnen klinken bijna hetzelfde. Ze zijn het niet.

Het gaat sneller, ja. Maar sneller naar waar?

Wat dit betekent voor jouw bedrijf

Als jij als bedrijfsleider vandaag nadenkt over een softwaretraject — of het nu gaat om een interne tool, een klantgericht platform, of een AI-gedreven applicatie — dan zijn dit de vragen die je moet stellen aan wie het bouwt:

Hoe wordt de data opgeslagen, en wie heeft er toegang toe? Is er een authenticatiearchitectuur die meegroeit met het gebruik? Van welke externe diensten zijn we afhankelijk, en wat is het exitplan als die dienst wegvalt of te duur wordt? Hoe ziet de codebase eruit over twee jaar, als er iemand anders aan moet werken? Is er een testinfrastructuur? Een monitoring? Een back-upstrategie?

Dit zijn geen fancy vragen. Dit zijn de basisvragen die elke professionele developer zichzelf stelt voordat de eerste regel code geschreven wordt. AI verandert niets aan die vragen. AI maakt ze alleen urgenter, omdat de drempel om iets te bouwen dat er professioneel uitziet, zo laag geworden is dat het verleidelijk is om ze over te slaan.

Het goede nieuws

Er is ook goed nieuws, en ik wil hier eerlijk over zijn: het is vandaag makkelijker dan ooit om goede software te bouwen. Niet ondanks AI, maar dankzij AI. De tools zijn beter. De snelheid is hoger. De mogelijkheden zijn breder.

Maar het verschil tussen een aannemer en een doe-het-zelver is niet het gereedschap in hun handen. Het is de kennis die bepaalt hoe dat gereedschap ingezet wordt, wanneer welke tool de juiste is, en wanneer je moet stoppen en iemand anders moet bellen.

Hubo is een geweldige winkel. Maar ik bel nog altijd mijn aannemer voor de badkamer.