Logo of Osakidetza, the Basque Health Service, featuring a modern design with clouds and abstract elements.

256_cta-background.webp

384_cta-background.webp

640_cta-background.webp

750_cta-background.webp

828_cta-background.webp

share_osakidetza-logo.jpg

thumbnail_cta-background.webp

osakidetza-logo

Daar hebben wij de oplossing voor

Wilt u efficiënter werken? 

Abstract digital background featuring interconnected lines and glowing points in shades of blue and green.

1080_background.webp

1200_background.webp

256_background.webp

384_background.webp

640_background.webp

750_background.webp

828_background.webp

share_atmosphere-water-sky-azure-electricity-astronomical-object-slope-electric-blue.jpg

thumbnail_background.webp

atmosphere-water-sky-azure-electricity-astronomical-object-slope-electric-blue

Logo of Zen Software in white on a transparent background.

1080_zen-logo-white.webp

1200_zen-logo-white.webp

256_zen-logo-white.webp

384_zen-logo-white.webp

640_zen-logo-white.webp

750_zen-logo-white.webp

828_zen-logo-white.webp

share_zen-logo-white.jpg

thumbnail_zen-logo-white.webp

zen-logo-white.webp

ZEN Software

1080_zen-logo-black.webp

1200_zen-logo-black.webp

256_zen-logo-black.webp

384_zen-logo-black.webp

640_zen-logo-black.webp

750_zen-logo-black.webp

828_zen-logo-black.webp

share_západoslovenská energetika-logo.jpg

thumbnail_zen-logo-black.webp

západoslovenská energetika-logo

Alle diensten op een rij

Verouderde systemen moderniseren

Maatwerksoftware bouwen en beheren

Cloud & platform

Wat kost het?

Wat we doen

Cases

Over ons

Artikelen

Contact

Gelukt! Je staat op de lijst van Standup & Deliver.

Alles wat relevant is voor het meten van softwareontwikkeling en productieplatformen, in je mailbox.

Standup & Deliver, de nieuwsbrief van ZEN Software

In 1988 legde een student een tiende van het internet plat. Wat deden we daarna?

Een groene rups kruipt over een uitgerolde band met ponstape en laat een spoor van steeds kleinere kopieën van zichzelf achter; links knielt een engineer die een pion en een koordje over het pad zet

morris-worm-1988.webp

In november 1988 schreef een student aan Cornell een programmaatje dat moest tellen hoeveel computers er aan het internet hingen. Door een fout legde het een tiende van dat internet plat. Wat er daarna gebeurde is interessanter dan de storing zelf, en het is het draaiboek dat we nu weer nodig hebben.

OpenAI's AI-agents braken in bij een ander bedrijf. Waarom noemen we dat opeens een complot?

Illustratie: een klein robotje typt rustig aan een bureau terwijl de bureaulamp een reusachtige monsterschaduw op de muur werpt, naast een serverkast die wagenwijd openstaat met de sleutel nog in het slot

hugging-face-hack-beveiligingsincident.webp

OpenAI's AI-agents braken deze zomer in bij Hugging Face, een ander AI-bedrijf. Volgens Dwarkesh Patel was het een AI-beschaving, volgens Alexander Klöpping de gevaarlijkste hack uit onze geschiedenis. Ik laat zelf elke dag AI-agents draaien, dus ik heb de rapporten gelezen, en ik kwam er een stuk rustiger uit dan ik erin ging. Wat me wel bezighoudt: waarom noemen we dit opeens een complot?

AI maakt code goedkoop. Je organisatie is nog steeds duur.

Illustratie: een koerier op een step levert een pakketje af bij een rij van vijf bureaus met stempels en kalenders, met een dichte deur aan het eind

organisatie-is-duur.webp

Developers in een gecontroleerd onderzoek waren 19% trager met AI en dachten dat ze 20% sneller waren. DORA vond ondertussen dat organisaties wél sneller werden, en daarvoor betaalden met stabiliteit. Wat er veranderde toen code goedkoop werd, is niet wat de meeste engineeringleiders denken.

Een AI-abonnement van 200 dollar levert 14.000 dollar aan rekenkracht op. Maar klopt die som?

