Zelf bouwen met AI of laten bouwen door professionals? Waar AI stopt en vakmanschap begint

Waar AI vandaag al keihard op scoort

Laten we het beestje bij de naam noemen: AI is goed in code. Dit komt doordat het razendsnel patronen herkent en die omzet naar tekst die lijkt op wat ontwikkelaars al jaren schrijven. Dat maakt AI geweldig voor alles wat voorspelbaar is. 

De eerste winst zit in genereren. Denk aan nieuwe functies, helpers, simpele API-aanroepen of varianten op hetzelfde thema. Zeker als je in een bekende taal of framework werkt, kan een AI-assistent in seconden iets neerzetten waar je anders tien minuten op zit te typen. Dat klinkt klein, maar op een hele werkweek is het een grote winst. 

De tweede winst zit in versnellen van prototypes. Een proof-of-concept of MVP draait vaak om een ding: kun je aantonen dat het idee technisch kan, en hoe voelt het voor een gebruiker? AI helpt je om dat ‘gevoel’ sneller te maken. Niet perfect, maar wel snel genoeg om iets te leren. 

De derde winst zit in itereren. “Maak dit formulier netter”, “schrijf tests voor deze functie”, “refactor dit naar een nettere structuur”. Als je de juiste context geeft, kan AI een lijstje met verbeteringen voorstellen waar je zelf stapsgewijs doorheen loopt. Het is een versneller van denkwerk, niet alleen van tikwerk. 

En ja, er is ook nog de doe-het-zelf laag. No-code en low-code waren al populair, maar met AI erbovenop kun je als niet-developer best ver komen. Dat is fantastisch, vooral voor teams die willen experimenteren zonder meteen een heel traject in te stappen. De vraag is alleen wat er gebeurt als je AI niet gebruikt als tool, maar als team.

Wanneer code werkt, maar systemen wankelen

AI-code levert vaak snel resultaat op. De meeste problemen ontstaan niet omdat de code niet draait, maar omdat het systeem geen houvast heeft. Het werkt in de ideale situatie, maar begint te schuiven zodra de werkelijkheid afwijkt. 

Die kloof heeft één oorzaak die steeds terugkomt: AI helpt bij het schrijven, maar niet automatisch bij het ontwerpen. Code is het zichtbare deel. Betrouwbaarheid zit in de keuzes eronder. Keuzes die bepalen hoe onderdelen samenwerken, wat er gebeurt bij fouten, en hoe je systeem zich gedraagt als het drukker wordt of als er iets verandert.

Architectuur geeft je systeem ruggengraat

Architectuur is de set afspraken waarop alles leunt. Waar komt data binnen en waar wordt die gevalideerd? Waar ligt de bron van waarheid? Welk component is verantwoordelijk voor welke taak? Hoe voorkom je dat één wijziging onverwacht drie andere delen breekt? Zonder dit soort afspraken krijg je software die vooral “op gevoel” aan elkaar hangt. Dat voelt eerst snel, maar het maakt elke volgende stap onvoorspelbaar.

Context bepaalt of je oplossing klopt

Vervolgens speelt context een grote rol, want software bestaat niet in een vacuüm. Elk bedrijf heeft uitzonderingen, interne spelregels en processen die niet in een standaardtemplate passen. AI kent die context alleen als je deze expliciet aanlevert, en zelfs dan blijft het een momentopname. Mensen herkennen juist de situaties die je niet opschrijft, maar die wel gebeuren. En die situaties zijn vaak bepalend voor vertrouwen: gaat het goed als het nét anders loopt dan gepland?

Onderhoud is waar snelle winst langzaam duur wordt

Na de eerste oplevering komt het punt waar veel AI-oplossingen zichzelf verraden: onderhoud. Een prototype is gebouwd om iets te bewijzen en een systeem wordt gebouwd om te blijven bestaan, maar  in de praktijk verandert er altijd iets: nieuwe wensen, extra gebruikers, andere integraties, nieuwe eisen. 

Als de codebasis bestaat uit losse snelle suggesties zonder duidelijke structuur, wordt aanpassen steeds duurder. Je ziet dan onduidelijke patronen, dubbele logica en keuzes die niemand meer kan uitleggen. Niet omdat iemand slecht werk levert, maar omdat de basis geen consistent verhaal vertelt.

Beveiliging moet je meenemen in het ontwerp

Beveiliging hoort in dezelfde categorie. Werkende code kan tegelijk kwetsbaar zijn. De vraag is niet alleen “doet het wat het moet doen?”, maar ook “doet het niets wat het niet mag doen?”. 

