AI-ondersteunde ontwikkeling is niet langer gratis

AI-ondersteunde softwareontwikkeling is een nieuwe fase ingegaan en brengt een golf van verborgen uitdagingen mee.

Een tijdlang hadden velen van ons het gevoel dat AI-hulp bijna onbeperkt was: een relatief goedkoop abonnement, een codeerassistent in de IDE en het gemak om steeds opnieuw vragen te stellen zonder veel bij de kost stil te staan.

Dat gemak verdwijnt.

Hoe meer we AI inzetten voor echt software-engineeringwerk - architectuur, debugging, refactoring, migraties, documentatie, tests, codebeoordeling en systeemontwerp - hoe duidelijker het wordt dat grondig redeneerwerk een echte prijs heeft.

Die prijs wordt vaak betaald via abonnementen, tokens, cloudgebruik of de operationele complexiteit van het beheer van lokale modellen. Maar er is nog een kost die me meer zorgen baart: de mentale kost.

De mentale kost is de hogere cognitieve belasting en de mogelijke achteruitgang van vaardigheden wanneer AI het redeneren, oplossen van problemen en nemen van beslissingen overneemt waarmee software-engineers traditioneel nauw bij hun werk betrokken bleven.

De hardwarezoektocht: lokaal versus cloud

De voorbije weken ben ik ernstig op zoek gegaan naar alternatieven voor cloudgebaseerde codeerassistenten en grote LLM's. Mijn voornaamste motivatie was praktisch: de stijgende kost van AI-ondersteunde ontwikkeling. Ik wilde begrijpen of lokale modellen een realistisch alternatief konden worden voor mijn dagelijkse werk als software-engineer en technisch architect.

Het onderzoek werd al snel een hardwarezoektocht.

Een RTX 3060 met 12 GB VRAM volstaat voor experimenten en om bij te leren, maar al snel kijk je naar kaarten met meer geheugen en zelfs naar hardware van workstationklasse. Bij elke stap wordt dezelfde les duidelijker: VRAM is de echte valuta van lokale AI. Minder geheugen betekent kleinere modellen, kleinere contextvensters, meer compromissen en minder bruikbaar redeneervermogen. Meer geheugen biedt betere mogelijkheden, maar vraagt ook een veel grotere investering.

Ik bekeek Apple Silicon-machines met unified memory, compacte AI-workstations, apparaten op basis van NVIDIA, NPU's, browsergebaseerde modellen en kleinere lokale modellen die rechtstreeks op clientmachines kunnen draaien. Elk van die opties is interessant, maar geen ervan neemt de fundamentele afweging op magische wijze weg: lokale AI is nuttig, maar vervangt sterke cloud-LLM's niet automatisch.

• Voor eenvoudigere, duidelijk afgebakende taken zijn lokale modellen zinvol: unit tests genereren, eenvoudige codetransformaties, semantisch zoeken, intelligent kopiëren en plakken, documentclassificatie, spraak-naar-tekst met Whisper-achtige modellen, lokale RAG of privacygevoelige automatisering.
• Voor grondig redeneerwerk - beslissingen op architectuurniveau, complexe debugging, analyse met veel context en hoogwaardige ondersteuning voor software-engineering - blijven de beste cloudmodellen moeilijk te vervangen.

Op een bepaald moment is de vraag niet langer technisch maar economisch. Als ik enkele duizenden euro's in lokale AI-hardware investeer, zal die investering zichzelf dan echt terugverdienen? Voor klantdemo's, on-premise-AI, verwerking van privédocumenten, semantisch zoeken, transcriptie of gespecialiseerde lokale workflows kan de waarde reëel zijn. Als vervanging van een sterke codeerassistent in de cloud voor architectuurintensieve ontwikkeling is het antwoord veel minder duidelijk.

Wat gebeurt er met ons denkvermogen?

Dat brengt ons bij een ongemakkelijkere vraag: wat gebeurt er met ons denkvermogen?

Met AI kan ik nu veel sneller ontwikkelen. Ik kan gegenereerde code beoordelen, verbeteren, refactoren, testen en in een grotere architectuur integreren. Code beoordelen is mentaal echter niet hetzelfde als code van nul schrijven.

