Neem contact met ons op:
Type something to search...
to navigateto selectESC to close
Maakt AI je team slechter?

Maakt AI je team slechter?

We zien steeds vaker dat developers minder leren als ze met AI werken. Een developer levert een feature op in de helft van de tijd. De code werkt, de PR wordt gemerged, iedereen blij. Alleen kan diezelfde developer de code niet meer debuggen zonder AI. De feature is opgeleverd, maar er is niks geleerd. De developer vertrouwt volledig op AI.

Deze week kwamen we een studie tegen die bevestigt wat we al zagen. Anthropic publiceerde een studie genaamd “How AI Impacts Skill Formation”. Die bevestigt iets waar engineering leaders zich zorgen over maken: AI coding tools kunnen de ontwikkeling van programmeervaardigheden belemmeren.

Het onderzoek van Anthropic

Onderzoekers deden een experiment met developers die Python Trio leerden, een library voor asynchrone programmering. Ze kozen Trio omdat het een aantal nieuwe concepten bevat zoals structured concurrency. De helft van de deelnemers had AI-hulp, de andere helft niet.

De resultaten waren interessant: de AI-groep scoorde 17% lager op kennistests. Dat is een verschil van 4,15 punten op een quiz van 27 punten, met een effect size van Cohen’s d = 0,738. Het grootste verschil zat bij debuggen, precies de vaardigheid die je nodig hebt als er iets kapot gaat in productie.

De AI-groep liep tegen veel minder fouten aan tijdens het leren. De mediaan was 1 fout met AI tegen 3 zonder. Klinkt als een voordeel, maar developers leren juist van fouten. RuntimeWarnings, TypeErrors, de frustratie van debuggen: die momenten dwingen je om te begrijpen hoe je code werkt. AI haalde de worsteling weg, en daarmee ook het leren.

Hoe developers AI gebruiken

Het onderzoek vond zes patronen in hoe developers AI gebruiken, met heel verschillende resultaten.

Drie patronen werden geassocieerd met slecht leren (quizscores tussen 24-39%):

  • AI Delegation: Alles aan AI overlaten voor codegeneratie
  • Progressive AI Reliance: Beginnen met vragen stellen maar geleidelijk alle codering delegeren
  • Iterative AI Debugging: AI gebruiken om bugs te fixen zonder te begrijpen waarom ze gebeurden

Met deze drie patronen leerden developers (quizscores tussen 65-86%):

  • Generation-Then-Comprehension: Code laten genereren maar daarna vragen stellen om het te begrijpen
  • Hybrid Code-Explanation: Zowel code als uitleg tegelijk vragen
  • Conceptual Inquiry: Alleen conceptuele vragen stellen, dan zelf de code schrijven

Developers leren wanneer ze mentaal bezig zijn met het probleem.

Wat dit betekent

Ten eerste: wat gebeurt er met je toekomstige senior engineers? Juniors worden senior door problemen op te lossen: debuggen, fouten maken, intuïtie ontwikkelen voor waarom dingen falen. Als AI dit proces overslaat voor een hele generatie engineers, kunnen organisaties straks te weinig mensen hebben die kunnen doorgroeien naar senior technische rollen.

Een ander effect is het gebrek aan diepgaande kennis van frameworks en programmeertalen. Als AI de standaard wordt om nieuwe tech te leren, krijg je teams die afhankelijk zijn van dingen die ze niet begrijpen. We zien dit al: snel opstarten met AI, maar daarna vastlopen bij debugging of grotere wijzigingen.

Dit is extra belangrijk in kritieke domeinen. Security, infrastructuur, financiële systemen: allemaal hebben ze mensen nodig die code kunnen reviewen, niet alleen accepteren wat AI genereert. Je kunt code niet effectief reviewen voor een library die je niet begrijpt. Je kunt geen code reviewen als je niet begrijpt wat je ziet.

We schreven eerder over onderzoek dat laat zien dat ervaren developers 19% langzamer waren bij het gebruik van AI voor echte taken. Als je daar ook nog minder goed kunnen debuggen bij optelt, beginnen de langetermijnkosten groter te worden dan de kortetermijnwinst.

Wat organisaties kunnen doen

Het onderzoek is geen argument tegen AI coding tools. We gebruiken ze zelf dagelijks. Het is een argument om bewust na te denken over hoe ze worden gebruikt, vooral wanneer leren onderdeel is van het doel.

Maak begrip onderdeel van code review. Vraag developers om uit te leggen hoe hun code werkt. In het onderzoek zochten de developers die wél leerden actief naar uitleg. Code review kan die gewoonte versterken.

Herken wanneer leermodus anders is dan productiemodus. Er is een echt verschil tussen AI gebruiken om een feature te bouwen in technologie die je goed kent, en AI gebruiken om iets nieuws te leren. Organisaties die dit onderscheid erkennen, kunnen hun verwachtingen aanpassen. Bij leren is langzamer vaak beter.

Houd wat productieve worsteling in het proces. Wanneer developers nieuwe technologieën leren, overweeg om AI-hulp te beperken of te focussen op uitleg in plaats van codegeneratie. Zelf door problemen heen werken is langzamer, maar je behoudt wat je leert.

Let op tekenen van afhankelijkheid. Developers die code niet kunnen uitleggen die ze zelf schreven, die moeite hebben met debuggen zonder AI, of die vastlopen op technologieën die ze zogenaamd al maanden gebruiken. Dat zijn signalen: ze leren niet echt.

