Waarom bedrijven nog steeds menselijke ontwikkelaars nodig hebben, zelfs met door AI gegenereerde code

Elke AI-coderingstool kan syntactisch correcte code genereren als je erom vraagt. Maar kunnen ze bedrijfssoftware bouwen? En de echte vraag is:hebben we nog softwareontwikkelaars nodig?

Softwareontwikkeling is altijd meer geweest dan ontwerpen en code. Het gaat om beveiliging, begrijpen wat AVG, SOC 2 en intern bedrijfsbeleid vereisen, en weten wie verantwoordelijk is als er iets mislukt.

Het vereist edge-case redenering en institutionele kennis die geen enkele prompt kan bieden. Enterprise-software heeft iemand nodig die architectonische beoordelingen kan maken en een plan kan opstellen voor hoe systemen in de loop van de tijd moeten worden gestructureerd.

Maar AI heeft de manier veranderd waarop ontwikkelaars werken.

De rol van een ontwikkelaar is verschoven van het schrijven van code naar het valideren, orkestreren en bezitten van resultaten.

En die verschuiving is precies waarom grote bedrijven nog steeds softwareontwikkelaars nodig hebben, zelfs als AI de code schrijft.

Wat 'AI-code schrijven' eigenlijk betekent in bedrijfsomgevingen

Als we zeggen dat AI code schrijft, bedoelen we eigenlijk dit:je geeft een prompt in natuurlijke taal en de tool retourneert syntactisch correcte uitvoer. Het verwerkt op betrouwbare wijze boilerplate-, unit-tests en standaardfuncties.

Maar dat betekent niet dat het uw systeem begrijpt.

Het kent uw architectuur, uw compliancevereisten of de bedrijfslogica niet die zich door jarenlange afwegingen heeft ontwikkeld. In bedrijfsomgevingen is dat de kloof tussen een nuttig productiviteitshulpmiddel en iets dat productiesoftware kan bouwen.

Enterprise-systemen leven ver buiten de nette grenzen van een prompt. Productiecode bevat jaren van opgebouwde logica, niet-standaard integraties, wettelijke beperkingen en architecturale beslissingen die zijn genomen lang voordat de huidige taak bestond. Die context leeft zelden op één plek, en wordt nooit in één enkele prompt vastgelegd.

Moderne modellen doen meer dan pure patroonafstemming. Ze vertonen echte redeneervermogens. Maar bedrijfssoftware hangt af van hoe uw specifieke systeem zich gedraagt, onder welke beperkingen het functioneert en hoe teams het in de loop van de tijd onderhouden. Geen enkele redenering kan deze kloof dichten zonder context.

AI kan code produceren die op zichzelf correct is. Enterprise-software moet in de context correct zijn:binnen een bepaald systeem, onder specifieke regels, onderhouden door echte teams.

Waarom het genereren van AI-code ≠ de ontwikkeling van bedrijfssoftware

Het genereren van code met behulp van AI wordt automatisch op schaal aangevuld. De ontwikkeling van bedrijfssoftware staat onder druk. Het gaat om weten wat je moet bouwen, waarom het architectonisch bij elkaar blijft, en wie antwoordt als het om 02.00 uur kapot gaat.

AI kan code produceren, maar kan geen systeem, beslissing of gevolg bezitten, althans voorlopig niet.

De kloof wordt duidelijker als je kijkt naar wat bedrijfsontwikkeling eigenlijk inhoudt naast het schrijven van code:het ontwerpen van systemen, het bezitten van resultaten in de productie en het opereren binnen beperkingen die AI niet kan zien.

Laten we dat eens opsplitsen.

1. Code schrijven

Het genereren van code is indrukwekkend op lijn- en functieniveau. Met een goed gedefinieerde prompt kan een model alles produceren, van een werkend API-eindpunt tot een databasequery, vaak sneller dan een senior engineer die helemaal opnieuw typt.