Balance scale with one small coin on one pan and a large melting block of ice on the other, hanging level, while a small robot mops the puddle

17-ai-abonnement-subsidie.webp

Een ChatGPT Pro-abonnement van 200 dollar zou 14.000 dollar per maand aan rekenkracht opleveren. Zo gaat de screenshot rond. Ik ben het cijfer naar zijn bron gevolgd, en de som klopt niet helemaal. Maar onder die som zit een betere vraag, en die gaat over hoe lang een AI-model eigenlijk meegaat.

Mijn AI agent werkt 's nachts voor me door. Hij mag alleen niks beslissen.

Leeg bureau in ochtendlicht met een koffiekop en een uitgeprint rapport met vinkjes en één kruisje; een kleine robot kijkt toe met de handen op de rug

16-agent-werkt-s-nachts.webp

Sinds augustus draait bij ons elke werkdag om half acht een agent die de open merge requests leest en er iets van vindt. Hij mag niets mergen, niets sluiten, niets beslissen. Dat is geen beperking die ik er later bij heb bedacht. Het is het ontwerp.

48 grote storingen in twaalf maanden. Wat is er aan de hand bij GitHub?

Illustratie: een brug op twee pijlers, waarvan de rechter gebarsten is en met steigers overeind wordt gehouden, terwijl het verkeer er gewoon overheen blijft rijden.

github-gitlab-bridge.webp

Bijna acht uur plat op één middag, 48 grote storingen in een jaar, en de grootste oorzaak is capaciteit. Over GitHub dat een Microsoft-divisie werd, het omgekeerde Midas-syndroom, Bitbucket als waarschuwing, en waarom wij willen dat het met allebei goed blijft gaan.

Wat je mist bij AI-agents is meestal geen gereedschap

Illustratie: vier oplichtende schermen sturen elk een stroom datablokjes naar één trechter, waar het werk zich opstapelt naast een lege stoel

geen-gereedschap-v2.webp

Ik draai al maanden meerdere AI-agents naast elkaar. Na vijf uur DHH over programmeren met agents bleek mijn gereedschap te kloppen. Wat ontbrak waren drie gewoontes, en die kun je geen van alle installeren.

De bedenker van Ruby on Rails schrijft geen regel code meer zelf

Staafdiagram: dezelfde vertaalklus van Python naar Rust kostte 550 dollar met Fable, 46 dollar met GPT Sol en 23 dollar met DeepSeek V4 Pro

dhh-podcast-nl.webp

De bedenker van Ruby on Rails schrijft geen regel code meer zelf en stuurt zestien agents tegelijk aan. Uit vijf uur gesprek met Lex Fridman de drie dingen waar je maandag iets aan hebt, inclusief het enige getal uit de aflevering waar een inkoper iets aan heeft.

Code wordt goedkoop. Engineering niet.

Twee panelen: implementatie voor 150 euro per uur, doorgestreept met een pijl naar beneden, naast engineering judgement als schaars met een pijl naar boven.

code-is-getting-cheap-nl.webp

Een developer met twintig jaar ervaring stopte met AI-coderen. Niet omdat het niet werkte, maar omdat het te goed werkte. Zijn diagnose is scherper dan die van de meeste partijen die aan AI verdienen. Alleen komen wij tot een andere conclusie: niet stoppen met AI, maar betere engineering eromheen.

AI-vampiers: de verborgen prijs van twintig agents

Vriendelijke cartoonvampier achter een laptop bij zonsopgang, met negen zwevende schermen waarop AI-assistenten tegelijk code schrijven

ai-vampires-v5.webp

Marc Andreessen beschrijft bij Joe Rogan een nieuw type programmeur: iemand die niet meer gaat slapen omdat er twintig agents op antwoord staan te wachten. Hij noemt ze AI-vampiers en schaart ze onder goed nieuws. De waarneming klopt. De rubriek niet.

Software ontwikkelen met behulp van AI en rekening houden met AVG, NIS2 en DORA compliance

Drie gekleurde transparante vlakken boven één doorlopende lichtlijn, die elkaar overlappen en daar van kleur mengen.

zen-hero-compliance-regelgevingslagen.webp

