We bouwen nu in drie maanden wat ons drie jaar kostte. Daar begint het moeilijke deel.

Er is dit jaar iets veranderd in ons ontwikkelteam, en ik moet er nog steeds aan wennen. In de afgelopen drie maanden heeft een handjevol mensen bij Guardian360 ons Lighthouse-platform opnieuw opgebouwd en uitgebreid met meer nieuwe functionaliteit dan we vroeger in ruim drie jaar leverden. We hebben geen groter team aangenomen en we hebben geen groter budget gevonden. AI-ondersteunde softwareontwikkeling nam simpelweg de beperking weg die elke roadmapbeslissing die we ooit namen heeft gevormd: een tekort aan mensen en middelen.

Dat klinkt als goed nieuws, en grotendeels is het dat ook. Maar het heeft een nieuwe beperking blootgelegd, en die zit niet waar ik hem verwachtte. Als bouwen niet langer schaars is, wordt implementatie dat. Onze partners, de managed service providers (MSP’s) die ons cybersecurityplatform aan hun klanten leveren, kunnen nieuwe functionaliteit niet opnemen in het tempo waarin wij die nu kunnen produceren. En twee vragen houden me daarnaast bezig. Is software die zo snel gebouwd wordt eigenlijk wel veilig? En zou meer functionaliteit de eenvoud kunnen aantasten die ons altijd heeft onderscheiden?

Wat verandert er als bouwen niet langer de bottleneck is?

Het grootste deel van de geschiedenis van Guardian360 was onze roadmap een lijst van dingen die we wilden bouwen, gerangschikt naar wat we ons konden veroorloven om te bouwen. Partners vroegen jarenlang om bepaalde functies, en veel van hen moesten wachten.

Vandaag werken onze ontwikkelaars samen met AI voor codegeneratie, testen en documentatie. We begonnen met Claude, het model van Anthropic, en verplaatsen dat werk steeds meer naar Hermes. Hermes is geen model maar een laag die we zelf hebben gebouwd. Het gebruikt open-source large language models om aan te drijven wat wij een company brain noemen, en het faciliteert de AI-agents die ons helpen bij een breed scala aan taken. Hermes, en de open-source modellen die het gebruikt, draaien in ons eigen servercluster in Nederland, en dat is net zozeer een principekwestie als een praktische. Claude heeft nooit toegang gehad tot klantdata op ons platform, omdat onze partnerovereenkomsten niet toestaan dat die data de EU verlaat. Meer van ons werk verplaatsen naar infrastructuur die we zelf beheren volgt dezelfde logica.

We zijn allesbehalve een uitzondering. Volgens Veracode’s 2026 GenAI Code Security Report genereert AI inmiddels ongeveer de helft van alle gecommitte code. De vraag is niet langer of softwareteams AI gebruiken, maar wat er daarna gebeurt.

Is software die met AI gebouwd is eigenlijk wel veilig?

Dit is de zorg die ik het serieust neem, en ik vermoed dat het de eerste vraag is die veel lezers zullen stellen. Het onderzoek geeft weinig reden tot geruststelling. Veracode constateerde dat ongeveer 44 procent van de AI-codegeneratietaken een riskante kwetsbaarheid introduceerde, met een gemiddelde security pass rate van 56 procent, nauwelijks veranderd ten opzichte van 55 procent in het eerste rapport. De studie van IOActive uit april 2026 analyseerde bijna 20.000 codevoorbeelden en vond dat 31,6 procent van de door AI gegenereerde voorbeelden volledig exploiteerbaar was; geen enkel model produceerde volledig veilige output.

Wat me nog meer zorgen baart is de kloof tussen perceptie en werkelijkheid. De Cloud Security Alliance meldt dat meer dan 75 procent van de ontwikkelaars in één onderzoek geloofde dat door AI gegenereerde code veiliger is dan door mensen geschreven code, terwijl 56 procent toegaf dat het regelmatig beveiligingsproblemen introduceert. Snelheid voelt als competentie. Dat is het niet.

De conclusie van IOActive is dat organisaties AI-output moeten behandelen als untrusted input en verplichte beveiligingsreview moeten afdwingen vóór deployment. Precies zo werken wij: AI mag de code schrijven, maar elke wijziging wordt beoordeeld door een persoon die hem begrijpt voordat hij in productie komt. We gaan nu een stap verder door onze eigen AI-pentesting op onszelf te richten, inclusief crystal box-analyse van onze eigen broncode, waarbij de testende agents volledige toegang tot de code hebben. We draaien die analyse met meerdere verschillende modellen, zodat de blinde vlekken van het ene model minder snel onopgemerkt blijven.

Hetzelfde principe vormt de AI-pentesting die we naar onze partners brengen, waarbij de AI de test uitvoert en de consultant van de partner hem ondertekent. Ontwikkelaars lijken dit instinct te delen. In de 2026 Developer Survey van Stack Overflow zei bijna de helft van de respondenten AI-output te vertrouwen wanneer ze die kunnen verifiëren, terwijl slechts 6,6 procent AI een belangrijke beslissing zou toevertrouwen.

Waarom betekent meer functies niet automatisch meer waarde?

De tweede zorg is minder technisch maar net zo reëel. No Jitter beschreef onlangs een “feature flood” in communicatiesoftware, waarbij leveranciers elk jaar honderden nieuwe functies uitbrengen terwijl de adoptie achterblijft. De benchmarks van Pendo suggereren dat ongeveer 80 procent van de gebouwde functies nooit betekenisvolle adoptie bereikt, en dat 6,4 procent van de functies 80 procent van alle clicks genereert. Dat patroon bestond al lang voordat AI er was. AI maakt het alleen goedkoper om het te herhalen.