Maar het schrijven van nieuwe code is een verrassend klein onderdeel van het werk van een ontwikkelaar. Uit het rapport van IDC uit 2024 blijkt dat de ontwikkeling van applicaties ongeveer 16% van de ontwikkelaarstijd in beslag neemt. De veel geciteerde observatie van Robert C. Martin schat de lees-schrijfverhouding op ruim 10 op 1.

De rest bestaat uit het lezen van de bestaande code, het begrijpen van de bedoelingen, het opsporen van fouten, het onderhandelen over compromissen en het voeren van telefoontjes zonder duidelijk antwoord.

2. Systemen ontwerpen

Bij systeemontwerp wordt de complexiteit van een onderneming meedogenloos. Een prompt kan een AI geen dingen vertellen als:

• De betalingsservice is gebouwd door een team dat niet meer bestaat, en elke wijziging daarin vereist coördinatie tussen drie complianceteams
• Het bedrijf koos drie jaar geleden voor consistentie vanwege prestatieredenen, en het terugdraaien van die beslissing betekent nu dat 400 miljoen records opnieuw moeten worden gemigreerd
• De nieuwe microservice die u genereert, wordt eigendom van een team in een andere tijdzone met verschillende oproeproulaties

Enterprise-systemen zijn geen greenfield. Ze dragen technische schulden met zich mee als gevolg van beslissingen die zijn uitgesteld, en van integraties die alleen bestaan omdat twee systemen na een overname gedwongen werden samen te werken.

Een goed systeemontwerp in deze omgeving vereist een historische context (waarom compromissen uit het verleden zijn gemaakt), het in kaart brengen van beperkingen (niet-onderhandelbare wettelijke, contractuele en operationele grenzen), redeneren over falen ('Hoe mislukt dit en hoe erg?') en organisatiebewustzijn (wie hangt hiervan af en wie zal worden verbroken door het te veranderen).

Een LLM-genererende code heeft dit allemaal niet. Het redeneert over de code ervoor, niet over het systeem erachter.

3. Eigenaar zijn van resultaten in de productie

Productie is geen testomgeving. In bedrijfssoftware is een bug geen mislukte unit-test. Het gaat om een inkomstengebeurtenis, een nalevingsincident, een falend klantvertrouwen of, in gereguleerde sectoren, een juridisch risico.

De kosten van een productiestoring worden gemeten aan de hand van SLA-schendingen, incidentrapporten en post-mortems met zichtbaarheid van de leidinggevenden.

In bedrijfsomgevingen betekent eigendom:

• U bent verantwoordelijk als het systeem zich onverwacht gedraagt
• Je draagt de context van mislukkingen uit het verleden met je mee en gebruikt deze om deze anders te ontwerpen
• Je hebt een afweging gemaakt over een afweging zonder een perfect antwoord, en je staat erachter
• Jij bent degene die om 02.00 uur de fout oplost als de monitoringwaarschuwing afgaat

Het genereren van code levert output op. Het leidt niet tot verantwoordelijkheid. Het heeft geen belang bij correctheid buiten de prompt, geen herinnering aan de laatste storing en geen mogelijkheid om te worden opgeroepen.

4. De ondernemingsmultiplier

Dit alles wordt verergerd door schaalgrootte. Enterprise-software betekent:

• Gedistribueerd eigendom: meerdere teams die samenwerken met hun eigen normen en prikkels
• Regelgevingsoppervlakte: Naleving van de AVG, SOX, HIPAA en PCI-DSS is ingebouwd in de architectuurbeslissingen
• Levensduurvereisten: systemen die over 10 tot 20 jaar zullen functioneren en evolueren
• Integratiedichtheid: niet drie diensten die met elkaar praten, maar honderden, vaak over organisatie- en leveranciersgrenzen heen

In deze omgeving bestaat de gevaarlijke illusie erin dat code-uitvoer wordt aangezien voor technisch oordeel. Een junior ontwikkelaar die met behulp van AI een werkende functie genereert, heeft niet automatisch de capaciteit ontwikkeld om het systeem waarin het leeft te ontwerpen, te anticiperen op hoe het zal falen, of eigenaar te zijn van wat er gebeurt als het mislukt.