Zodra je een coding agent aan je codebase hangt, raak je drie regimes tegelijk. Niet omdat AI apart gereguleerd is, maar omdat het bestaande regels raakt op plekken waar je ontwikkelstraat er nooit eerder mee te maken had.

AI-gegenereerde infrastructuurcode reviewen: waar je écht naar moet kijken

Rij gesloten deuren met in elk slot nog de sleutel, waarvan er één rood is.

zen-hero-iac-sleutels-in-de-sloten.webp

Applicatiecode die fout is, gaat meestal stuk. Infrastructuurcode die fout is, werkt. En dat is precies het probleem. Een agent die Terraform schrijft, levert iets op dat plant, applyt en draait. Of het ook veilig is, zie je niet aan de output.

Wat dertig minuten wachten per engineer per dag echt kost

Rekensom in vier stappen: dertig minuten wachten per dag wordt 495.000 euro per jaar bij honderd engineers.

zen-hero-wachttijd-rekensom.webp

Een half uur per dag, zo weinig lijkt het. Maar reken het door en het is €5.000 per engineer per jaar, of een half miljoen euro bij honderd engineers: geld dat op geen enkele regel van je P&L staat en dat niemand ooit heeft goedgekeurd.

DORA-metrics lezen als AI de helft van je commits schrijft

Vier DORA-metrics met pijlen die de beweging tonen; change failure rate is rood gemarkeerd als het risico.

zen-hero-dora-beweging.webp

Je DORA-dashboard toont nog steeds dezelfde vier getallen. Alleen betekenen ze niet meer hetzelfde. Zodra een flink deel van je code niet meer met de hand geschreven wordt, verschuift wat elk van die metrics je vertelt, en de naïeve lezing wijst precies de verkeerde kant op.

Bedrijfsprocessen automatiseren: waar begin je?

Keana planningsscherm: transportorders links, ritopbouw rechts met voertuig, tijdvenster en stops per rit

keana-planning-ritopbouw.webp

Bijna elke organisatie heeft een handvol handelingen die niemand zou missen: dezelfde gegevens twee keer invoeren, de wekelijkse export die iemand met de hand bijwerkt, wachten tot een collega iets doorgeeft. Automatiseren is die handelingen weghalen — en dat begint niet bij het kiezen van een tool. Wat het wél oplevert, wat je beter laat staan, en waar het in de praktijk misgaat.

Een cloudmigratie plannen (zonder gek te worden)

Gantt met vier overlappende planfases van een cloudmigratie over vijf weken.

zen-hero-migratie-fases-gantt.webp

Je weet dat je naar de cloud moet. Maar je ziet ertegenop: wat als we data kwijtraken? Hoe lang gaat dit duren? Wat als het duurder uitpakt dan on-premise blijven? Kiezen we wel de juiste provider?

De afgelopen jaren hebben we 8 productiesystemen gemigreerd naar AWS, Azure en Google Cloud. Wat we daarvan geleerd hebben: de meeste cloudmigraties slagen gewoon. De migraties die misgaan, gaan mis door slechte planning — niet door slechte uitvoering.

Je weet dat je [naar de cloud](/onze-diensten/oplossingen/zen-cloud-landing-zone) moet. Maar je ziet ertegenop: wat als we data kwijtraken? Hoe lang gaat dit duren? Wat als het duurder uitpakt dan on-premise blijven? Kiezen we wel de juiste provider?
    
De afgelopen jaren hebben we 8 productiesystemen gemigreerd naar AWS, Azure en Google Cloud. Wat we daarvan geleerd hebben: **de meeste cloudmigraties slagen gewoon**. De migraties die misgaan, gaan meestal mis door slechte planning — niet door slechte uitvoering.

Wat is een klantenportaal?

Dashboard showing the ZEN Software Service Catalog with a list of components and their details.

Frame 31.webp

Een klantenportaal is een afgeschermd deel van je software waar klanten inloggen om hun eigen orders, facturen of dossiers te zien. Klinkt eenvoudig, en de schermen zijn dat vaak ook. Het moeilijke zit eronder: wie mag wat zien, en waar komt die informatie vandaan. Een uitleg zonder verkooppraat, met wat we ervan geleerd hebben van het portaal dat we zelf draaien.