Dat gaat over toegangsrechten, het afschermen van gevoelige gegevens, het veilig omgaan met invoer en het beperken van schade als er iets misgaat. Als je dat pas achteraf moet toevoegen, ben je meestal bezig met repareren in plaats van bouwen.

Daar komt nog een praktisch risico bij: wat je aan AI laat meelezen. Veel assistenten worden beter als ze meer context uit je project kunnen gebruiken. Dat is nuttig, maar het betekent ook dat je bewust moet bepalen welke stukken code, data en documentatie wel of niet in die context terechtkomen. Zeker bij gevoelige informatie wil je niet afhankelijk zijn van “dat zal wel goed zitten”. Dit vraagt om afspraken en controle, niet om aannames.

Herkomst vraagt om volwassen werkwijze

En dan is er herkomst. AI kan suggesties doen die sterk lijken op bestaande codepatronen. Dat hoeft geen probleem te zijn, maar je wil wel zeker weten dat je geen risico’s naar binnen haalt die later lastig uit te leggen zijn. Dit los je op met een volwassen werkwijze: reviews, duidelijke richtlijnen en iemand die verantwoordelijkheid neemt voor wat er uiteindelijk in je product belandt.

Eigenaarschap maakt het verschil

Dat laatste punt is de verbindende factor: eigenaarschap. Professionele ontwikkeling gaat niet alleen over code schrijven, maar ook over verantwoordelijkheid dragen. Wie staat ervoor dat de oplossing klopt, ook onder druk? Wie pakt het op als er iets misgaat? Wie zorgt dat het systeem mee kan bewegen met nieuwe eisen? AI kan versnellen, maar het kan geen eigenaar zijn.

Daarom blijft de kernboodschap staan: AI maakt iets werkend, vakmanschap maakt iets betrouwbaar.

Bouwen is typen, beslissen is ontwerpen

Het interessantste werk in software gebeurt vaak voordat er een regel code is geschreven. Dat is het moment waarop je keuzes maakt die rust geven, of je juist jaren blijven achtervolgen. AI kan je niet uit die verantwoordelijkheid prompten. 

Een volwassen traject begint met scherpte: wat is het echte probleem dat je oplost, en voor wie? Als je probleem vaag blijft, wordt je oplossing een grabbelton. AI kan dan alsnog code maken, maar die code gaat alle kanten op omdat de richting ontbreekt. 

Daarna komt het beslissen over wat maatwerk moet zijn en wat vooral niet. Elke organisatie heeft processen die uniek zijn. Het vakmanschap zit in herkennen waar je standaardsoftware kunt gebruiken, waar je koppelingen slim legt, en waar je juist maatwerksoftware nodig hebt om waarde te leveren. 

Ook de plek van AI in je oplossing is belangrijk. Gebruik je AI als interface, als assistent, als interne versneller voor je team, of als kern van je product? Elk van die keuzes vraagt andere eisen aan betrouwbaarheid, monitoring en duidelijke afspraken. Dat is precies waarom veel developers AI wel gebruiken voor code en documentatie, maar veel minder enthousiast zijn over AI voor uitrollen en bewaken en projectplanning. Daar zit de hoogste verantwoordelijkheid. 

Een simpele manier om dit concreet te maken, is door vóór de bouw vijf keuzes expliciet te maken.

• Eigenaarschap: Wie hakt knopen door, en wie is aanspreekpunt als er iets misgaat? 
• Meetbaarheid: Hoe weet je dat het werkt, en wat betekent “goed genoeg” in jullie context? 
• Risico: Welke fouten zijn vervelend, en welke fouten zijn onacceptabel omdat ze geld, data of vertrouwen kunnen kosten?
• Onderhoud: Wie gaat dit over zes maanden aanpassen, en hoe zorgen we dat die persoon niet hoeft te gokken? 
• Veiligheid en data: Welke data mag er door AI, hoe ga je om met toegang, logging en afhankelijkheden, en hoe voorkom je dat je je eigen softwareketen verrast? 

Pas als je die keuzes hebt, wordt AI echt een versneller. Dan kan het helpen om sneller naar een goede oplossing te typen, zonder dat je onderweg de verkeerde afslag neemt. 

De valkuil van nog even wachten

De verleiding om te wachten is groot. Je ziet tools elkaar elke maand overtreffen, je hoort nieuwe beloftes, en je denkt: als ik nu bouw, zit ik straks vast aan iets ouds. Die gedachte is begrijpelijk, maar vaak gebaseerd op een verkeerde aanname: dat jouw voordeel straks in de tool zit. 