De code is het makkelijke gedeelte. De onderneming is het moeilijkste deel. En AI helpt, zoals het er nu uitziet, slechts bij één daarvan.

Waar bedrijven nog softwareontwikkelaars voor nodig hebben

Bedrijven hebben nog steeds ontwikkelaars nodig omdat software die op grote schaal draait wettelijke aansprakelijkheid met zich meebrengt en niet mag falen. Het vereist menselijk oordeel, institutioneel geheugen en verantwoordelijkheid, en geen daarvan kan tot stand worden gebracht of aan een model worden gedelegeerd.

1. Systeemarchitectuur en langetermijnontwerp

Architectuur is een reeks onomkeerbare beslissingen die worden genomen op basis van onvolledige informatie.

Ontwikkelaars kiezen niet alleen patronen; ze coderen organisatorische beperkingen in servicegrenzen, data-eigendom en koppelingsbeslissingen die ofwel dividend uitkeren ofwel een belasting voor de komende tien jaar inhouden.

AI kan een dienst genereren. Het kan niet beslissen waar de grens van die dienst zou moeten liggen, of waarom die grens nog steeds zinvol zal zijn als het bedrijf in omvang verdubbelt, van richting verandert of een concurrent overneemt.

2. Beveiliging, naleving en verantwoordelijkheid

Beveiliging is een architectonisch eigendom, geen kenmerklaag.

Het modelleren van dreigingen vindt plaats tijdens het ontwerp, en in gereguleerde omgevingen (SOX, HIPAA, PCI-DSS) creëert elke beslissing een juridisch en financieel spoor dat een met naam genoemde mens moet bezitten en verdedigen.

De gegevens ondersteunen deze zorg. Uit het GenAI Code Security Report 2025 van Veracode blijkt dat door AI gegenereerde code 2,74x meer kwetsbaarheden bevat dan door mensen geschreven code, getest in meer dan 100 LLM's en vier programmeertalen. Uit een afzonderlijk onderzoek uit 2026 bleek dat één op de vier AI-codevoorbeelden een bevestigd beveiligingsprobleem bevat, waarbij 45% OWASP Top 10-fouten introduceert.

Als een toezichthouder vraagt waarom er op een bepaalde manier met klantgegevens wordt omgegaan, is ‘het model suggereerde dit patroon’ geen antwoord. Door AI gegenereerde code heeft geen juridische status, geen aansprakelijkheid en geen besef van wat niet-naleving feitelijk kost.

3. Afhandeling van uitzonderingen en randgevallen

Het verwachte pad is eenvoudig. Bij het falen van het 99e percentiel verdienen bedrijfssystemen hun geloofwaardigheid.

Het is de plek waar betalingsgateways halverwege de transactie een time-out krijgen, waar downstream-systemen verkeerd opgemaakte reacties verzenden onder piekbelasting, en waar een database-failover plaatsvindt tijdens een live migratie.

Ervaren ontwikkelaars kennen deze fouten uit de eerste hand. Ze coderen niet alleen defensief tegen randgevallen. Ze hebben ze meegemaakt.

Ze kennen de API's van derden die liegen over hun foutcodes en de API's waarbij de fout catastrofaal optreedt. Dit staat niet in trainingsgegevens.

4. Oudere systeemintegratie

De meeste bedrijfssoftware leeft samen met systemen die zijn gebouwd in technologieën die dateren van vóór het huidige team, soms tientallen jaren:COBOL-batchprocessen die moderne API's voeden, ERP-systemen met ongedocumenteerde bijwerkingen, mainframe-datamodellen die zijn geabstraheerd achter kwetsbare servicelagen.

Dit werk gaat volledig over wat niet gedocumenteerd is. Ontwikkelaars die dit doen, hebben historische beperkingen van eerdere integraties met zich mee, kennen ongedocumenteerde risico's en begrijpen welke aannames stilletjes zullen breken als ze worden geschonden. AI ziet alleen wat er wordt getoond.