Een PWA bouwen in 2026: wat je als React-developer écht moet leren

Diagram met twee routes vanaf de service worker: groen naar de cache, rood naar het netwerk.

zen-hero-service-worker-routes.webp

Heb je al React-applicaties gebouwd, dan valt een Progressive Web App waarschijnlijk reuze mee.

De term heeft nog altijd iets van 2019 over zich. PWA's werden toen aangeprezen als “websites die zich gedragen als native apps” en zouden en passant de app stores overbodig maken. Die voorspelling is… wisselend oud geworden.

Heb je al React-applicaties gebouwd, dan valt een Progressive Web App waarschijnlijk reuze mee.
     
De term heeft nog altijd iets van 2019 over zich. PWA's werden toen aangeprezen als “websites die zich gedragen als native apps” en zouden en passant de app stores overbodig maken. Die voorspelling is… wisselend oud geworden.
     
Maar ondertussen zijn PWA's stilletjes gewoon nuttig geworden.
     
Voor interne bedrijfstools, klantportalen, webshops, boekingsflows, buitendienst-apps, dashboards en producten waarbij “installeerbaar zijn” zwaarder weegt dan een plek in de App Store, zijn ze vaak precies de praktische tussenweg tussen website en mobiele app.
    
Het goede nieuws: ben je al thuis in React, Next.js, Vite of moderne frontend-tooling, dan ben je er dichterbij dan je denkt.
     
Het slechte nieuws: er zijn een paar concepten die webdevelopers stelselmatig onderschatten.

Cloudkosten optimaliseren: hoe een SaaS-bedrijf 35% bespaarde

reducing-cloud-costs.webp

Een klein SaaS-bedrijf van zo'n 50 medewerkers klopte bij ons aan met een zorg die in de budgetbesprekingen was komen bovendrijven. Hun product was stabiel, het gebruik groeide gestaag, maar de cloudkosten gedroegen zich niet langer voorspelbaar. De infrastructuur kostte ongeveer €10.000 per maand. Niet extreem, maar het kroop omhoog zonder duidelijke verklaring. Voor een bedrijf van die omvang wordt zelfs een paar duizend euro verspilling per maand merkbaar.

5 dingen waar je op moet letten als je een website bouwt die écht scoort

Diagram dat een goed gekoppelde sitestructuur naast losse weespagina's zet.

08-sitestructuur.webp

Veel SEO-advies klinkt nog altijd alsof het uit 2014 komt. Eindeloze keywordlijstjes, “content is king”, en gepieker over dichtheidsscores waar niemand meer naar omkijkt. Ondertussen komen genoeg technisch prima websites niet van hun plek, omdat ze precies datgene negeren waar zoekmachines stilletjes heel goed in zijn geworden: structuur, duidelijkheid, snelheid, en of een site het gevoel geeft dat er mensen achter zitten die weten wat ze doen.

Veel SEO-advies klinkt nog altijd alsof het uit 2014 komt. Eindeloze keywordlijstjes, “content is king”, en gepieker over dichtheidsscores waar niemand meer naar omkijkt. Ondertussen komen genoeg technisch prima websites niet van hun plek, omdat ze precies datgene negeren waar zoekmachines stilletjes heel goed in zijn geworden: structuur, duidelijkheid, snelheid, en of een site het gevoel geeft dat er mensen achter zitten die weten wat ze doen.
       
Goede posities komen meestal voort uit een combinatie van een stevig technisch fundament en content die niet aanvoelt alsof hij puur voor de zoekmachine in elkaar is gezet. Het aantal websites dat nog steeds levenloze, dichtgetimmerde pagina's publiceert, suggereert iets anders.

Waarom IAM misschien wel het gevaarlijkste deel van je cloud is

Gesloten kluisdeur naast een wand die vol kleine, legitiem uitgesneden doorgangen zit.

09-waarom-iam-misschien-wel-het-gevaarlijks.webp

Vraag iemand waar het risico in de cloud zit, en je krijgt meestal dezelfde antwoorden: blootgestelde databases, verkeerd ingestelde storage buckets, misschien een server die open aan het internet hangt. Dat zijn de dingen waar mensen screenshots van maken, postmortems over schrijven en securitypresentaties mee vullen. Het is alleen niet waar de meeste interessante problemen vandaan komen.

