Twee heel verschillende vragen

"Doen jullie iets met AI?" is inmiddels de standaardvraag geworden. Het probleem is dat het eigenlijk twee vragen zijn die niets met elkaar te maken hebben, en dat het antwoord op de ene "ja, volop" is en op de andere "alleen als het echt iets oplevert".

De eerste vraag is: gebruik je AI om software te maken? De tweede is: zit er AI in de software die je oplevert? Ze worden constant door elkaar gehaald, ook door mensen die er budget voor vrijmaken. En juist daar gaat het mis, want de plek waar AI vandaag de dag het meeste oplevert en het minste risico geeft, is niet de plek waar het meeste geld naartoe gaat.

Ik leid overdag drie PHP-teams en freelance 's avonds onder eigen naam. In beide petten gebruik ik AI intensief. Maar waar ik het inzet verschilt bewust, en dat onderscheid is het hele verhaal.

AI in het proces: de werkplaats

In het bouwproces is AI voor een ervaren ontwikkelaar een krachtige versneller. Niet omdat het het denkwerk overneemt, maar omdat het het saaie werk eromheen wegneemt zodat er tijd overblijft voor het denkwerk.

Concreet, waar het bij mij zijn geld verdient:

• Een vreemde codebase verkennen. In plaats van een halve dag door mappen klikken, laat ik AI de structuur in kaart brengen en de plekken aanwijzen die ertoe doen. Ik controleer, maar ik begin niet meer bij nul.
• Tests en refactors. Repetitief, goed af te bakenen, en precies waar een model sterk is. Ik schrijf de intentie, het model tikt het uit, ik ben de eindredacteur.
• Datamigraties en eenmalig gereedschap. Wegwerpscripts die ooit één keer perfect moeten draaien; snel opgezet, kritisch nagelopen.
• Grotere klussen met agents. Werk dat je kunt opsplitsen in parallelle deeltaken laat ik door meerdere agents oppakken, terwijl ik zelf de coördinator en het geweten blijf.

De rode draad: de waarde schaalt mee met jóuw oordeel, niet met dat van het model. Een senior die weet hoe het hoort, gebruikt AI als hefboom. Een junior die het antwoord niet kan beoordelen, gebruikt het als kruk, en bouwt sneller iets wat niet klopt. AI in het proces maakt goede ontwikkelaars sneller; het maakt zwakke code niet vanzelf goed.

En ja, ik ben eerlijk over de grenzen. Het model verzint met overtuiging onzin, het kent jouw domein niet, en het heeft geen idee wat er in productie gebeurt als het misgaat. Daarom komt er niets doorheen zonder review. Maar binnen die grens is de winst enorm en het risico laag; als er iets misgaat, gebeurt dat op mijn scherm, niet bij de klant.

AI in het product: wat de klant krijgt

Zodra een taalmodel meegaat in wat je oplevert, verandert alles. De fout gebeurt dan niet meer op mijn scherm maar bij de gebruiker, en die heeft geen reviewstap. De lat ligt daar veel hoger, en de eerlijke vraag is meestal niet "kan het?" maar "moet het?".

Heel veel "AI-features" in het MKB zijn een chatbot die op alles wordt geplakt. Dat voegt zelden waarde toe en bijna altijd risico: verkeerde antwoorden met een stellige toon, kosten en latency per verzoek, en een gebruiker die het bedrijf gaat wantrouwen na één hallucinatie. Een LLM in je product is geen feature; het is een verantwoordelijkheid.

Als het wél zinvol is, bouw ik eromheen in plaats van erop te vertrouwen:

• De mens houdt het laatste woord. In Mithril haalt AI actiepunten en beslissingen uit een meeting, maar altijd via een reviewscherm; niets wordt zomaar waar.
• Genereren, niet beslissen. In Aura schrijft het model SEO-teksten voor, maar de eigenaar keurt ze goed en kan ze overschrijven. De AI doet het typewerk, niet het oordeel.
• Vangnetten en eerlijkheid. Fallbacks als het model eruit ligt, een interface die onzekerheid laat zien in plaats van hem te verbergen, en determinisme op de plekken waar dat moet.

De onderliggende regel is dezelfde als waarmee ik al mijn plugins bouw: het onvoorspelbare deel hoort achter een strakke, geteste grens. Een LLM is bij uitstek dat onvoorspelbare deel.

Waarom dit onderscheid geld scheelt

Voor het MKB is dit geen filosofie maar een rekensom. Er wordt op dit moment veel budget verbrand aan product-AI die risico toevoegt zonder aantoonbare opbrengst, terwijl de veilige en grote winst ergens anders ligt: sneller en goedkoper bouwen met AI in het proces.

Dus als een klant vraagt "kunnen we iets met AI doen?", is mijn eerste antwoord meestal niet een feature maar een tegenvraag: welk probleem los je op? Vaak is de eerlijke uitkomst dat we het product simpel houden en de AI in de werkplaats laten, waar hij de bouwtijd omlaag brengt. Dat is minder spannend om over op te scheppen, en veel meer waard.

Dat is precies waarom ik als eerste antwoord op "doen jullie iets met AI?" liever een gesprek voer dan een demo geef. Niet elke vraag verdient een taalmodel; sommige verdienen gewoon goede, saaie code die blijft werken.

Waar ik de grens trek

Samengevat: in de werkplaats ben ik agressief met AI, in het product ben ik conservatief. Dat lijkt tegenstrijdig, maar het komt uit dezelfde hoek; respect voor wat de techniek wél en niet kan.

AI in je ontwikkelproces maakt je sneller vandaag, zonder dat je klant het risico draagt. AI in je product kan geweldig zijn, maar alleen als je precies weet waarom hij er zit en wat er gebeurt als hij ernaast zit. Het verschil tussen die twee kennen is, denk ik, waar het bij AI in 2026 echt om draait.