Investeer in echt begrip, ook als het langzamer is. Code die niemand echt begrijpt is technical debt, ook als de code zelf werkt. Geef developers de tijd om kritieke systemen echt te leren kennen. Die investering betaalt zich terug wanneer ze aan die systemen moeten bouwen of als ze problemen moeten oplossen.

Sneller is niet hetzelfde als beter

Met AI coding tools lever je sneller, maar je bouwt mogelijk minder kennis op. Dat werkt voor ervaren developers in technologie die ze kennen. Niet voor developers die iets nieuws leren, of teams die complexe systemen moeten onderhouden.

Zoals de onderzoekers schrijven: “AI-enhanced productivity is not a shortcut to competence.” Wie dat negeert, krijgt teams die wel code produceren maar niet snappen wat ze doen.

AI gaat niet meer weg. Laten we zorgen dat het teams beter maakt.

We helpen organisaties bij het opzetten van engineering practices die werken op de lange termijn. Wil je praten over hoe je AI inzet? Neem contact op.

Tags:
AI coding Skill development Developer productivity Engineering leadership
Delen:
Laatste Artikelen
Categorieën
Tags

Gerelateerde Artikelen

Engineering
De verborgen kosten van vibe coding
Door Lumia Labs/ Op 08 Jan, 2025

De verborgen kosten van vibe coding

De demo was indrukwekkend. Een developer typte een prompt, en binnen seconden verscheen werkende code. Eindelijk een manier om sneller te leveren. Zes maanden later zit datzelfde team tot over de oren in technical debt. Ze debuggen code die niemand volledig begrijpt. En ze vragen zich af waarom hun "versnelde" project inmiddels drie maanden achterloopt. We hebben dit vaker zien gebeuren. Volgens MIT's GenAI Divide rapport levert 95% van de enterprise AI-pilots geen meetbare omzetgroei of kostenbesparing. Opvallend: 42% van de bedrijven stopte in 2025 met het merendeel van hun AI-initiatieven, meer dan het dubbele van het jaar ervoor. Wat gaat er mis? En belangrijker: hoe beoordeel je AI coding tools voordat je ze inzet? De flow-debt trade-off AI coding tools zijn heel goed in het snel genereren van logisch uitziende code. Die snelheid voelt als productiviteit, maar dat is het niet altijd. Het patroon dat we vaak zien: de snelheid schiet omhoog, developers voelen zich productiever, en de eerste features worden snel opgeleverd. Dan beginnen de problemen. De gegenereerde code werkt, maar zit vol verborgen aannames. Database queries die hele tabellen scannen. Authenticatieflows die edge cases overslaan. API-contracten die uitgaan van ideale omstandigheden. Elk stukje code lijkt logisch op zichzelf, maar samen creëren ze een systeem dat met elke toevoeging moeilijker te wijzigen wordt. Onderzoekers noemen dit de flow-debt trade-off: de soepele ervaring van code genereren leidt tot een ophoping van technical debt door architecturele inconsistenties, beveiligingslekken en onderhoudslast die zich pas later openbaart. Geen architectuur, geen context Dezelfde patronen duiken keer op keer op in AI-gegenereerde code, allemaal terug te voeren op dezelfde beperking: AI tools optimaliseren voor de directe taak, niet voor het systeem als geheel. Architectuur verdwijnt naar de achtergrond. De AI kent je infrastructuur niet, weet niet wat je team aankan, en heeft geen idee van je roadmap. Het resultaat: monolithische structuren die in het begin prima werken, maar lastig op te splitsen zijn als je wilt schalen. Database queries blijven ongeoptimaliseerd. Gegenereerde code gebruikt vaak ORM-patronen die inefficiënte queries verbergen. Het werkt prima met 1.000 records. Bij 100.000 records schieten de responstijden omhoog. Bij een miljoen wordt het systeem onbruikbaar tijdens piekmomenten. Error handling blijft oppervlakkig. AI genereert het happy path goed. Minder consistent is het met foutscenario's, retry-logica, circuit breakers en graceful degradation. Systemen die zo gebouwd worden, werken tot er iets misgaat, en falen dan op onvoorspelbare manieren. Security blijft bij de basis. Inputvalidatie is er wel, maar kwetsbaarheden in de businesslogica worden gemist. Er zijn autorisatiechecks, maar gebruikers kunnen meer rechten krijgen dan de bedoeling is. De code lijkt veilig, maar is het niet. Monitoring schiet tekort. Er wordt wel gelogd, maar niet op een manier die helpt bij het debuggen in productie. Metrics, traces en alerts ontbreken bijna altijd. Best practices Als je AI coding tools gebruikt (en de meeste teams doen dat), kun je zo de voordelen pakken zonder de technical debt: Meet de totale kosten, niet de initiële snelheid. Houd bij hoeveel tijd je besteedt aan het debuggen van AI-gegenereerde code, het refactoren van architectuurbeslissingen en het oplossen van beveiligingsbevindingen. Vergelijk dat met de bespaarde tijd tijdens het genereren. Voer je security reviews uit. Verminder de aandacht niet omdat de code "van AI komt." Verhoog die eerder. Gegenereerde code passeert vaak een vluchtige review terwijl subtiele problemen verborgen blijven. Toets architecturele samenhang. Onderzoek regelmatig of de codebase nog klopt met de architectuur. Afwijken is eenvoudig met gegenereerde code, omdat LLMs niet genoeg context hebben om over de hele codebase te optimaliseren. Blijf code reviewen. Bij AI-gegenereerde code is review juist belangrijker. Maak jij de PR? Lees je eigen code eerst kritisch door. De AI schreef het, maar jij zet je naam eronder. Plan refactoring in. AI-ondersteunde codebases hebben doorgaans agressievere refactoring nodig dan traditioneel ontwikkelde. Begroot dit van tevoren. Zet mensen op de kritieke onderdelen. Authenticatie, autorisatie, betalingen en data: daar wil je altijd een mens naar laten kijken. Succesvol met AI Organisaties die succesvol zijn met AI doen het volgende: ze behandelen gegenereerde code als startpunt in plaats van eindproduct, houden strak toezicht op de architectuur, en investeren in code review practices die de systematische problemen van AI opvangen. Ze erkennen ook dat developer productiviteit en systeemkwaliteit verschillende metrics zijn. Optimaliseren voor de een ten koste van de ander creëert problemen die jaren kosten om op te lossen. Wij bouwen al 25 jaar enterprise systemen. De fundamenten zijn niet veranderd: goede architectuur stelt teams in staat om snel te ontwikkelen. AI tools veranderen dit niet. Ze maken het alleen verleidelijker om de fundamentele basis van software engineering over te slaan. Als je AI coding tools evalueert, begin dan met afgebakende experimenten. Meet uitkomsten over maanden, niet dagen. En denk na over architectuur voordat je duizenden regels gegenereerde code hebt die niemand volledig begrijpt. De technologie is waardevol. De balans vinden vraagt om een menselijke aanpak.Lumia Labs helpt organisaties schaalbare systemen te bouwen en bestaande codebases te verbeteren. Neem contact op.