5. Betrouwbaarheid, monitoring en respons op incidenten

Verzendcode is het begin. Het echte werk is het draaiende houden:ontwerpen voor zichtbare fouten, waarschuwingen kalibreren die signaleren in plaats van ruis toevoegen, en dashboards bouwen die de aanwezige technicus binnen enkele seconden vertellen wat er kapot is en waarom.

Als er incidenten plaatsvinden, gaat een ontwikkelaar op onderzoek uit, besluit of er een rollback of een patch forward nodig is, informeert belanghebbenden en voert de autopsie uit om herhaling te voorkomen.

Deze cyclus van ontwerpen, observeren, falen en leren heeft gevolgen die een codegenerator niet kan veroorzaken.

Wat er misgaat als bedrijven te veel vertrouwen op door AI geschreven code

Overmatig vertrouwen op door AI geschreven code faalt niet luid. Het mislukt geleidelijk. Systemen stapelen stilletjes schulden op, en de gaten komen pas aan het licht onder druk:tijdens een incident, een audit of een inbreuk op de beveiliging.

1. Technische schuld

AI genereert code die werkt voor de prompt, niet voor het systeem. Zonder architectonisch oordeel dat elke uitvoer begeleidt, accumuleert de codebase inconsistente patronen en overtollige abstracties die lokaal redelijk maar mondiaal duur zijn.

En het gebeurt snel. Schulden die in het tempo van AI zijn ontstaan, komen sneller binnen dan welk team dan ook kan absorberen.

Teams die zich haasten om te verzenden zonder zelf de ontwerpbeslissingen te nemen, eindigen met een codebase die niemand volledig begrijpt, een code die meer kost om te refactoren dan om te schrijven.

2. Stille mislukkingen

Door AI gegenereerde code kan het gelukkige pad doorgaans goed aan, en het mislukkingspad slecht. Randgevallen die niet in de prompt stonden, worden eenvoudigweg niet afgehandeld, en in tegenstelling tot een syntaxisfout wordt een ontbrekende foutmodus pas aangekondigd als de omstandigheden precies verkeerd zijn.

Stille fouten vormen de gevaarlijkste klasse van bedrijfsbugs. Een betaling die twee keer wordt verwerkt, een record dat gedeeltelijk wordt geschreven, een waarschuwing die nooit wordt geactiveerd:deze komen niet naar voren tijdens het testen.

Ze veroorzaken geen monitoring. Ze worden ontdekt door gevolgen stroomafwaarts, meestal lang nadat de schade is aangericht.

3. Beveiligingsrisico's

Modellen genereren code op basis van patronen in hun trainingsgegevens, waaronder onveilige patronen, verouderde bibliotheken en verouderde benaderingen. Zonder dat een ontwikkelaar de uitvoer actief modelleert, worden kwetsbaarheden samen met functies verzonden:SQL-injectie komt naar boven, geheimen worden hardgecodeerd en invoervalidatie wordt overgeslagen.

Het subtielere risico is vals vertrouwen.

AI-code die de codebeoordeling en het automatische scannen doorstaat, kan nog steeds architecturale kwetsbaarheden bevatten:geschonden vertrouwensgrenzen, open escalatieroutes voor privileges, gegevensblootstelling die in het ontwerp is ingebakken. Deze vereisen een menselijke veiligheidsredenering, en geen pluisjes.

4. Verlies van systeembegrip

Het grootste risico is niet van technische aard. Het is organisatorisch.

Wanneer ontwikkelaars AI gebruiken om code te genereren, lezen, debatteren en bezitten ze de institutionele kennis over hoe het systeem werkt niet volledig.

Na verloop van tijd verliezen ontwikkelaars het vermogen om over het systeem als geheel te redeneren. Het resultaat is een codebasis die niemand begrijpt en die niemand veilig kan veranderen.

Sommige bedrijven implementeren al tegenmaatregelen:verplichte beoordelingen van codebegrip, pair-programmering met AI-tools, strengere PR-normen.