De dagelijkse worsteling met logica, randgevallen, afhankelijkheden, falende builds, onduidelijke documentatie en moeilijke debugging heeft velen van ons tot sterke engineers gemaakt. Als AI te veel van die weerstand wegneemt, dreigen we de mentale weerbaarheid en diepgaande vaardigheden voor probleemoplossing te verliezen die we ontwikkelden door moeilijke technische uitdagingen zonder hulp aan te pakken.

Die bezorgdheid is niet alleen persoonlijk. Recent empirisch onderzoek bij professionele software-engineers wijst erop dat AI-codeerassistenten de aard van engineeringwerk fundamenteel veranderen: ze verbeteren feedbacklussen, maar beïnvloeden ook de flow en cognitieve belasting. Vella en Blincoe beschrijven een paradox tussen productiviteit en ervaring: terwijl ontwikkelaars hun algemene productiviteit hoog bleven inschatten, verdubbelde mettertijd bijna het aandeel engineers dat een slechtere ontwikkelaarservaring rapporteerde op het vlak van mentale inspanning en focus.

Mijn vader kon zonder gps rijden. Vandaag kunnen veel mensen zich niet voorstellen om zonder gps te rijden. Gps heeft vervoer niet slechter gemaakt; het heeft veranderd wat mensen elke dag doen. Misschien maakt softwareontwikkeling een gelijkaardige overgang door.

Misschien is de engineer van de toekomst niet degene die elke regel code met de hand schrijft. Misschien is het degene die het probleem helder kan definiëren, de juiste tools kiest, de output valideert, de architectuur begrijpt, de risico's beheerst en herkent wanneer AI fout zit.

Verantwoordelijkheid en discipline

AI is krachtig, maar niet perfect. AI kan hallucineren, feiten verzinnen, vereisten verkeerd begrijpen en code genereren die correct lijkt maar bij randgevallen faalt.

AI-hallucinaties zijn niet alleen technische bugs. Ze kunnen een bron worden van geloofwaardige maar foute informatie, waardoor menselijke verificatie deel uitmaakt van professionele verantwoordelijkheid. Omdat deze systemen werken met waarschijnlijkheden voor het volgende token in plaats van feitelijk begrip, missen ze het bewuste inzicht om hun eigen verzinsels te herkennen of te voorkomen.

Het geloofwaardigheidsprobleem is niet theoretisch: zelfs in expertomgevingen kunnen door AI gegenereerde of verzonnen verwijzingen onopgemerkt blijven wanneer verificatie niet systematisch gebeurt. Beveiligingsverantwoordelijken waarschuwen ook dat AI-gegenereerde software blindelings gebrekkige of verouderde codepatronen kan herhalen, waardoor systematische governance en grondige manuele codebeoordeling nog belangrijker worden.

Voor software-engineers is dat belangrijk. Als ik met AI-ondersteuning code, architectuur, documentatie of analyse oplever, blijft de verantwoordelijkheid bij mij. Ik kan tegen een klant, een team of een productiesysteem niet zeggen: de AI zei dat het zo moest.

Dat is geen engineering. AI kan het denken versnellen, maar verantwoordelijkheid niet vervangen.

In die zin neemt AI de nood aan engineeringdiscipline niet weg. Ze vergroot die nood, omdat de output er verzorgd kan uitzien terwijl ze fout is.

De ethische en ecologische kosten

Auteurschap en intellectuele eigendom brengen eveneens een kost mee. Veel AI-systemen zijn getraind op enorme hoeveelheden door mensen gemaakte inhoud.

De auteursrechtelijke vraag is niet opgelost. De denktank van het Europees Parlement merkt op dat voor de training van general-purpose AI auteursrechtelijk beschermd materiaal kan worden gebruikt en dat er ondanks de bestaande Europese regels voor auteursrecht en AI rechtsonzekerheid blijft bestaan. Een bredere studie van het Europees Parlement waarschuwt dat generatieve AI structurele risico's inhoudt voor creativiteit en een eerlijke vergoeding wanneer auteurschap en trainingspraktijken niet verantwoord worden beheerd.

Als software-engineers zijn we gewend licenties te respecteren. We letten erop of een bibliotheek MIT, Apache, GPL of propriëtair is. Waarom zouden trainingsgegevens dan worden behandeld alsof ze geen eigenaar, auteur of geschiedenis hebben? We moeten vermijden AI te gebruiken om blind propriëtaire code te kopiëren of de economische rechten van makers te omzeilen. De vraag is niet alleen: kan AI dit genereren? De betere vraag is: zou ik dit moeten genereren en begrijp ik welk menselijk werk erachter kan zitten?

