Thijs Fassaert
WBSO in de AI-revolutie: Wat Verandert en Wat Blijft
Leestijd 6 minuten
Terwijl de immense technologische vooruitgang op het gebied van AI in veel domeinen nog toekomstmuziek lijkt, is die binnen softwareontwikkeling al realiteit. De impact van large language models (LLMs) is hier direct voelbaar: wat tot voor kort complexe maatwerk code vereiste, kan nu via modellen van spelers als OpenAI, Anthropic en Alphabet worden gerealiseerd. Deze transformatie van programmatuurontwikkeling roept fundamentele vragen op over hoe we technologische innovatie definiëren en stimuleren.
Want hoe verhoudt deze ontwikkeling zich tot de WBSO - Nederlands grootste stimuleringsregeling voor technologische vernieuwing? Hoe definieer je technisch risico en vernieuwing in een wereld waarin geavanceerde oplossingen letterlijk enkele prompts verwijderd zijn? En belangrijker nog: blijft de WBSO in zijn huidige vorm een effectief instrument voor het stimuleren van echte innovatie in softwareontwikkeling?
Want hoe verhoudt deze ontwikkeling zich tot de WBSO - Nederlands grootste stimuleringsregeling voor technologische vernieuwing? Hoe definieer je technisch risico en vernieuwing in een wereld waarin geavanceerde oplossingen letterlijk enkele prompts verwijderd zijn? En belangrijker nog: blijft de WBSO in zijn huidige vorm een effectief instrument voor het stimuleren van echte innovatie in softwareontwikkeling?
Context & Uitdaging
De WBSO (Wet Bevordering Speur- en Ontwikkelingswerk) stimuleert bedrijven om te investeren in technisch vernieuwende projecten door fiscale voordelen te bieden voor concreet speur- en ontwikkelwerk (S&O). De regeling dwingt bedrijven om vooraf hun technische roadmap en potentiële obstakels scherp te krijgen. Door alleen eigen ontwikkelwerk te subsidiëren, zorgt de WBSO voor groei van technische kennis en kunde binnen organisaties en versterkt het daarmee de innovatiekracht van het Nederlandse bedrijfsleven.
Bij softwareontwikkeling is de afbakening van S&O altijd complex geweest. Anders dan bij fysieke productontwikkeling, waar R&D en productie vaak duidelijk gescheiden fasen zijn, lopen deze activiteiten bij softwareontwikkeling vaak door elkaar. Dezelfde developer die nieuwe technische concepten uitwerkt, implementeert deze ook direct in productiecode. Dit vereist daarom een aanvullende definitie: in het kort kan S&O binnen programmatuur worden samengevat als planmatig (dus vooraf te beschrijven) technisch ontwikkelwerk aan een eigen oplossing, waarbij de ontwikkelaar tegen tekortkomingen van bestaande technologische tools/technieken aanloopt en de eigen oplossing die hiervoor wordt geprogrammeerd technische risico's bevat. De nadruk ligt hierbij duidelijk op concrete technische vernieuwing - het concept (dienst of product) waaraan wordt ontwikkeld is van ondergeschikt belang. Een extra voorwaarde is dat er in een formele programmeertaal wordt gecodeerd, zoals Java, C#, Python, PHP of Ruby.
Deze afbakening is regelmatig onderwerp van discussie. In 2019 publiceerde RVO een onafhankelijk evaluatierapport met aanbevelingen voor verruiming van de WBSO-scope voor programmatuur. In een eerder artikel betoogden we dat deze verruiming niet nodig was - de bestaande definitie bood voldoende ruimte en flexibiliteit om technische vernieuwing te stimuleren, terwijl versoepeling tot uitvoeringsproblemen zou leiden. Deze aanbevelingen hebben dan ook niet tot aanpassingen in de regeling geleid.
De opkomst van LLMs voegt een nieuwe dimensie toe aan deze discussie. Deze modellen veranderen niet alleen hóe we ontwikkelen, maar ook wát we ontwikkelen. Functionaliteiten die voorheen complex eigen ontwikkelwerk vereisten, kunnen nu worden gerealiseerd door het aanspreken van externe APIs. Tegelijkertijd ontstaan er nieuwe technische uitdagingen rond de integratie en optimale inzet van deze technologie. Dit dwingt ons om opnieuw te kijken naar waar de grenzen van S&O liggen.
De WBSO (Wet Bevordering Speur- en Ontwikkelingswerk) stimuleert bedrijven om te investeren in technisch vernieuwende projecten door fiscale voordelen te bieden voor concreet speur- en ontwikkelwerk (S&O). De regeling dwingt bedrijven om vooraf hun technische roadmap en potentiële obstakels scherp te krijgen. Door alleen eigen ontwikkelwerk te subsidiëren, zorgt de WBSO voor groei van technische kennis en kunde binnen organisaties en versterkt het daarmee de innovatiekracht van het Nederlandse bedrijfsleven.
Bij softwareontwikkeling is de afbakening van S&O altijd complex geweest. Anders dan bij fysieke productontwikkeling, waar R&D en productie vaak duidelijk gescheiden fasen zijn, lopen deze activiteiten bij softwareontwikkeling vaak door elkaar. Dezelfde developer die nieuwe technische concepten uitwerkt, implementeert deze ook direct in productiecode. Dit vereist daarom een aanvullende definitie: in het kort kan S&O binnen programmatuur worden samengevat als planmatig (dus vooraf te beschrijven) technisch ontwikkelwerk aan een eigen oplossing, waarbij de ontwikkelaar tegen tekortkomingen van bestaande technologische tools/technieken aanloopt en de eigen oplossing die hiervoor wordt geprogrammeerd technische risico's bevat. De nadruk ligt hierbij duidelijk op concrete technische vernieuwing - het concept (dienst of product) waaraan wordt ontwikkeld is van ondergeschikt belang. Een extra voorwaarde is dat er in een formele programmeertaal wordt gecodeerd, zoals Java, C#, Python, PHP of Ruby.
Deze afbakening is regelmatig onderwerp van discussie. In 2019 publiceerde RVO een onafhankelijk evaluatierapport met aanbevelingen voor verruiming van de WBSO-scope voor programmatuur. In een eerder artikel betoogden we dat deze verruiming niet nodig was - de bestaande definitie bood voldoende ruimte en flexibiliteit om technische vernieuwing te stimuleren, terwijl versoepeling tot uitvoeringsproblemen zou leiden. Deze aanbevelingen hebben dan ook niet tot aanpassingen in de regeling geleid.
De opkomst van LLMs voegt een nieuwe dimensie toe aan deze discussie. Deze modellen veranderen niet alleen hóe we ontwikkelen, maar ook wát we ontwikkelen. Functionaliteiten die voorheen complex eigen ontwikkelwerk vereisten, kunnen nu worden gerealiseerd door het aanspreken van externe APIs. Tegelijkertijd ontstaan er nieuwe technische uitdagingen rond de integratie en optimale inzet van deze technologie. Dit dwingt ons om opnieuw te kijken naar waar de grenzen van S&O liggen.
Impact
De transformatie die LLMs teweegbrengen in softwareontwikkeling is tweeledig: ze veranderen zowel het ontwikkelproces zelf als de aard van de applicaties die worden ontwikkeld.
Ontwikkelproces
Recent onderzoek van Anthropic toont aan dat 37% van de queries binnen Claude afkomstig is van professionals in computergerelateerde beroepen. Tools als GitHub Co-pilot, Aider en Replit bieden verschillende niveaus van assistentie, van eenvoudige code-suggesties tot volwaardige pair-programming ervaringen. Boilerplate coding, documentatie, testen en andere repetitieve taken kunnen steeds vaker naar LLMs worden overgedragen.
Door deze verschuiving kunnen ontwikkelaars zich meer richten op waar ze het meeste waarde toevoegen: het uitdenken van domeinspecifieke logica, architectuur en systeemontwerp, en technische optimalisatie. Terwijl LLMs steeds beter worden in het overnemen van 'reguliere' programmatuurontwikkeling, ligt het diepgaande S&O nog steeds bij de ontwikkelaar.
De transformatie die LLMs teweegbrengen in softwareontwikkeling is tweeledig: ze veranderen zowel het ontwikkelproces zelf als de aard van de applicaties die worden ontwikkeld.
Ontwikkelproces
Recent onderzoek van Anthropic toont aan dat 37% van de queries binnen Claude afkomstig is van professionals in computergerelateerde beroepen. Tools als GitHub Co-pilot, Aider en Replit bieden verschillende niveaus van assistentie, van eenvoudige code-suggesties tot volwaardige pair-programming ervaringen. Boilerplate coding, documentatie, testen en andere repetitieve taken kunnen steeds vaker naar LLMs worden overgedragen.
Door deze verschuiving kunnen ontwikkelaars zich meer richten op waar ze het meeste waarde toevoegen: het uitdenken van domeinspecifieke logica, architectuur en systeemontwerp, en technische optimalisatie. Terwijl LLMs steeds beter worden in het overnemen van 'reguliere' programmatuurontwikkeling, ligt het diepgaande S&O nog steeds bij de ontwikkelaar.
AI neemt routine-programmering over, waardoor echte innovatie verschuift naar architectuur, integratie en domeinspecifieke optimalisaties.
Applicatiearchitectuur
LLMs beïnvloeden ook fundamenteel hoe moderne applicaties worden gebouwd. Functionaliteiten die eerder complex waren om zelf te ontwikkelen - zoals het structureren van ongestructureerde data of het genereren van acties vanuit natuurlijke taal - kunnen nu worden gerealiseerd via API-calls naar LLMs. Waar voorheen eigen code werd geschreven, wordt nu een prompt opgesteld en een externe API aangesproken. Het schrijven van prompts of het aanspreken van gedocumenteerde APIs is echter per definitie geen S&O.
Omdat de WBSO hard onderscheid maakt tussen eigen programmatuurontwikkeling en inzet van bestaande technologie, valt deze nieuwe aanpak bij dit soort ontwikkelingen in eerste instantie dus vaak buiten scope. Er zit echter een belangrijke nuance: vaak is er meer nodig dan alleen een API-call met een prompt. Om eigen data goed te kunnen ontsluiten moeten bijvoorbeeld vectorrepresentaties worden gegenereerd voor RAG (retrieval-augmented generation). Voor een generieke oplossing volstaat het niet om eenmalig een prompt te schrijven - er moet technologie worden ontwikkeld die dynamisch prompts genereert afhankelijk van klant, case en context. Door de continue innovatie op het gebied van LLMs groeien niet alleen dit soort technische uitdagingen binnen de eigen backend, maar worden er ook steeds nieuwe concepten geïntroduceerd die om eigen technische oplossingen vragen.
We zien hierdoor een interessante verschuiving: waar AI 'off the shelf' functionaliteit gaat bieden die eerder eigen S&O vergde, verschuift het S&O zich naar het ontwikkelen van eigen technologie om deze mogelijkheden optimaal in te zetten en te integreren. En juist hier focust de WBSO zich op.
LLMs beïnvloeden ook fundamenteel hoe moderne applicaties worden gebouwd. Functionaliteiten die eerder complex waren om zelf te ontwikkelen - zoals het structureren van ongestructureerde data of het genereren van acties vanuit natuurlijke taal - kunnen nu worden gerealiseerd via API-calls naar LLMs. Waar voorheen eigen code werd geschreven, wordt nu een prompt opgesteld en een externe API aangesproken. Het schrijven van prompts of het aanspreken van gedocumenteerde APIs is echter per definitie geen S&O.
Omdat de WBSO hard onderscheid maakt tussen eigen programmatuurontwikkeling en inzet van bestaande technologie, valt deze nieuwe aanpak bij dit soort ontwikkelingen in eerste instantie dus vaak buiten scope. Er zit echter een belangrijke nuance: vaak is er meer nodig dan alleen een API-call met een prompt. Om eigen data goed te kunnen ontsluiten moeten bijvoorbeeld vectorrepresentaties worden gegenereerd voor RAG (retrieval-augmented generation). Voor een generieke oplossing volstaat het niet om eenmalig een prompt te schrijven - er moet technologie worden ontwikkeld die dynamisch prompts genereert afhankelijk van klant, case en context. Door de continue innovatie op het gebied van LLMs groeien niet alleen dit soort technische uitdagingen binnen de eigen backend, maar worden er ook steeds nieuwe concepten geïntroduceerd die om eigen technische oplossingen vragen.
We zien hierdoor een interessante verschuiving: waar AI 'off the shelf' functionaliteit gaat bieden die eerder eigen S&O vergde, verschuift het S&O zich naar het ontwikkelen van eigen technologie om deze mogelijkheden optimaal in te zetten en te integreren. En juist hier focust de WBSO zich op.
WBSO in het AI-tijdperk
Waar ligt de Grens?
De voorwaarden die de WBSO stelt aan programmatuurontwikkeling blijven relevant, ook in het LLM-tijdperk. De focus ligt nog steeds op concrete technische vernieuwing die het routinematige programmeerwerk overstijgt. Wat verandert is de mix van activiteiten die een ontwikkelaar uitvoert.
Nieuwe Uitdagingen in Beoordeling
Door de verwevenheid van eigen ontwikkeling met LLM-functionaliteit wordt niet de definitie van S&O, maar wel het beoordelen ervan complexer. Code die door LLMs wordt gegenereerd, of functionaliteiten die voorheen eigen ontwikkeling waren maar nu verweven zijn met externe APIs, maken het lastiger om de grenzen tussen reguliere ontwikkeling en S&O in de praktijk te bepalen. Dit heeft logischerwijs impact op het beoordelingsproces.
RVO zal kritischer kijken naar trajecten waarbij niet glashelder wordt gemaakt hoe LLM-integratie de architectuur en het ontwikkelproces beïnvloedt. Wij verwachten daarom ook meer behoefte aan controles achteraf, waarbij tijdens bedrijfsbezoeken en audits zorgvuldig wordt gekeken naar de onderbouwing van het eigen S&O binnen dit complexere technologische landschap.
Waar ligt de Grens?
De voorwaarden die de WBSO stelt aan programmatuurontwikkeling blijven relevant, ook in het LLM-tijdperk. De focus ligt nog steeds op concrete technische vernieuwing die het routinematige programmeerwerk overstijgt. Wat verandert is de mix van activiteiten die een ontwikkelaar uitvoert.
Nieuwe Uitdagingen in Beoordeling
Door de verwevenheid van eigen ontwikkeling met LLM-functionaliteit wordt niet de definitie van S&O, maar wel het beoordelen ervan complexer. Code die door LLMs wordt gegenereerd, of functionaliteiten die voorheen eigen ontwikkeling waren maar nu verweven zijn met externe APIs, maken het lastiger om de grenzen tussen reguliere ontwikkeling en S&O in de praktijk te bepalen. Dit heeft logischerwijs impact op het beoordelingsproces.
RVO zal kritischer kijken naar trajecten waarbij niet glashelder wordt gemaakt hoe LLM-integratie de architectuur en het ontwikkelproces beïnvloedt. Wij verwachten daarom ook meer behoefte aan controles achteraf, waarbij tijdens bedrijfsbezoeken en audits zorgvuldig wordt gekeken naar de onderbouwing van het eigen S&O binnen dit complexere technologische landschap.
WBSO-definitie blijft bruikbaar; de uitdaging ligt in het herkennen van technische vernieuwing binnen AI-gedreven ontwikkeling.
Praktische Implicaties
Deze ontwikkelingen onderstrepen het belang van een gedegen WBSO-implementatie. Meer dan ooit is diepgaande kennis van programmatuurontwikkeling en de grenzen tussen reguliere ontwikkeling en eigen S&O hierbinnen nodig om projecten te ontleden en te bepalen waar technische vernieuwing plaatsvindt. Dit begint bij het structureren van de aanvraag maar strekt zich uit tot het volledige traject.
Cruciaal hierbij is dat WBSO-projecten goed aansluiten bij de interne projectorganisatie. Alleen dan kunnen bestaande systemen en werkwijzen worden gebruikt voor een heldere en aantoonbare WBSO-administratie. Deze precisie in voorbereiding en uitvoering wordt met de intrede van LLMs alleen maar belangrijker.
Deze ontwikkelingen onderstrepen het belang van een gedegen WBSO-implementatie. Meer dan ooit is diepgaande kennis van programmatuurontwikkeling en de grenzen tussen reguliere ontwikkeling en eigen S&O hierbinnen nodig om projecten te ontleden en te bepalen waar technische vernieuwing plaatsvindt. Dit begint bij het structureren van de aanvraag maar strekt zich uit tot het volledige traject.
Cruciaal hierbij is dat WBSO-projecten goed aansluiten bij de interne projectorganisatie. Alleen dan kunnen bestaande systemen en werkwijzen worden gebruikt voor een heldere en aantoonbare WBSO-administratie. Deze precisie in voorbereiding en uitvoering wordt met de intrede van LLMs alleen maar belangrijker.
Conclusie & Vooruitblik
De WBSO blijft een relevant en effectief instrument voor het stimuleren van technisch vernieuwende innovaties. Hoewel LLMs grote impact hebben op programmatuurontwikkeling, blijven de kernprincipes van de regeling overeind: het onderscheid tussen inzet van bestaande technologie en ontwikkeling van eigen nieuwe technologie.
De focus op aantoonbare technische risico's en toetsbare resultaten vormt een solide basis voor toekomstige innovatiestimulering. Dit vergt geen fundamentele aanpassingen in de regeling, maar wel een zorgvuldigere aanpak. De verwevenheid van eigen ontwikkeling met externe technologieën maakt grenzen vager, terwijl intensievere WBSO-beoordelingen en -controles worden verwacht.
Deze realiteit vraagt om een nieuwe kijk op WBSO-implementatie: niet als losstaande exercitie maar als doorlopend proces dat vraagt om specialistische begeleiding. Alleen zo kan deze stimulans optimaal en duurzaam worden benut in een tijd waarin AI het ontwikkellandschap blijft transformeren.
De WBSO blijft een relevant en effectief instrument voor het stimuleren van technisch vernieuwende innovaties. Hoewel LLMs grote impact hebben op programmatuurontwikkeling, blijven de kernprincipes van de regeling overeind: het onderscheid tussen inzet van bestaande technologie en ontwikkeling van eigen nieuwe technologie.
De focus op aantoonbare technische risico's en toetsbare resultaten vormt een solide basis voor toekomstige innovatiestimulering. Dit vergt geen fundamentele aanpassingen in de regeling, maar wel een zorgvuldigere aanpak. De verwevenheid van eigen ontwikkeling met externe technologieën maakt grenzen vager, terwijl intensievere WBSO-beoordelingen en -controles worden verwacht.
Deze realiteit vraagt om een nieuwe kijk op WBSO-implementatie: niet als losstaande exercitie maar als doorlopend proces dat vraagt om specialistische begeleiding. Alleen zo kan deze stimulans optimaal en duurzaam worden benut in een tijd waarin AI het ontwikkellandschap blijft transformeren.
Op de hoogte blijven over de WBSO en gerelateerde zaken? Schrijf je in voor onze nieuwsbrief.
Links:
Links:
- Artikel "Programmatuur-ontwikkeling in de WBSO"
- Meer informatie over de WBSO en onze dienstverlening.