Engineering
De Architectuur Review Checklist
Door Lumia Labs/ Op 16 Jan, 2026

De Architectuur Review Checklist

Een software systeem overnemen is een uitdaging. Misschien ben je net begonnen als CTO of nieuwe developer. Misschien heeft je bedrijf software overgenomen. Misschien zijn de oprichters of het oude team vertrokken en is het nu aan jou. De documentatie is karig. De git-historie vertelt verhalen waar je niet bij was. Het systeem draait, meestal, maar je weet niet precies waarom. Laat staan wanneer het gaat omvallen. Dit artikel geeft je vragen. Vragen die problemen blootleggen voordat ze zichzelf aankondigen. Je leert meer van de vragen die je niet kunt beantwoorden dan van de vragen die je wel kunt beantwoorden. Elke keer dat je "geen idee" moet zeggen, weet je waar je op kunt focussen. Drie gebieden zijn belangrijk: beveiliging, operations en aanpasbaarheid. Elk gebied legt andere risico's bloot, en samen vertellen ze je wat voor software je in huis hebt. Beveiliging Beveiliging in dit soort systemen is speurwerk. Beslissingen genomen door mensen die er niet meer zijn, gebaseerd op aannames die misschien niet meer kloppen. Jouw taak: uitpluizen. Kun je het volledige pad volgen van gebruikersinvoer naar de database? Authenticatie zit in de ene service, autorisatie ergens anders, inputvalidatie verspreid over drie microservices. Waar componenten elkaar raken, daar vind je de zwakke plekken. Wat is de schade als één component wordt gehackt? Kijk naar gedeelde database-credentials, service accounts met onbeperkte toegang, secrets in environment variables die elke service kan lezen. Dit was logisch toen het systeem nog klein was met 3 ontwikkelaars met één server. Nu betekent het dat één hack overal doorwerkt. De Target-hack van 2013 begon met de credentials van een airco-leverancier en eindigde met 40 miljoen gestolen creditcards. Eenmaal binnen konden aanvallers overal bij. Wat als authenticatie niet meer werkt? Als de authenticatieservice down gaat, falen requests dan of gaan ze door? Onder druk falen veel systemen open: de "tijdelijke bypass" die nooit is verwijderd, de fallback die validatie overslaat of minder goed beveiligd is. Dit zit in bijna elke codebase. Vind het voordat een aanvaller het vindt. Welke beveiligingskeuzes passen niet meer bij hoe het systeem nu wordt gebruikt? Het single-tenant systeem dat multi-tenant werd, de interne tool die naar klanten ging. Beveiligingsfouten kunnen meerdere productreleases overleven, vooral als ze uit dependencies komen. Vraag wanneer de laatste security review was. Vraag dan wat er sindsdien is veranderd. Beveiligingslekken kunnen kostbaar worden. Probeer een goed beeld te vinden van waar de risico's zich bevinden. Operationele Paraatheid Je ontdekt hoe software faalt door ernaar te kijken, niet door te wachten tot het daadwerkelijk gebeurt. Operationele paraatheid betekent dat je bugs kunt oplossen voordat je klanten erover beginnen te posten op social media. Wat gebeurt er als het systeem 's nachts down gaat? Als er iets faalt, wordt dan de juiste persoon genotificeert, en heeft deze genoeg informatie om het probleem te kunnen oplossen? Veel van dit soort systemen sturen alerts naar Slack-kanalen die niemand bekijkt, en zeker niet na kantooruren. Dat is schijnveiligheid, geen werkende monitoring. Check wie er echt on-call is, welke informatie ze krijgen, en of ze er iets mee kunnen. Op welke manier heeft dit systeem nog nooit gefaald? Als het systeem nooit een database-failover heeft meegemaakt, of een externe service die wegviel, nooit echte productiebelasting heeft doorstaan, dan weet je niet hoe het zich gedraagt in die scenario's. Geen incidenten kan betekenen dat het systeem robuust is, maar het kan ook betekenen dat dit nog kan komen. Welke alerts worden door iedereen genegeerd? Te veel valse meldingen creëren een gevaarlijk patroon: teams leren alerts negeren, waardoor echte problemen onzichtbaar worden. Analyseer: hoeveel alerts kwamen binnen en hoeveel waren terecht? Minder dan de helft bruikbaar? Dan verstoort je monitoring meer dan het beschermt. Hoe lang duurt herstel echt, en heb je het ooit getest? De meeste van dit soort systemen hebben backups die nooit zijn teruggezet, failover-procedures die nooit zijn uitgevoerd, en runbooks van mensen die jaren geleden vertrokken. Je 'theoretische' hersteltijd betekent niets tot je het onder druk hebt doorlopen. GitLab leerde dit op de harde manier in 2017 toen ze tijdens een incident ontdekten dat hun backups niet werkten. Ter referentie: DORA-onderzoek laat zien dat topteams binnen een uur herstellen. Zwakke teams doen er een week tot een maand over. Wie weet echt hoe het systeem werkt? Als het antwoord 'één persoon' is, heb je een single point of failure. Onderzoekers noemen dit de "busfactor," het aantal mensen dat kan vertrekken voordat een project vastloopt. Een studie bij JetBrains toonde aan dat bestanden die niet meer door hun oorspronkelijke ontwikkelaars worden aangeraakt, verlaten blijven. Permanente blinde vlekken in de codebase. Als 'het vertrokken team' je antwoord is, vertrouw je op kennis die al begint te verdwijnen. Aanpasbaarheid Als ontwikkelaars niet durven te refactoren, worden kleine aanpassingen opgespaard tot gevaarlijke mega-releases. Bugfixes blijven liggen uit angst voor onverwachte bijwerkingen. De technische schuld groeit omdat iedereen de risicovolle modules mijdt. Enquêteonderzoek in de software-industrie toont aan dat teams 23% van hun ontwikkeltijd verspillen aan technical debt. Tijdsdruk is de belangrijkste oorzaak. Angst is een valide maatstaf voor architectuurkwaliteit. Waar weigeren developers aan te werken in het systeem? Elk systeem heeft dit soort black boxez: de facturatiecode die niemand helemaal snapt, de koppeling met dat legacy-systeem bij elkaar gehouden door WD-40 en duct tape. Dit worden permanente blinde vlekken en zijn risicovol. Wat is het ergste dat kan gebeuren door een typfout? Kan één verkeerd teken productie platleggen? Een gezond systeem kan omgaan met kleine fouten, terwijl een gevoelig systeem kleine fouten keihard afstraft. Vinden je tests echt bugs? Een groene testsuite die niet alles test zorgt voor vals vertrouwen. Teams deployen omdat de tests slaagden, terwijl de tests niet testten wat belangrijk was. Kijk naar de laatste bugs die productie bereikten. Hadden de tests die bugs moeten voorkomen? Hoe lang duurt het voor een nieuwe engineer code kan deployen? Dit is een productiviteitsmetric die wrijving meet. Als het maanden kost om het systeem goed genoeg te begrijpen om veilig code bij te dragen, zal ontwikkeling aan het systeem altijd traag zijn. De codebase werkt tegen. Bij Etsy deployen nieuwe engineers op hun eerste dag. Kun je een foute deploy binnen minuten terugdraaien? De snelheid waarmee je kunt herstellen bepaalt je bereidheid om te deployen. Als rollback een nachtmerrie is, durf je niet meer te deployen. Teams nemen geen risico's meer en productiviteit en innovatie stopt. Wat Nu Met Deze Antwoorden Begin met de vragen die je niet kon beantwoorden. Dat zijn je blinde vlekken, en blinde vlekken blijven niet voor altijd verborgen. De antwoorden die je zorgen baren: schrijf ze nu op. Volgende week is de urgentie weg, en het systeem blijft draaien terwijl je jezelf vertelt dat het waarschijnlijk wel goed zit. Leg de zorgen vast en pak dit aan. Deze vragen geven je geen compleet beeld, het is een beginpunt. Ze vertellen je waar de gaten kunnen zitten, en daar begin je met oplossen.Lumia Labs werkt samen met organisaties met legacy systemen. Heb je behoefte aan een frisse blik op je systeem? Laten we praten.