Guardian360 heeft altijd geprobeerd een platform te bieden dat een MSP in een paar minuten aan een bestuurder kan uitleggen. Elke functie die we toevoegen maakt dat moeilijker. De kosten van het bouwen van een functie zijn ingestort; de kosten van het begrijpen ervan niet.

Onze partners dragen al genoeg complexiteit met zich mee. Onderzoek van CRN, gepubliceerd door securityleverancier Coro, vond dat MSP’s tussen de 6 en 20 of meer leveranciers beheren om securitydiensten te leveren, de integratie tussen die tools beoordelen met slechts 6,2 van de 10, en dat slechts 7 procent tevreden is over het rendement op hun securitytools. Het laatste wat ze van ons nodig hebben is nog een laag complexiteit, hoe goed bedoeld ook.

Waar is de bottleneck naartoe verschoven?

Google’s DORA-onderzoek biedt een nuttige lens. Het 2025-rapport vond voor het eerst een positief verband tussen AI-adoptie en delivery throughput, maar AI-adoptie correleerde nog steeds met lagere delivery stability: meer change failures, meer rework en langer herstel. DORA concludeerde ook dat AI bestaande organisatorische eigenschappen de neiging heeft te spiegelen en te versterken, ten goede en ten kwade.

Ik zou die observatie verder willen trekken dan het ontwikkelteam. Een functie creëert pas waarde wanneer een partner die begrijpt, configureert, aan een klant uitlegt en er een dienst omheen bouwt. Die keten loopt op menselijke snelheid. AI versnelt de eerste schakel en laat de rest onaangeroerd, wat betekent dat de wachtrij simpelweg stroomafwaarts verschuift, naar onze partners en hun klanten.

Het onderzoek van Stack Overflow wijst in dezelfde richting: mensen vertrouwen wat ze kunnen verifiëren. Een partner die een functie nooit heeft zien werken kan die niet verifiëren, kan die niet uitleggen en zal die niet verkopen.

Zouden we gewoon moeten vertragen?

Sommige partners zouden precies dat betogen: stop even, stabiliseer, laat ons bijbenen. Het is een terecht argument en ik ben het er deels mee eens. Een leverancier die sneller uitbrengt dan zijn kanaal kan volgen optimaliseert voor zijn eigen tevredenheid, niet voor die van zijn partners.

Toch zou kunstmatig vertragen een kans verspillen die kleine Europese leveranciers zelden krijgen. Het antwoord is naar mijn overtuiging discipline in plaats van remmen. Dat betekent beslissen wat je niet uitbrengt, eenvoud behandelen als een ontwerpvereiste in plaats van een bijzaak, en partners betrekken voordat een functie af is in plaats van erna.

Een deel van die discipline is in het platform zelf ingebouwd. We introduceren workspaces: in plaats van elke functie op één scherm te presenteren, groeperen we functionaliteit per taak, zodat een partner alleen ziet wat het werk op dat moment vereist. De AI-gedreven interface gaat hier nog verder. Pagina’s, rapporten en navigatie worden definities in plaats van code, en een agent bouwt de weergave die een gebruiker vraagt binnen de grenzen van diens rol. Dit is geen concept meer. We laten het op 3 november werkend zien, en we willen eerlijke feedback van onze partners over de vraag of het hen daadwerkelijk helpt.

Er is een tweede manier om complexiteit laag te houden: laat het platform meer van het werk doen. Vandaag vertelt Lighthouse je wat verbeterd zou kunnen worden. In de toekomst zal het dat ook oplossen, waar de partner en diens klant dat toestaan. Elke taak die het platform overneemt is een taak die een partner niet langer hoeft te leren, uit te leggen of in te plannen.

Waarom we de deuren van de controlekamer openen

Het logo van Guardian360 bevat een vuurtoren, en de metafoor heeft nog nooit zo kloppend gevoeld. Een vuurtoren is alleen nuttig als zijn licht de kust bereikt. We kunnen het helderste licht ter wereld bouwen, maar onze partners zijn degenen die het naar hun klanten dragen.

Daarom organiseren we “Een blik vanuit de controlekamer” op dinsdag 3 november 2026, van 09:30 tot 13:00 bij het Van der Valk Hotel in Woerden. We laten zien wat we hebben gebouwd, live draaiend in plaats van op slides, en geven een eerste blik op wat Guardian360 in 2027 levert. Deelname is gratis, er is plek voor ongeveer 50 gasten, en inschrijving is open tot 30 oktober. Meer dan de demonstraties waardeer ik het gesprek. Ik hoor liever op 3 november dat iets te complex is dan dat ik het een jaar later ontdek in adoptiecijfers.

Dus, wat is nu jouw beperking?

Als bouwen ook voor jou niet langer de beperking is, en voor veel MSP’s is dat moment dichterbij dan het lijkt, wat dan wel? Voor ons is het antwoord duidelijk. Als bouwen niet langer schaars is, wordt implementatie dat. Daar begint het moeilijke deel, en het is werk dat we alleen samen met onze partners kunnen doen.

Bronnen

• Veracode: 2026 GenAI Code Security Report: AI Is Writing More of Your Code but Security Hasn’t Caught Up (July 2026)
• IOActive: The Security Gap in AI-Generated Code (April 2026)
• Cloud Security Alliance: Vibe Coding Security Debt: AI-Generated Vulnerabilities at Scale (April 2026)
• IT Brief UK: Stack Overflow survey finds developers wary of AI tools (October 2026)
• Google Cloud / DORA: Announcing the 2025 DORA report: State of AI-assisted Software Development
• No Jitter: Vendors ship thousands of features, users adopt dozens (July 2026)
• Coro / CRN: Your Tool Stack Is Eating Your Margins (August 2026)
• Guardian360: A view from the control room, event 3 November 2026