Maar zonder doelbewuste inspanning blijft dit een structurele kwetsbaarheid die zich rustig opbouwt totdat iets het team dwingt er de confrontatie mee aan te gaan.

Hoe de rol van zakelijke ontwikkelaars verandert

De rol van de bedrijfsontwikkelaar evolueert van het schrijven van code naar het beheren ervan, en van handmatige implementatie naar AI-ondersteunde orkestratie, verankerd in het oordeelsvermogen en de verantwoordelijkheid die alleen een mens kan bieden.

1. Van schrijven tot valideren

De primaire output van een ontwikkelaar bestaat niet langer uit regels code; het zijn beslissingen over code. Dat betekent dat we de door AI gegenereerde output kritisch moeten lezen en identificeren wat er ontbreekt of op subtiele wijze verkeerd is, alleen datgene goedkeuren wat geschikt is voor een productiesysteem dat reële gevolgen heeft, en veiligheidslacunes, weglatingen in de randvoorwaarden en architectonische afwijkingen opsporen voordat ze worden verzonden.

Dit vereist meer oordeel, niet minder. Een ontwikkelaar die geen code kan schrijven, is zeker niet uitgerust om deze te valideren.

2. Van implementeren tot orkestreren

Ontwikkelaars zijn steeds meer verantwoordelijk voor het samenstellen van systemen uit door AI gegenereerde componenten, services van derden en interne platforms. De implementatiewerkzaamheden nemen af; het integratie- en coördinatiewerk neemt toe.

Dat betekent het beheren van contracten en interfaces tussen samengestelde componenten, het zorgen voor coherent gedrag tussen systemen die uit verschillende bronnen zijn opgebouwd, het bezitten van fouten in de naden waar componenten samenkomen en aannames breken, en het coördineren tussen teams, leveranciers en platforms in plaats van elke laag te schrijven.

Het ambacht verschuift van auteurschap naar architectuur, en van uitvoering naar ontwerp.

3. Van snelheid naar veiligheid en veerkracht

AI verhoogt de snelheid van codeproductie. De last voor zakelijke ontwikkelaars is ervoor te zorgen dat snelheid de veiligheid niet in gevaar brengt. Dat betekent het bezitten van:

• Waarneembaarheid :instrumentatie en logboekregistratie ingebouwd door het ontwerp, niet achteraf ingebouwd
• Herstelbaarheid :terugdraaipaden en foutgrenzen gedefinieerd voordat ze nodig zijn
• Verdedigbaarheid :architecturale beslissingen die stand houden onder toezicht van de toezichthouder of postmortem
• Tempo :weten wanneer je moet vertragen omdat het risicoprofiel dit vereist

De waardepropositie van de ontwikkelaar in een AI-augmented omgeving is niet snelheid. Het is het oordeel dat ervoor zorgt dat snelheid geen aansprakelijkheid wordt.

Wanneer AI ontwikkelaars moet helpen, en niet moet vervangen

AI levert een echte hefboomwerking op als het functioneert als een instrument onder menselijke leiding. Op het moment dat het bedrijf wordt behandeld als beslisser op het gebied van architectuur, beveiliging of compliance, heeft de onderneming verantwoordelijkheid vervangen door automatisering en oordeelsvermogen door waarschijnlijkheid.

Waar AI een hefboomwerking biedt

AI is het meest waardevol in de delen van de ontwikkeling die bij de eerste poging veel volume hebben en weinig op het spel staan. Sterke gebruiksscenario's zijn onder meer:

• Boilerplate-generatie: steigers, CRUD-operaties, repetitieve patronen in services
• Testschrijven :het genereren van eenheids- en integratietestgevallen op basis van bestaande functiehandtekeningen
• Documentatie :inline opmerkingen, API-documenten en README-inhoud opstellen vanuit codecontext
• Hulp bij codebeoordeling :voor de hand liggende problemen, inconsistente patronen en stijlschendingen aan het licht brengen
• Ondersteuning voor refactoring :herstructureren van goed begrepen code met duidelijke voor/na-intentie
• Foutopsporing in versnelling :foutbronnen beperken en mogelijke oplossingen voorstellen
• Prototyping :snel verkennen hoe een oplossing eruit zou kunnen zien voordat je een aanpak kiest

