Type something to search...

AI coding

Engineering
Van DevSecOps naar Agentic DevSecOps
Door Lumia Labs/ Op 01 Mar, 2026

Van DevSecOps naar Agentic DevSecOps

DevSecOps begon met een simpel idee: security hoort in het ontwikkelproces, vanaf dag één. Maar "iedereen" in je team omvat nu ook AI-agents. Ze schrijven code en mergen pull requests. Je securitymodel gaat nog uit van mensen. Security opnieuw inrichten voor agents: dat is wat wij Agentic DevSecOps noemen. Het verandert hoe je nadenkt over identiteit, toegangscontrole, verificatie en verantwoordelijkheid. DevSecOps was gebouwd voor mensen DevSecOps draait erom dat het hele team verantwoordelijk was voor security. Shift left, bouw security in het ontwikkelproces en voorkom dat vulnerabilities productie bereiken. Dat ging uit van een menselijke developer die de code schrijft, de intentie begrijpt, scanresultaten beoordeelt en afwegingen maakt over risico. Developers gebruiken tooling zoals statische analyse om problemen te signaleren, maar uiteindelijk beoordeelt een mens of een melding een false positive is of een echte dreiging. Een reviewer leest de diff en bedenkt wat de gevolgen zijn. Uit Sonar's 2025-onderzoek blijkt dat 42% van de productiecode al AI bevat, en dat percentage stijgt. Zodra agents PRs openen en hun eigen code mergen, houdt geen van die aannames stand. Wat Agentic DevSecOps anders maakt Bij Agentic DevSecOps ontwerp je security voor een wereld waarin AI-agents je code schrijven en uitrollen. Wie is de agent, en wat mag die? In traditionele DevSecOps koppel je toegangscontroles aan menselijke identiteiten. Als een AI-agent een PR opent: wiens rechten gebruikt die? Wat zou die mogen doen? In onze ervaring draaien de meeste organisaties agents onder de persoonlijke credentials van een developer. De agent krijgt rechten die bedoeld waren voor een mens. AI-agents kiezen ook hun eigen dependencies. Onderzoek van Veracode toonde aan dat 45% van AI-gegenereerde code kwetsbaarheden bevat. Een agent kan een dependency toevoegen die technisch niets mankeert maar niet in je architectuur past. Of code schrijven die een kwetsbaar patroon nabootst zonder dat je scanners het oppikken. Snelheid versus verificatie AI-agents schrijven en deployen code tien tot honderd keer sneller dan mensen. Een security scan van 15 minuten werkt prima als developers een paar keer per dag pushen. Bij tientallen agent-wijzigingen per uur wordt die scan een bottleneck, of hij wordt "tijdelijk" overgeslagen en komt nooit meer terug. Agents laten genoeg sporen achter in commits en PR-beschrijvingen. Maar tegen de tijd dat een fout in productie opduikt, zitten er al tientallen commits bovenop. De code stapelt zich sneller op dan iemand kan reviewen. Andere fouten, andere risico's AI-agents maken andere fouten dan mensen. Menselijke fouten zijn voorspelbaar: input niet valideren, onveilige patronen kopiëren, credentials hardcoden, slordig worden onder tijdsdruk. Dat zie je in een review. AI-gegenereerde code is lastiger. Het lijkt correct, het doorstaat eenvoudige checks, maar er zit een fout in die je niet meteen ziet. De code ziet er goed uit, maar het doet alleen niet wat je denkt. Nieuwe aanvallen duiken al op in agentic workflows: Prompt injection via codecontext Een aanvaller verbergt kwaadaardige instructies in een codebase-comment of issue-omschrijving. De AI-agent leest die context, volgt de instructies en introduceert een backdoor die eruitziet als een legitieme codewijziging. Onderzoekers hebben aangetoond dat LLM's via hun inputcontext te manipuleren zijn. Een AI-agent die je vraagt een feature te bouwen kan een dependency binnenhalen die nog niet bestaat. Registreert een aanvaller die pakketnaam eerst, dan installeert de agent het foute pakket. Agents die zelf lockfiles aanpassen als onderdeel van hun workflow omzeilen die bescherming. Niemand kijkt mee Een AI-agent schrijft de code, een andere reviewt het, een geautomatiseerde pipeline deployt het. Niemand heeft dat zo bedacht, maar de stappen bij elkaar zijn een volledig geautomatiseerde route naar productie. AI-agents hebben API-keys en credentials nodig. Een agent die zijn context logt of secrets in een commit message zet, lekt credentials op plekken waar je secret scanning niet kijkt. Wat je pipeline nodig heeft Geef agents hun eigen identiteit Geef AI-agents eigen service-accounts met beperkte rechten. Schrijft een agent code? Dan mag die niet mergen. Draait een agent tests? Dan mag die de testconfig niet aanpassen. In de praktijk draaien de meeste agents nog op het token van een senior developer met volledige repo-toegang. Behandel ze als serviceaccounts: zo min mogelijk rechten, gecontroleerde toegang. Meer dan één scan Eén scan is niet genoeg, combineer statische analyse, semantische analyse, gedragstests en afwijkingsdetectie. AI-gegenereerde code heeft herkenbare patronen. Daar kun je op scannen. Rem agents bewust af Beperk hoe snel agents wijzigingen kunnen pushen, en bouw circuit breakers die activiteit pauzeren bij afwijkingen: ongebruikelijke dependency-toevoegingen of wijzigingen aan security-gevoelige bestanden. Weet waar elke wijziging vandaan komt De transparantieverplichtingen in de EU AI Act gelden al voor AI-gegenereerde code in gereguleerde sectoren, en handhaving komt eraan. Elke wijziging moet terug te voeren zijn op wie (of wat) het schreef, wat de aanleiding was, welke context de agent had en welke review het doorliep. Begin daar nu mee. Menselijke review Niet elke wijziging heeft een menselijke reviewer nodig. Maar wijzigingen aan authenticatie, autorisatie, betalingsverwerking, dataverwerking en infrastructuur wel. Bepaal je risicogebieden en wijk daar niet van af, ook als het de ontwikkeling iets vertraagt. Dit is geen toolingvraag Agentic DevSecOps gaat minstens zoveel over organisatie als over techniek. Securityteams moeten snappen hoe agents werken. Ontwikkelteams doen er goed aan agents te behandelen als een nieuwe collega: stel kaders, controleer het werk. En je platform moet er rekening mee houden dat niet alleen mensen code schrijven. Wie dit goed regelt kan agents met vertrouwen inzetten.Lumia Labs helpt teams die met AI-agents werken om security goed te regelen. Zet je agents in binnen je pipeline en wil je dat veilig doen? Neem contact op.

Engineering
Maakt AI je team slechter?
Door Lumia Labs/ Op 30 Jan, 2026

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 gebeurdenMet 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 schrijvenDevelopers 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.

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
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.