Engineering
Innovatie is geen afdeling
Door Lumia Labs/ Op 05 Feb, 2026

Innovatie is geen afdeling

Bedrijven die voorop willen blijven richten vaak innovatiehubs of -labs op: aparte teams, los van de dagelijkse gang van zaken, met de opdracht om de volgende doorbraak te bouwen. Geef slimme mensen de ruimte om te experimenteren, is de gedachte, en de rest komt vanzelf. Soms werkt het. Een lab waar we mee werkten bouwde een prototype dat de manier van werken binnen het bedrijf had kunnen veranderen. Ze hadden het getest met gebruikers en het was klaar om ingevoerd te worden. Maar de productteams zaten al vol. Het prototype was met andere technologie gebouwd, dus geen enkel team kon het overnemen. Een jaar later was het innovatielab een gewoon team geworden, bezig met onderhoud in plaats van vernieuwing. Het instinct om innovatie apart te zetten is begrijpelijk. Clayton Christensen's Innovator's Dilemma liet zien waarom succesvolle bedrijven moeite hebben met grote marktverschuivingen: ze zijn te goed in het bedienen van bestaande klanten. Als er een nieuwe technologie opkomt, lijkt het onverstandig om daarin te investeren. De logische keuze om je op winstgevende klanten te blijven richten, blijkt achteraf de verkeerde. Christensen stelde een oplossing voor: zet aparte teams op om nieuwe technologieën te onderzoeken. Veel bedrijven volgden dit advies, maar de meeste faalden alsnog. Losse innovatieteams kunnen werken voor onderzoek en proof of concepts. Dat model werkt niet zodra de rest van het bedrijf ermee aan de slag moet. Of je houdt het team echt los als apart bedrijf, of je zorgt dat bestaande teams zelf leren vernieuwen. Onderzoek van Harvard Business Review toonde aan dat de meeste innovatiehubs hun belofte niet waarmaken. Soms reageren labs door zelf producten uit te rollen, maar dat zorgt voor nieuwe problemen. Innovatie en onderhoud vragen andere vaardigheden en een andere manier van denken. Zodra een lab productiesystemen onderhoudt, wordt het een beheerteam in plaats van een vernieuwingsteam. Waarom afscheiding faalt Culturele isolatie. Innovatielabs hebben andere waarden, durven meer risico te nemen, en werken anders. Wanneer projecten terug moeten naar de hoofdorganisatie, stuiten ze op weerstand. De ontwikkelaars die er niet bij horen, ergeren zich aan de voorkeursbehandeling, en managers zien hun budget in gevaar komen. "Not invented here" wordt "not wanted here." Verkeerde metrics. De rest van het bedrijf kijkt naar kwartaalomzet en marge, terwijl het lab kijkt naar hoe snel ze experimenteren en wat ze ervan leren. Geen van beiden snapt wat de ander onder succes verstaat. Bij bezuinigingen worden labs stopgezet omdat ze geen meetbare resultaten kunnen aantonen. Onderzoek naar wendbare organisaties van O'Reilly en Tushman vond dat bedrijven nauwe samenwerking op directieniveau nodig hebben tussen experimentele en bestaande teams, maar de meeste krijgen dit niet voor elkaar. Kennis blijft hangen. Google's Project Aristotle ontdekte dat psychologische veiligheid, het gevoel dat je risico's kunt nemen zonder afgerekend te worden, voor bijna de helft bepaalt hoe goed teams presteren. Losse labs hebben dit misschien intern, maar de rest van de organisatie meestal niet. Het nieuwe denken blijft in het lab hangen, en de rest van het bedrijf leert nooit anders te denken. Verdwijnende aandacht. Zodra het slechter gaat met het bedrijf, kijkt de directie niet meer naar het lab. Budgetten worden bevroren, deadlines schuiven op, en de beste mensen worden teruggehaald naar "echte" projecten. Labs hebben blijvende steun van de top nodig om te overleven, en die verdampt zodra de kwartaalcijfers tegenvallen. Overleven Kodak vond digitale fotografie uit in de jaren '70. Nokia zag de smartphone al jaren aankomen, nog voor de iPhone bestond. Beide bedrijven hadden innovatie ergens in de organisatie. De ideeën waren er, maar ze kregen het niet voor elkaar. Onderzoek dat de ondergang van Nokia en Kodak vergeleek vond dat beide een starre bedrijfscultuur hadden, verkeerde keuzes maakten, en weigerden om hun eigen winstgevende producten te vervangen. Ze zagen het aankomen maar ondernamen niets. Analyse van HealthManagement.org vond dat bij Nokia angst de oorzaak was: topmanagers waren bang voor externe concurrenten, middenmanagers voor interne politiek. Niemand durfde de knoop door te hakken. Kodak voerde in 1981 een studie uit die liet zien dat ze ongeveer tien jaar hadden om zich voor te bereiden op digitale fotografie. Ze stopten het in een la om de filmtak te beschermen. De kennis was er, maar de wil ontbrak. Innovatie inbouwen in de organisatie BCG-onderzoek vond dat bedrijven waar innovatie overal in de organisatie leeft 60% meer kans hebben om voorop te lopen. O'Reilly en Tushman onderzochten bedrijven waar dezelfde directie verantwoordelijk is voor zowel innovatie als dagelijkse operatie. Doorbraken lukken daar in 90% van de gevallen. Bij aparte innovatieteams is dat minder dan 25%. Creëer ruimte voor experiment Traditionele maatstaven verstikken experimenteel werk. 3M laat werknemers 15% van hun tijd aan eigen projecten besteden, hier kwam Post-it Notes uit voort. Google had vroeger de 20% innovatietijd, wat Gmail en AdSense opleverde. Meet experimenteel werk anders, maar doe dat in de hele organisatie. Maak falen risicovrij Als falen risicovol is, probeert niemand meer iets nieuws. Organisaties die willen innoveren moeten laten zien dat ze van fouten leren, en mensen belonen die risico durven te nemen. Dat vraagt een cultuuromslag. Roteer mensen en ideeën Als innovatie in een lab zit, blijft de kennis daar hangen. Laat ontwikkelaars en productmensen wisselen tussen regulier werk en experimentele projecten. Zo leert iedereen hoe je iets uitprobeert, test of het werkt, en op tijd stopt als het niets wordt. Zet in op veel kleine vernieuwingen Bedrijven geven innovatie vaak maar één kans, terwijl investeerders juist verwachten dat het meeste mislukt. Diezelfde aanpak werkt ook intern: voer veel kleine experimenten uit, stop wat niet werkt, en ga door met wat wel aanslaat. Onderzoek van McKinsey vond dat de beste vernieuwers acht keer zo vaak écht wendbaar zijn geworden als organisatie. Niet Agile op papier, maar in de praktijk. Cultuur eet labs als ontbijt Kodak en Nokia hadden beide de technologie. Ze zagen het aankomen en hadden al jaren eerder werkende prototypes dan de concurrentie. Wat ontbrak was een organisatie die achter haar eigen uitvindingen durfde te staan. Zit vernieuwing in je cultuur, dan bloeit het. Zit het in een lab, dan verzandt het.Lumia Labs helpt bedrijven die technisch én organisatorisch willen vernieuwen. Benieuwd hoe je teams innovatiever maakt? We horen graag van je.