In al deze gevallen comprimeert AI de tijd. Een ontwikkelaar is nog steeds eigenaar van de uitvoer, maar bereikt deze sneller.

Waar menselijk oordeel niet onderhandelbaar is

Er is een duidelijke reeks beslissingen waarbij het verwijderen van de mens niet alleen maar risico's met zich meebrengt. Het elimineert de verantwoordingsstructuur waarvan de onderneming afhankelijk is:

• Systeemontwerp en servicegrenzen: beslissingen die de codebase jarenlang zullen beperken
• Beveiligingsarchitectuur :bedreigingsmodellering, vertrouwensgrenzen, privilege-ontwerp
• Nalevingsbeslissingen: welke gegevens worden verzameld, hoe deze worden opgeslagen, wie er toegang toe heeft
• Productie-incidenten :diagnose, escalatie, terugroepgesprekken onder druk
• Oude integratie :navigeren door ongedocumenteerd gedrag en het minimaliseren van de explosieradius
• Afwegingsoplossing :kiezen tussen concurrerende beperkingen zonder duidelijk antwoord
• Postmortems en leren :institutionele kennis uit mislukkingen halen

Dit zijn geen taken die AI slecht uitvoert. Het zijn taken waarbij de menselijke beslissing zelf deel uitmaakt van wat de onderneming nodig heeft.

Waarom Human-in-the-Loop belangrijk is in ondernemingen

In consumentensoftware veroorzaakt een slechte, door AI gegenereerde beslissing een bug. Bij bedrijfssoftware kan dit leiden tot een schending van de compliance, een beveiligingsincident of een storing met contractuele gevolgen. De inzet verandert wat de lus moet bevatten.

Human-in-the-loop in een bedrijfscontext betekent dat er geen door AI gegenereerde code in productie komt zonder dat de ontwikkelaar zich heeft aangemeld. Het betekent dat architectuurbeslissingen voorafgaan aan de door AI ondersteunde implementatie, en niet andersom.

Elke systeembeslissing is terug te voeren op een genoemde ingenieur die deze begreep en onderschreef. AI-output wordt behandeld als een concept, niet als een resultaat. En monitoring, waarschuwingen en respons op incidenten blijven door mensen ontworpen en uitgevoerd.

Het doel is niet om AI te vertragen. Het is bedoeld om ervoor te zorgen dat de snelheid die AI biedt de verbinding tussen beslissingen en gevolgen niet verbreekt, wat de verbinding is waarop bedrijfssoftware, regelgeving en organisatorisch vertrouwen allemaal zijn gebouwd.

Conclusie

Softwareteams zijn nog steeds belangrijk omdat de moeilijkste onderdelen van de bouwtechnologie (architectuur, verantwoordelijkheid, institutioneel geheugen) altijd menselijke besluitvorming vereisen.

De nieuwe realiteit is eenvoudig:verbeter de tools die beschikbaar zijn voor ontwikkelaars, vervang ze niet. Gebruik AI om het denken aan te scherpen, en niet om het te vervangen. En implementeer dit in het besef dat iemand uiteindelijk eigenaar zal zijn van de uitkomst.

De organisaties die de komende tien jaar de meest duurzame software bouwen, zullen niet degenen zijn die de meeste code genereren. Zij zullen degenen zijn die de snelheid van AI koppelen aan het menselijk oordeel, en precies weten waar de grens tussen die twee moet liggen.

Als u een realistische partner nodig heeft om u te helpen uitzoeken waar AI een netto positief punt is in uw technische organisatie en waar het risico's met zich meebrengt, dan is het team van Imaginovation kan u helpen bij het opstellen van die routekaart.

Laten we praten.