Naast de ethiek kunnen we de ecologische kost niet negeren. Elke prompt die we versturen, wordt uitgevoerd op echte infrastructuur: datacenters, GPU's, elektriciteit, koelsystemen, netwerkverkeer, hardwaretoeleveringsketens en fabrieken.

Die ecologische bezorgdheid is niet abstract. Het Internationaal Energieagentschap verwacht dat het elektriciteitsverbruik van datacenters tegen 2030 ongeveer kan verdubbelen naarmate AI-workloads groeien. Wat vroeger een eenvoudig lokaal script of een menselijke beslissing was, is nu een zware inference-workload die ergens in een extern datacenter draait. Een token heeft een kost. Een GPU heeft een kost. Niet die volledige kost verschijnt op onze factuur; een deel wordt door het milieu betaald.

We focussen vaak op het onmiddellijke voordeel en negeren de verantwoordelijkheid op lange termijn. Als engineers moeten we een eenvoudige vraag kunnen stellen: lossen we het probleem van vandaag op door de last van morgen te creëren?

Conclusie: verantwoorde ondersteuning

De tools die we vandaag normaal maken, zullen bepalen hoe de volgende generatie leert, werkt, problemen oplost en de wereld begrijpt.

• Als we blinde afhankelijkheid normaliseren, erven zij misschien gemak zonder diepgang.
• Als we onzorgvuldige generatie normaliseren, erven zij misschien snelheid zonder geloofwaardigheid.
• Als we het negeren van auteurschap normaliseren, erven zij misschien productiviteit zonder eerlijkheid.
• Als we onbeperkte rekenkracht normaliseren, erven zij misschien innovatie met een ecologische schuld.

Als we daarentegen verantwoorde AI-ondersteuning normaliseren, erven ze misschien iets beters: technologie die menselijke capaciteiten vergroot zonder menselijk beoordelingsvermogen te vervangen.

Mijn conclusie is niet dat we AI moeten vermijden. Integendeel: we moeten AI gebruiken, maar doordacht. AI-ondersteunde ontwikkeling vereist nu dezelfde discipline die we al op cloudarchitectuur toepassen: kostenbewustzijn, classificatie van workloads, governance, beveiliging, privacy, verificatie en rendement op investering.

• Gebruik sterke cloudmodellen waar grondig redeneerwerk echte waarde creëert.
• Gebruik lokale modellen voor taken die kleiner, herhaalbaar, privé of kostengevoelig zijn.
• Gebruik deterministische tools, tests, documentatie en klassieke engineering waar die nog altijd het betere antwoord bieden.

Houd een deel van de klassieke engineeringpraktijk in leven, want diep kunnen nadenken blijft het belangrijkste instrument dat we hebben. AI is niet langer alleen een plug-in in de IDE; ze wordt onderdeel van softwarearchitectuur. En zoals elk krachtig instrument is AI niet gratis - financieel, mentaal, ethisch, ecologisch of professioneel.

De verantwoordelijke engineer van het AI-tijdperk is niet degene die AI voor alles gebruikt. Het is degene die begrijpt wanneer, waarom, hoe en ten koste van wie AI moet worden gebruikt.

Referenties

International Energy Agency. (2025). Energy and AI: Energy demand from AI. https://www.iea.org/reports/energy-and-ai/energy-demand-from-ai

Vella, A., and Blincoe, K. (2026). The Impact of AI Coding Assistants on Software Engineering: A Longitudinal Study. arXiv:2605.23135. https://arxiv.org/abs/2605.23135

Shao, A. (2025). New sources of inaccuracy? A conceptual framework for studying AI hallucinations. Harvard Misinformation Review. https://misinforeview.hks.harvard.edu/article/new-sources-of-inaccuracy-a-conceptual-framework-for-studying-ai-hallucinations/

Marcelin, T., and Cassetti, F. (2025). AI and copyright: The training of general-purpose AI. European Parliamentary Research Service. https://www.europarl.europa.eu/thinktank/en/document/EPRS_ATA(2025)769585

European Parliament. (2025). Generative AI and Copyright: Training, Creation, Regulation. https://www.europarl.europa.eu/thinktank/en/document/IUST_STU(2025)774095