Bouwen met AI zonder programmeren: code was het kleinste deel
In dit artikel:
Ik beschrijf hoe AI de machtsverhoudingen in softwareontwikkeling verandert: niet omdat AI zelfstandig programmeert, maar omdat domeinexperts met hun inhoudelijke kennis nu zelf werkende systemen kunnen bouwen — zonder eerst ontwikkelaars te hoeven overtuigen. Als contentdirecteur en langjarig Flying‑Blue‑lid bouwde de auteur een productieplatform met tienduizenden regels code, honderden backend‑functies en een streng contentsysteem — grotendeels door zelf te ontwerpen en AI als programmeur in te zetten.
Eerste ervaringen voelden als ‘valsspelen’: in gewone taal een functie beschrijven en direct werkende code terugkrijgen. Dat maakt extreem snel productief, maar kan leiden tot rommel als je geen systeemdenker bent. Na drie weken bleek een verzameling werkende componenten geen geïntegreerd geheel: redundante data, herhaalde bugfixes en onduidelijke ontwerpkeuzes. De les: syntax en tooling zijn makkelijk; het echte omslagpunt is leren denken in systeemlogica en verantwoordelijkheidsgrenzen.
De echte voorsprong van de auteur was domeinkennis. Twintig jaar ervaring met het loyaliteitsprogramma Flying Blue leverde inzicht in regels, fricties en welke informatie gebruikers écht nodig hebben. Met die kennis bouwde hij onder meer een analyticsplatform dat voortgang voorspelt en ROI van miles berekent, en — belangrijker — een CMS dat contentkwaliteit afdwingt in plaats van alleen publicatie mogelijk te maken. Omdat AI‑modellen en zoekoverzichten steeds meer antwoorden genereren, wordt niet meer ‘wie het beste linkprofiel heeft’ geciteerd, maar wie het antwoord het meest feitelijk en gestructureerd aanbiedt. Dat maakt kwaliteitscontrole cruciaal.
Architectuurprincipes die werden ingevoerd:
- Eén enkele bron van waarheid: variabelen zoals benodigde XP voor een status staan centraal; wijzigen op één plek corrigeert alle 156 pagina’s in vier talen.
- Harde poortwachters: publicatie wordt geblokkeerd als content niet voldoet aan 48 automatische checks (te weinig woorden, geen bronvermelding, onvoldoende feitelijke ankers).
- Tests als vangnet: in plaats van blindelings vertrouwen op AI‑code, schreef de auteur 10.388 tests die verwachtingen in gewone taal vastleggen; AI genereert de technische tests en controleert bij elke wijziging of de verwachtingen nog kloppen.
Tegelijk kwamen valkuilen naar voren. Elf nachtelijke AI‑agents die de site moesten monitoren leverden veel ruis op: circa 30% van hun meldingen was onzin of gedupliceerde fouten. Oplossing: vervangen door een eenvoudig, voorspelbaar script dat dezelfde basischecks doet zonder valse positieven. Conclusie: AI is niet altijd het juiste instrument; simpele, betrouwbare oplossingen kunnen vaak beter zijn.
Belangrijkste inzichten en praktische adviezen:
- De barrière verschuift van ‘kan ik coderen?’ naar ‘begrijp ik mijn domein en kan ik een systeem ontwerpen en disciplinair aanpakken?’
- Begin klein: bouw één flow of één berekening die klopt, breid pas uit als dat stabiel is.
- Leg vast welke regels altijd waar moeten zijn (kennisarchitectuur), en forceer die in het systeem.
- Schrijf verwachtingen op (tests) en laat het systeem die elke wijziging controleren.
- Wees pragmatisch over tooling: kies betrouwbare scripts boven complexe AI‑agents als ze beter voorspelbaar zijn.
- Durf te starten en gebruik AI als begeleider: beschrijf problemen in gewone taal en laat modellen helpen, maar raak niet verliefd op de technologie.
Context: dit sluit aan bij de opkomst van low‑code/no‑code en AI‑assisted development: niet het einde van ontwikkelaars, maar de opkomst van domeinexperts als daadwerkelijke bouwers. De kritische succesfactor is niet alleen toegang tot AI, maar discipline in systeemontwerp, kwaliteitsbewaking en het vertalen van domeinkennis naar onveranderlijke regels. Voor organisaties betekent het dat specialisten, redacties en productdenkers dichter bij uitvoering kunnen komen — mits ze leren denken als systeembouwers en investeren in tests en single sources of truth.