Vraag iemand waar het risico in de cloud zit, en je krijgt meestal dezelfde antwoorden: blootgestelde databases, verkeerd ingestelde storage buckets, misschien een server die open aan het internet hangt. Dat zijn de dingen waar mensen screenshots van maken, postmortems over schrijven en securitypresentaties mee vullen. Het is alleen niet waar de meeste interessante problemen vandaan komen.
      
Kijk je lang genoeg naar echte systemen, dan begin je een ander patroon te zien. Er gaat zelden iets mis doordat iemand zich als in een film door lagen infrastructuur heen hackt. Veel vaker was de toegang er gewoon al. Alleen… iets ruimer dan iemand doorhad. Dat is IAM.

Als AI de juniorrollen overneemt, waar komen de seniors dan vandaan?

Monumentale trap waarvan de onderste treden ontbreken, zodat het bovenste deel in de lucht begint.

10-als-ai-de-juniorrollen-overneemt-waar-ko.webp

Er zit een stille tegenstrijdigheid in hoe we over AI in softwareontwikkeling praten.

Aan de ene kant is er enthousiasme over het vervangen van juniorwerk. Boilerplate, simpele features, kleine bugfixes — precies het werk dat vroeger je instap was, wordt nu steeds vaker door AI gedaan. Dat scheelt tijd, drukt de kosten en laat teams sneller werken, zo gaat het argument. Daar valt weinig tegenin te brengen.

Er zit een stille tegenstrijdigheid in hoe we over AI in softwareontwikkeling praten.
      
Aan de ene kant is er enthousiasme over het vervangen van juniorwerk. Boilerplate, simpele features, kleine bugfixes — precies het werk dat vroeger je instap was, wordt nu steeds vaker door AI gedaan. Dat scheelt tijd, drukt de kosten en laat teams sneller werken, zo gaat het argument. Daar valt weinig tegenin te brengen.
       
Maar er blijft een ongemakkelijke vraag in de lucht hangen: **als er minder mensen op juniorniveau beginnen, waar komen de [senior developers](/onze-diensten/producten-en-diensten/projectversterking-detachering-zzp) dan later vandaan?** Want senior engineers verschijnen niet kant-en-klaar. Ze worden gevormd, over jaren, vaak juist door het soort werk dat nu wegautomatiseert.

Cloud observability versus cloud monitoring

Diagram dat vooraf gedefinieerde monitoringchecks naast doorzoekbare observability-dimensies zet.

11-observability.webp

Het verschil tussen monitoring en observability merk je pas echt wanneer er iets misgaat en je gebruikelijke tools je niet helpen begrijpen waarom. Dan pas wordt het gat zichtbaar.

De termen [cloud observability](/onze-diensten/oplossingen/zen-devops-accelerator) en cloud monitoring worden voortdurend door elkaar gebruikt.
      
Dashboards, alerts, logs, traces — het belandt allemaal onder dezelfde paraplu, en een tijdlang voelt dat prima. Je levert functionaliteit op, je houdt je metrieken in de gaten en je grijpt in als er iets breekt.
      
Het verschil tussen monitoring en observability merk je pas echt wanneer er iets misgaat en je gebruikelijke tools je niet helpen begrijpen waarom.
       
Dan pas wordt het gat zichtbaar.

Wordt software veiliger met AI-coding agents als Claude Mythos, of juist onveiliger?

Schaar die twee tegengestelde schaduwen werpt: de ene sluit een naad, de andere opent hem.

12-wordt-softwarebeveiliging-beter-met-ai-c.webp

Elke nieuwe golf tooling in softwareontwikkeling roept dezelfde tweedeling op. De een ziet hefboomwerking. De ander ziet risico.

Claude Mythos zit precies op die grens. Het is niet zomaar weer een coding assistant. Het leest omvangrijke codebases, vindt kwetsbaarheden, en gaat soms nog een stap verder, door uit te zoeken hoe die zwakke plekken daadwerkelijk misbruikt zouden kunnen worden.

Elke nieuwe golf tooling in softwareontwikkeling roept dezelfde tweedeling op. De een ziet hefboomwerking. De ander ziet risico.
       