In de praktijk zit je voordeel meestal in fundamenten die niet snel verouderen. Denk aan heldere data, logische processen, goede toegangsrechten, degelijke logging, tests, en een architectuur die je kunt uitleggen. Die basis maakt het juist makkelijker om nieuwe AI-mogelijkheden later in te pluggen. 

Wachten heeft ook een prijs die je pas later ziet. Als je nu een snelle AI-oplossing neerzet zonder basis, bouw je vaak een systeem dat je straks niet kunt uitbreiden. Dan kom je in een loop van telkens opnieuw bouwen, migreren en uitleggen. Dat voelt als vooruitgang, maar het is vaak gewoon herhaling. 

Daar komt bij dat wet- en regelgeving rondom AI en data niet stilstaat. In Europa is er inmiddels een breed wettelijk kader voor AI aangenomen. Dat betekent niet dat elk marketingidee ineens juridisch spannend is, maar het betekent wel dat “we zien later wel” steeds minder comfortabel wordt zodra AI een rol krijgt in besluitvorming, compliance, of klantinteractie. 

Een volwassen investering klinkt daarom minder als “we kiezen een tool” en meer als “we bouwen een systeem dat nieuwe tools aankan”. De vraag is niet of je AI gebruikt, maar hoe volwassen je dat doet.

AI inzetten met gezond verstand

Een AI-specialist is een partij die AI inzet waar het helpt en er grenzen omheen zet waar het kan bijten. Dat klinkt minder sexy dan “alles automatiseren”, maar het is wel hoe je systemen bouwt waar je organisatie op kan leunen. 

In de praktijk betekent dat dat we AI gebruiken om developers beter te maken, niet om ze te vervangen. We gebruiken het voor snelheid, variatie en het verkennen van oplossingen. Daarna komt het echte werk: keuzes valideren, code reviewen, testen, en bewaken dat de oplossing als geheel gezond blijft. Code review is ook een moment waarop kennis en verantwoordelijkheid samenkomen. 

We kijken ook naar wat er rondom code zit. Hoe ga je om met afhankelijkheden? Hoe voorkom je softwareketen-verrassingen? Hoe weet je zeker dat wat je bouwt ook is wat je uitrolt? Daar bestaan volwassen beveiligingskaders voor, juist omdat software steeds meer een keten is van componenten. 

En als AI onderdeel is van de oplossing, dan hoort daar extra aandacht bij. Denk aan risico’s zoals prompt injection (iemand die je AI “ompraat”), onveilige output-afhandeling (iets uitvoeren omdat het er overtuigend uitziet), of het lekken van gevoelige informatie. Het punt is dat je het vooraf moet inregelen, omdat je anders pas leert onder druk. 

Ook nemen we verantwoordelijkheid voor wat code doet in jullie organisatie. AI kan meeschrijven, maar jij hebt iemand nodig die het kan uitleggen, verbeteren en dragen.

Snel gemaakt is nog niet slim gebouwd

AI kan veel beloven, zeker in de fase waarin het voelt alsof alles ineens zelf te maken is. Je hoeft geen techbedrijf te zijn om daarin te belanden. Juist marketing-, communicatie- en productteams zoeken naar tools en automatisering die vandaag waarde leveren en morgen niet blokkeren. Snelheid is dan aantrekkelijk, zolang het niet ten koste gaat van controle.

Die spanning wordt extra duidelijk zodra er al iets staat. De demo werkt, maar de vragen stapelen zich op. Wie krijgt toegang en op basis waarvan? Hoe richt je rollen en rechten in? Wat betekent security in de praktijk? Kan het systeem omgaan met groei, extra functies of meerdere teams die ermee werken? En als er later van platform of tooling wordt gewisseld, wat blijft er dan overeind?

Voor beslissers zit daar vaak nog een tweede twijfel onder: nu investeren en straks ingehaald worden. Wachten voelt veilig, maar lost die twijfel meestal niet op. Het verschil zit in de keuzes die je maakt. AI-tools veranderen snel. Een goede basis verandert veel minder vaak.

De belangrijkste gedachte is simpel: de investering gaat over zekerheid dat het blijft werken, dat het veilig is, dat het onderhoudbaar is en dat het mee kan bewegen met wat er nog aankomt.

Twijfel je of je nu moet investeren of nog even moet wachten? Plan dan een vrijblijvend kennismakingsgesprek! We brengen de keuzes in kaart die het verschil maken voor betrouwbaarheid, onderhoud en veiligheid.