Engineering
Wie reviewt jouw AI-gegenereerde code?
Door Lumia Labs/ Op 24 Jan, 2026

Wie reviewt jouw AI-gegenereerde code?

96% van de developers denkt dat AI-gegenereerde code niet correct is. Toch controleert maar 48% de AI-code altijd voordat ze committen. De kloof tussen wat developers denken en wat ze doen laat zien hoe het ervoor staat met AI coding in 2026. Teams bouwen op code waar ze zelf aan twijfelen, terwijl ongeveer de helft het ongecheckt live zet. Deze bevindingen komen uit Sonar's 2026 State of Code Developer Survey, een onderzoek onder 1.100 developers. Samen met onderzoek van METR, CodeRabbit en Veracode, en onze ervaring met development teams die AI gebruiken, zien we patronen. AI coding is nu de standaard 72% van de developers die AI tools hebben geprobeerd, gebruikt ze dagelijks of meerdere keren per dag. GitHub Copilot wordt het meest gebruikt met 75%, gevolgd door ChatGPT met 74%, Claude met 48% en Gemini met 37%. Cursor, dat twee jaar geleden nauwelijks bestond, staat nu op 31%. De code zelf vertelt het verhaal: 42% van productiecode is gemaakt met behulp van AI. Dat is gestegen van 6% in 2023 en naar verwachting stijgt het naar 65% in 2027. Developers gebruiken goedgekeurde AI tools, maar 35% gebruikt (ook) persoonlijke accounts. Dat betekent dat een derde van je team mogelijk bedrijfsgevoelige code deelt met AI-systemen waar je geen controle over hebt. De controlekloof Terug naar dat 96% van developers die denkt dat AI code incorrect is. Developers weten waar AI de fout ingaat: verzonnen functies, subtiele logicafouten, of security code met gaten. Bijna iedereen snapt het probleem. Toch loopt de controle sterk uiteen. Code wordt regelmatig niet goed gereviewd voordat het naar productie gaat. Sonar's data laat zien dat 95% van de developers AI-gegenereerde code in zekere mate controleert, al loopt het niveau van reviewen sterk uiteen. 59% noemt die moeite "matig" tot "substantieel." En de resterende 5% zet AI-code live met minimale of geen review. Als LLMs sneller meer code kunnen genereren, verandert de focus van teams. Ze moeten zich meer richten op het lezen en reviewen van code in plaats van het schrijven ervan. 38% van de developers zegt dat AI-code reviewen meer moeite kost dan menselijke code reviewen. Slechts 27% zegt dat het minder tijd kost. Voor veel teams wordt de bespaarde tijd op het schrijven van code opgeslokt door reviews. Of de andere kant op: reviewen wordt helemaal overgeslagen. Wat we in de praktijk zien is dat veel junior engineers hun eigen pull requests niet eens meer lezen. Zorgen over kwaliteit Extern onderzoek bevestigt dat AI-code kwaliteitsproblemen heeft. CodeRabbit's 2025-analyse vond dat AI-gegenereerde code 1,7x meer issues heeft dan door mensen geschreven code. Veracode's 2025 GenAI Code Security Report vond dat 45% van AI-gegenereerde code kwetsbaarheden bevat. Developers hebben zorgen over de volgende AI kwaliteitsissues:AI-code die er correct uitziet maar niet betrouwbaar is: 61% Blootstelling van gevoelige data: 57% Introductie van ernstige beveiligingslekken: 44%AI schrijft code die soms subtiel fout is op manieren die moeilijk te vinden zijn in reviews. Vooral als teams snelle reviews doen als ze druk ervaren om snel op te leveren. Waar AI effectief is Gevraagd waar AI tools het meest effectief zijn, noemen developers:Documentatie maken: 74% Bestaande code uitleggen en begrijpen: 66% Tests genereren: 59% Assisteren bij ontwikkeling van nieuwe code: 55%AI werkt het best bij taken die goed afgebakend zijn, duidelijke succescriteria hebben en geen diepe businesscontext vereisen. LLM-gegenereerde documentatie beschrijft vaak niet het 'waarom' achter de code. Waar AI moeite mee heeft zijn architectuurbeslissingen, businesslogica, security en langetermijn onderhoudbaarheid. Om dit goed te kunnen heeft AI meer informatie en begrip nodig van het gehele systeem, de organisatie en bedrijfsprocessen. Met meer context 'geheugen' en geavanceerdere modellen kunnen deze problemen in de toekomst verbeteren. Slimme teams zetten AI strategisch in. Ze weten waar AI ze helpt, maar verwachten niet dat het het echte denkwerk vervangt. Agents 64% van de developers heeft AI agents zoals Claude Code gebruikt. 25% gebruikt ze regelmatig. De belangrijkste toepassingen zijn documentatie maken (68%), automatische testen genereren (61%) en code review automatiseren (57%). Agents zijn de volgende stap: autonome systemen die complete workflows afhandelen met minder menselijk toezicht. De problemen rondom het genereren van code met AI worden versterkt wanneer agents zelfstandig opereren. Vragen die engineering management zouden moeten stellen: Welke vangrails bestaan er voor agent-acties? Hoe controleren we wat agents doen? Wat is onze recovery strategie als agents fouten maken? AI-productiviteit Maakt AI developers productiever, of voelen ze zich alleen productiever? De gemiddelde tijd die developers besteden aan routinetaken is 10 uur per week. Dit is niet gedaald ondanks wijdverbreide adoptie van AI tools. Wat wel veranderd is: wat developers doen in die tijd. Developers besteden het nu aan het reviewen van AI-gegenereerde code in plaats van zelf code schrijven. Als AI codegeneratie sneller maakt maar review net zo lang of langer duurt, waar is dan de winst? Meer code betekent meer PR's, en dan wordt reviewen de bottleneck. Kwaliteitsproblemen komen later in de pipeline aan het licht. "Bespaarde" tijd op het schrijven van code wordt besteed aan debuggen en fixen. METR's 2025 randomized controlled trial vond dat ervaren developers 19% langzamer waren bij het gebruik van AI tools. Productiviteit is moeilijk objectief te meten, maar het is niet altijd waar dat AI developers productiever maakt. Meet je volledige delivery cycle en kies goede metrics. Wat engineering leaders moeten doen Erken de controlekloof. Je developers vertrouwen AI-output niet. Zorg ervoor dat hier rekening mee wordt gehouden voordat het naar productie gaat. Ga er niet vanuit dat AI automatisch productiviteitswinst betekent. Maak controle verplicht. Als maar 48% AI-code altijd nakijkt, moet controle de norm worden. Automatische kwaliteitscontroles voor AI-gegenereerde code. Uitgebreide review voor AI-ondersteunde commits. Verbeter pre-commit checks: hoe meer je automatisch kunt vangen, hoe beter. Pak ongeautoriseerd AI-gebruik aan. Dat 35% persoonlijke accounts gebruikt is een beheerprobleem. Bied goedgekeurde tools met controles en creëer duidelijk beleid. Als je goedgekeurde tools hebt, beperk ze dan niet om kosten te besparen, want dan gaan mensen hun persoonlijke accounts gebruiken. Meet wat ertoe doet. Volg de volledige delivery cycle. Meet de codekwaliteit over tijd. Let op als er meer problemen na deployment komen. Stel verwachtingen bij. AI blinkt uit in documentatie, testgeneratie en code-uitleg. Het worstelt met betrouwbaarheid, security en architectuur. Bereid je voor op agents. Als je team agents gebruikt, moet het toezicht nu op orde zijn. Maak inzichtelijk wat er gebeurt en zorg dat er mogelijkheden zijn om terug te draaien. Succes met AI vraagt om een nuchtere aanpak: realistische verwachtingen, grondige controle, duidelijk toezicht.Lumia Labs helpt organisaties software bouwen die werkt. Zoek je een technisch perspectief op AI tools Laten we praten.