[Claude Mythos](https://red.anthropic.com/2026/mythos-preview/) zit precies op die grens. Het is niet zomaar weer een coding assistant. Het leest omvangrijke codebases, vindt kwetsbaarheden, en gaat soms nog een stap verder, door uit te zoeken hoe die zwakke plekken daadwerkelijk misbruikt zouden kunnen worden.
       
Die combinatie maakt het interessant, en tegelijk ongemakkelijk om over na te denken.

Wat er gebeurt als een cloudregio uitvalt

Raster van verbonden blokken waarin één district grijs is geworden en de lijnen ernaartoe afbreken.

13-wat-er-gebeurt-als-een-cloudregio-uitval.webp

De meeste teams bouwen hun systemen op kleine storingen.

Een container crasht. Een node verdwijnt. Misschien heeft een availability zone een tijdje last. Dat zijn de scenario's waar architectuurplaten je op voorbereiden, en de meeste platformen vangen ze goed genoeg op dat je het nauwelijks merkt.

De meeste teams bouwen hun systemen op kleine storingen.
      
Een container crasht. Een node verdwijnt. Misschien heeft een availability zone een tijdje last. Dat zijn de scenario's waar architectuurplaten je op voorbereiden, en de meeste platformen vangen ze goed genoeg op dat je het nauwelijks merkt.
      
Een regiostoring is van een heel andere orde. Hij komt zelden voor, en juist daarom schuif je hem makkelijk weg. Maar als het gebeurt, is de klap er meteen en laat hij zich moeilijk indammen. In plaats van één onderdeel dat raar doet, vallen hele lagen tegelijk weg.
      
Het eerste wat je merkt is niet altijd een duidelijke storing. Dingen houden gewoon op te werken, op vreemde manieren. Requests blijven hangen. Sommige endpoints geven fouten, andere lopen in een timeout. Achtergrondjobs verwerken niets meer, zonder dat er een alarm afgaat. Systemen die van elkaar afhankelijk zijn, vallen na elkaar om, en het is niet altijd duidelijk waar het begon.

Cloudsecurity-basics die developers vaak negeren

Gesloten gevel waarin één zijdeur met een verweerd blokje wordt opengehouden.

14-cloudsecurity-basics-die-developers-vaak.webp

Cloudsecurity wordt vaak gepresenteerd als een gedeelde verantwoordelijkheid. In de praktijk vertaalt zich dat meestal naar iets als: “het platform regelt het grootste deel wel”. Precies bij die aanname beginnen de problemen.

Moderne cloudproviders doen hun werk goed als het om infrastructuur gaat — fysieke hardware, netwerklagen en managed services. Maar zodra jij daarbovenop begint te bouwen, verschuift de verantwoordelijkheid razendsnel.

Cloudsecurity wordt vaak gepresenteerd als een gedeelde verantwoordelijkheid. In de praktijk vertaalt zich dat meestal naar iets als: *“het platform regelt het grootste deel wel”*. Precies bij die aanname beginnen de problemen.
      
Moderne cloudproviders doen hun werk goed als het om infrastructuur gaat — fysieke hardware, netwerklagen en managed services. Maar zodra jij daarbovenop begint te bouwen, verschuift de verantwoordelijkheid razendsnel. Verkeerde configuraties, te ruime rechten en impliciet vertrouwen tussen services horen nog altijd bij de meest voorkomende oorzaken van incidenten.
      
Het interessante is dat die problemen zelden voortkomen uit een gebrek aan tools. Ze komen voort uit kleine beslissingen tijdens de ontwikkeling die op dat moment niet riskant lijken.

5 tools die ervaren React-developers in 2026 moeten proberen

Vijf precisie-instrumenten op een rij, strak uitgelegd als een gereedschapsset.

15-5-tools-die-ervaren-react-developers-in-.webp

Werk je al een tijd met React, dan zit je stack waarschijnlijk prima in elkaar. Je zoekt niet nog een state-library of weer een nieuwe manier om knoppen te stylen. De meeste gangbare problemen zijn opgelost, en het ecosysteem heeft zich gesetteld rond een handvol betrouwbare keuzes.

Werk je al een tijd met React, dan zit je stack waarschijnlijk prima in elkaar. Je zoekt niet nog een state-library of weer een nieuwe manier om knoppen te stylen. De meeste gangbare problemen zijn opgelost, en het ecosysteem heeft zich gesetteld rond een handvol betrouwbare keuzes.
      
Wat in dit stadium verandert, is niet wát je gebruikt, maar wáár de wrijving zit. Het gaat niet meer om dingen werkend krijgen. Het gaat om minder afstemming tussen lagen, minder repetitief performancewerk, en systemen begrijpelijk houden terwijl ze groeien.
       
De tools die nu de moeite waard zijn, richten zich op precies die randen. Ze vervangen React niet, maar ze hervormen de onderdelen eromheen die zwaarder aanvoelen dan nodig.

Waarom je CI/CD-pipeline waarschijnlijk het traagste deel van je cloudstack is

Twee pipelinetijdlijnen boven elkaar: serieel drie en een half minuut, gecacht en parallel anderhalve minuut.

16-pipeline.webp

Cloudplatformen zijn razendsnel geworden. Je zet in minuten infrastructuur neer, schaalt op aanvraag en rolt wereldwijd uit zonder al te veel moeite. En toch duurt het vaak veel langer dan verwacht om een simpele codewijziging in productie te krijgen.

Cloudplatformen zijn razendsnel geworden. Je zet in minuten infrastructuur neer, schaalt op aanvraag en rolt wereldwijd uit zonder al te veel moeite. En toch duurt het vaak veel langer dan verwacht om een simpele codewijziging in productie te krijgen.
       
Die vertraging heeft meestal niets met de cloud zelf te maken. Ze komt uit de [CI/CD-pipeline](/onze-diensten/oplossingen/zen-devops-accelerator) die tussen het schrijven en het uitbrengen van code in zit. Pipelines verzamelen na verloop van tijd extra stappen, langere testsuites en inefficiënte processen waar niemand meer naar omkijkt. Wat begon als een eenvoudige workflow, verandert langzaam in een systeem dat alles afremt.

Waarom de meeste cloudmigraties mislukken vóór de eerste deployment

Architectonisch volume dat is opgetild en de bundel verbindingen eronder zichtbaar maakt.

17-waarom-de-meeste-cloudmigraties-mislukke.webp

Een cloudmigratie begint meestal vol vertrouwen. Het plan klinkt simpel: bestaande systemen naar de cloud, minder gedoe met infrastructuur, beter kunnen schalen en de stack moderniseren. In presentaties en strategiestukken oogt het pad meestal kaarsrecht.

De werkelijkheid ziet er doorgaans anders uit.

Een [cloudmigratie](/onze-diensten/oplossingen/zen-cloud-landing-zone) begint meestal vol vertrouwen. Het plan klinkt simpel: bestaande systemen naar de cloud, minder gedoe met infrastructuur, beter kunnen schalen en de stack moderniseren. In presentaties en strategiestukken oogt het pad meestal kaarsrecht.
      
De werkelijkheid ziet er doorgaans anders uit.
       
Veel cloudmigraties lopen al vast lang voordat er ook maar iets in productie staat. Teams zijn maanden bezig met omgevingen klaarzetten, infrastructuur herschrijven en afhankelijkheden ontwarren. Budgetten lopen op. Planningen schuiven. De migratie stokt.
        
De boosdoener is zelden het cloudplatform. Het zijn de aannames die uit de oude architectuur zijn meegekomen.

OTM 5.8: een voertuig mag eindelijk meer dan één brandstof hebben

Diagram: het enkelvoudige veld fuel met averageFuelConsumption raakt in OTM 5.8 gedeprecieerd ten gunste van fuels, een lijst met diesel en elektrisch, elk met eigen verbruik

otm-5-8.webp

OTM 5.8 verscheen op 13 maart 2026. De opvallendste wijziging deprecieert een veld dat in 5.4 nog werd toegevoegd: één brandstof per voertuig blijkt niet te werken zodra je vloot hybride wordt.

Bugs fixen in het tijdperk van AI: coding agents gebruiken zonder je codebase in spaghetti te veranderen

Modulair paneel waarin één cel precies wordt vervangen, met ernaast een vak vol in de knoop geraakte kabels.

18-bugs-fixen-in-het-tijdperk-van-ai.webp

Bugs fixen is veranderd.

Niet omdat bugs anders zijn. Het zijn nog steeds null references, race conditions, aannames die niet kloppen en randgevallen die je niet zag aankomen. Het verschil is dat je nu, als er iets breekt, niet langer alleen bent met die stack trace.

Bugs fixen is veranderd.
      
Niet omdat bugs anders zijn. Het zijn nog steeds null references, race conditions, aannames die niet kloppen en randgevallen die je niet zag aankomen. Het verschil is dat je nu, als er iets breekt, niet langer alleen bent met die stack trace.
       
Je hebt AI-assistenten die:
       
- direct fixes voorstellen
       
- hele functies herschrijven
       
- tests genereren
       
- onbekende code uitleggen
       
- architectuurwijzigingen voorstellen
       
Dat verandert hoe developers problemen aanvliegen. De verleiding ligt voor de hand: fout plakken, suggestie accepteren, door.
        
Soms werkt dat, maar snelheid zonder begrip levert een nieuwe soort problemen op. Snelle pleisters die door je modules heen rimpelen. Defensieve checks die diepere problemen verbergen. Refactors die stilletjes je systeemgrenzen verleggen. Code die de test van vandaag haalt maar de wijziging van morgen bemoeilijkt.
       
De vraag is niet óf je AI inzet bij het fixen van bugs. De vraag is hoe je dat zo doet dat je leven makkelijker wordt zonder je codebase langzaam uit te hollen — en zonder je eigen leerproces uit te besteden.

AI-moeheid in development: waarom constante AI-hulp je kan uitputten

Volle bak met stapels papier naast een lege werkbak.

19-ai-moeheid-in-development-waarom-constan.webp

Er zit een herkenbaar patroon in developers die een tijdje met AI-tools werken: eerst nieuwsgierigheid, dan een periode van dagelijks gebruik, en vervolgens — verrassend genoeg — vermoeidheid. Veel engineers melden uitputting, irritatie of zelfs lichte weerzin bij het idee dagelijks met AI te moeten werken. Voor teams die verwachtten dat AI tijd zou besparen, is dat een verwarrende ervaring.

Er zit een herkenbaar patroon in developers die een tijdje met AI-tools werken: eerst nieuwsgierigheid, dan een periode van dagelijks gebruik, en vervolgens — verrassend genoeg — **vermoeidheid**. Veel engineers melden uitputting, irritatie of zelfs lichte weerzin bij het idee dagelijks met AI te moeten werken. Voor teams die verwachtten dat AI tijd zou besparen en sleur zou wegnemen, is dat een verwarrende ervaring.
       
Het is niet zo dat de tools per se slecht zijn. Het is dat omgaan met AI verandert hoe developers denken, werken en hun focus vasthouden — en die veranderingen kunnen op subtiele manieren slopend zijn, op manieren die klassieke productiviteitscijfers niet oppikken.
       
In dit artikel pluizen we uit hoe AI-moeheid eruitziet in softwareontwikkeling, waarom ze ontstaat, wat ze doet met individuen en teams, en wat organisaties eraan kunnen doen.

Remote cloud sandboxes: minder merge conflicts in verspreide teams

Diagram dat één gedeelde ontwikkelomgeving vergelijkt met een tijdelijke sandbox per engineer.

20-sandboxes.webp

In verspreide engineeringteams zijn merge conflicts een terugkerende hoofdpijn. Ze vertragen de ontwikkeling, frustreren engineers en introduceren subtiele bugs die soms pas bij de deploy opvallen. Voor kleine teams werken klassieke lokale ontwikkelomgevingen prima, maar zodra je opschaalt naar remote of over meerdere locaties, is er iets steviger nodig.

Artikelen over maatwerk, cloud en AI

Maatwerk & modernisering

Cloud & platform

Artificial Intelligence

Werkwijze & teams

Alle artikelen

Wat is er nieuw in softwareontwikkeling?

Geef je softwareontwikkeling een Boost!

Contactformulier

Standup & Deliver, de nieuwsbrief van ZEN Software