Engineering
Je hebt geen microservices nodig
Door Lumia Labs/ Op 09 Feb, 2026

Je hebt geen microservices nodig

Segment bouwde meer dan 140 microservices voor hun event routing. Drie ontwikkelaars besteedden uiteindelijk het grootste deel van hun tijd aan onderhoud in plaats van features bouwen. Ze stapten terug naar een monoliet. In plaats van sneller te werken, schreef Alexandra Noonan, verdronk het kleine team in complexiteit. We zien dit patroon ook bij klanten. Amazon's Prime Video-team stapte over van serverless microservices naar een monoliet en verlaagde de infrastructuurkosten met 90%. Zelfs het bedrijf dat service-oriented architecture uitvond, kwam erachter dat het niet altijd het juiste antwoord is. Amazon's architectuur is niet de jouwe De microservices-beweging begon omdat monolithische applicaties onhandelbaar werden naarmate teams groeiden. Conway's Law speelde zich af: grote codebases dwongen ontwikkelaars tot eindeloos afstemmen. Jeff Bezos stuurde rond 2002 zijn beroemde API-mandaat waarin hij alle Amazon-teams verplichtte om via service-interfaces te communiceren. Die architectuurkeuze maakte AWS mogelijk. Het patroon werkte voor Amazon, dus iedereen kopieerde dat. In 2020 vond O'Reilly dat 77% van de organisaties microservices had overgenomen. Maar de meeste van die organisaties zijn Amazon niet. Ze hebben geen duizenden ontwikkelaars, geen decennia aan infrastructuurtooling, en niet het budget om honderden onafhankelijke services te beheren. Martin Fowler zag het al in 2015, hij schreef: bijna alle succesvolle microservices-verhalen begonnen met een monoliet die te groot werd en werd opgesplitst. Bijna alle gevallen waarbij een systeem vanaf het begin als microservices werd gebouwd, liepen vast. De meeste microservices zijn verkapte monolieten De meeste microservice-architecturen waar we mee werken doen niet wat ze beloven. Fouten die we zien:Meerdere services delen een database, waardoor migraties van het schema lastig worden Lastig om één wijziging in één service te deployen, door lekkende abstracties en verborgen afhankelijkheden Moeilijk om leveringen over teams te coördineren, omdat services niet onafhankelijk zijn Slecht API-ontwerp, waardoor services hun interne werking blootleggen (dit is ook slecht in monolieten, maar daar zit het nog in één delivery) Een storing in één service rolt door het hele systeemTaibi, Lenarduzzi en Pahl catalogiseerden 20 van dit soort antipatronen via gesprekken met ontwikkelaars. De meeste herkennen we. Het heeft een naam: de distributed monolith. Je betaalt de volledige operationele kosten van microservices, maar krijgt niets van de onafhankelijkheid. Elke service-hop voegt latency toe, en debuggen over servicegrenzen duurt zo'n 35% langer dan in één proces. Kelsey Hightower, destijds Distinguished Engineer bij Google Cloud, was er duidelijk over: monolieten zijn de toekomst, want microservices lossen een probleem op dat er niet is. Je gaat van slechte code naar slechte infrastructuur waar je diezelfde slechte code bovenop draait. Wat ons betreft wordt de complexiteit voor teams te vaak over het hoofd gezien. Team Topologies-onderzoek van Matthew Skelton en Manuel Pais bevestigt dit: niet de architectuurkeuze doet ertoe, maar of je team die architectuur aankan. Microservices verveelvoudigen wat een team moet begrijpen: networking, service discovery, distributed tracing, container orchestration. Method calls, niet netwerkcalls Er is een andere optie: de modulaire monoliet. Eén deployment met strikte interne grenzen tussen domeinmodules, waar communicatie via method calls gaat in plaats van netwerkcalls. Eén testpipeline, één deployment, maar mét de structuur die spaghetti voorkomt. Shopify draait een van de grootste Ruby on Rails-applicaties ter wereld: 2,8 miljoen regels code, meer dan 500.000 commits, honderden actieve ontwikkelaars. Ze evalueerden microservices en wezen ze bewust af. Kirsten Westeinde van Shopify's engineeringteam schreef dat ze een oplossing wilden die modulariteit bood zonder het aantal deployments te vergroten. Dat leverde 37 componenten op met duidelijke grenzen, afgedwongen door tools als Packwerk voor statische analyse. Ontwikkelaars werken binnen heldere grenzen zonder de overhead van gedistribueerde systemen. DHH van Basecamp beschreef hun aanpak in 2016: 12 programmeurs die miljoenen gebruikers bedienen op zes platformen, met een monoliet van 200 controllers en 190 modelklassen. In 2023 schreef hij "How to Recover from Microservices", met Gall's Law als uitgangspunt: een complex systeem dat werkt, is altijd ontstaan uit een simpel systeem dat werkte. Zelfs Google erkende het patroon. Hun Service Weaver-framework laat je een applicatie schrijven als modulaire monoliet en pas als microservices deployen wanneer dat nodig is. De architectuur begint simpel en wordt alleen complexer waar het systeem erom vraagt. De meeste teams zijn te klein voor microservices Microservices lossen problemen op die eenvoudigere architecturen niet aankunnen. Honderden ontwikkelaars die onafhankelijk moeten deployen. Componenten met fundamenteel andere schaaleisen. Op die schaal verdienen microservices hun complexiteit terug. Stefan Tilkov stelt dat een monoliet leidt tot koppeling die je er later moeilijk uit krijgt. Daar heeft hij gelijk in, als je geen modulegrenzen afdwingt. Maar hij nuanceert het zelf: de aanpak vereist diepe domeinkennis en past alleen bij grotere systemen. Het onderzoek achter Accelerate (Forsgren, Humble, Kim) laat zien dat topteams architectuur hebben waarmee teams onafhankelijk kunnen deployen. Dat kan met microservices, maar net zo goed met een modulaire monoliet. Teamautonomie bepaalt het resultaat, niet het architectuurpatroon. Als je engineeringteam kleiner is dan 50 ontwikkelaars, heb je vrijwel zeker geen microservices nodig. Begin met modules en stap over op microservices als dat nut heeft. Eerst modules, dan pas services Als we teams helpen met hun software-architectuur, gebruiken we deze principes: Trek eerst domeingrenzen. Snap je bedrijfsdomeinen voor je een architectuur kiest. Goede domeinkennis is de basis voor een goede architectuur. Dwing grenzen af in code. Modulegrenzen zonder handhaving vervagen binnen een paar maanden. Gebruik tooling als SonarQube om schendingen zichtbaar te maken. Meet de belasting op je team. Besteedt je team meer tijd aan infrastructuur dan aan features? Dan is je architectuur te complex. Plan vooruit. Een goed gemodulariseerde monoliet kan doorgroeien naar microservices wanneer nodig. Ontwerp modules alsof ze services kunnen worden.Lumia Labs helpt organisaties met architectuurkeuzes. Heroverweeg je je architectuur? We horen graag van je.