Gepubliceerd op dinsdag 16 juni 2026
IEF 23623

De vibe coder maakt genoeg creatieve keuzes voor bescherming van zijn werk

Artikel door Daniël de Weerd. Oorspronkelijk verschenen in AI-Forum 2026-2.

Software is traditioneel kennis- en arbeidsintensief om te maken en wordt daarom door het auteursrecht beschermd. Auteursrechtelijke bescherming veronderstelt echter een menselijke maker. Nu steeds meer regels broncode niet meer door een mens, maar door een AI-model in opdracht van een mens worden geschreven (“vibe coding”), roept dat de vraag op in hoeverre deze bescherming nog mogelijk en zinvol is. In deze korte bijdrage betoog ik dat die bescherming mogelijk en zinvol blijft, omdat ook de vibe coder meer dan genoeg “vrije en creatieve keuzes” maakt die het Hof van Justitie vereist.

Dit is een preview. Het volledige artikel is nu beschikbaar op www.AI-Forum.nl

Over softwareontwikkeling en vibe coding

Vibe coding is de praktijk waarbij een programmeur regels broncode niet meer handmatig schrijft, maar in plaats daarvan laat genereren door een AI-model.[1] Tot voor kort ging een groot deel van de tijd van ontwikkelaars nog op aan het uittypen van bezweringen als import { ApiClient } from "./services/apiClient of public static void main(String[] args). Bij vibe coding hoeft de programmeur dergelijke bezweringen niet meer zelf te schrijven, maar kan hij of zij een AI-model prompten met opdrachten in natuurlijke taal waarna het model de broncode genereert.

Dit maakt het maken van software vele malen sneller en goedkoper. In softwareland bestaat een eenvoudig hobbyproject al snel uit duizenden regels code en kan enterprise-software tientallen miljoenen regels beslaan. Nu deze regels code niet meer handmatig geschreven hoeven te worden, behaalt de programmeur die zijn code door AI laat genereren (de “vibe coder”) een tot voor kort onvoorstelbare productiviteitswinst. Wie nog nooit eerder heeft geprogrammeerd kan nu met AI zelf eenvoudige software maken, en wie al ruime ervaring heeft kan nu het werk doen waarvoor vroeger een team aan developers nodig was.

Dit betekent echter nog niet dat softwareontwikkelaars overbodig zijn, omdat het maken van software uit verschillende fasen bestaat. Eerst bedenk je in de ontwerpfase wat je gaat bouwen, en daarna pas ga je in de implementatiefase code schrijven om het ontwerp te realiseren. Ook in de implementatiefase blijf je echter continu nadenken over wat je aan het bouwen bent, vraag je feedback, overleg je met de opdrachtgever en pas je het plan aan. De vibe coder kan weliswaar veel sneller code schrijven, maar moet nog net zo diep nadenken over wat zijn code eigenlijk moet doen. AI kan - in ieder geval voorlopig - nog niet in je organisatie kijken wat je eigenlijk nodig hebt, of bij een klant langsgaan om te beoordelen welke pijnpunten met software kunnen worden opgelost. De gevierde computerwetenschapper Fred Brooks beschreef in 1987 al dat deze ontwerpfase verreweg het moeilijkst is:

“The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.”[2]

Hoewel het takenpakket van softwareontwikkelaars dus steeds meer zal verschuiven naar denkwerk over nut, noodzaak en functionaliteit van de software, blijft dit denkwerk daarom - op zijn minst de komende tijd, en vermoedelijk ook nog daarna - nuttig en relevant.

Juridische bescherming van computerprogramma’s

In het Europees auteursrecht worden “computerprogramma’s” auteursrechtelijk beschermd als werken van letterkunde.[3] Deze bescherming omvat “alle programma's in gelijk welke vorm” en ziet eveneens op “het desbetreffende voorbereidende ontwerpmateriaal […] dat tot het vervaardigen van een programma leidt”.[4] De beschermingsdrempel voor computerprogramma’s is gelijk aan die voor andere soorten werken: het programma moet in die zin oorspronkelijk zijn, dat het een eigen schepping van de maker is.[5] Jurisprudentie benadrukt vooral dat de bescherming alleen op de uitdrukkingswijze van het computerprogramma ziet, en niet op de functionaliteit, de gebruikte programmeertaal of de indeling van de gegevensbestanden.[6] 

Omdat de beschermingsdrempel voor computerprogramma’s gelijk is aan die voor andere werken, is ook jurisprudentie over het algemene werkbegrip relevant.

Met Infopaq introduceerde het Hof van Justitie het begrip “eigen intellectuele schepping van de maker” (ook wel “EIS”) en in Mio & Konektra liet het zich het meest recent uit over de inhoud van dat begrip.[7] Volgens Mio is een werk een voorwerp dat “de persoonlijkheid van de auteur ervan weerspiegelt door uitdrukking te geven aan de vrije en creatieve keuzen van die auteur”.[8] Door technische beperkingen ingegeven keuzes zijn hierbij niet vrij, en keuzes die niet de persoonlijkheid van de auteur weerspiegelen door “aan het voorwerp een uniek aspect te geven” zijn niet voldoende creatief.[9]

Interesse? De volledige analyse is vrij toegankelijk via ons proefabonnement

 

[1] Zie voor een uitgebreidere introductie van het begrip F.F. Blokhuis, “Vibe coding en het probleem van de auteursrechtelijke bescherming van software”, AI-forum 2026/1.

[2] Frederick P. Brooks Jr., “No Silver Bullet: Essence and Accidents of Software Engineering”, Computer Magazine april 1987.

[3] Art. 1 lid 1, Richtlijn 2009/24/EG (“Softwarerichtlijn”).

[4] Art. 1 lid 2 en overweging 7 Softwarerichtlijn.

[5] Art. 1 lid 3 Softwarerichtlijn.

[6] HvJ EU 2 mei 2012, ECLI:EU:C:2012:259 (SAS Institute), para. 39-46.

[7] HvJ EU 16 juli 2009, ECLI:EU:C:2009:465 (Infopaq);

HvJ EU 4 december 2025, ECLI:EU:C:2025:941 (Mio & Konektra).

[8] HvJ EU 4 december 2025, ECLI:EU:C:2025:941 (Mio & Konektra), para. 49.

[9] HvJ EU 4 december 2025, ECLI:EU:C:2025:941 (Mio & Konektra), para. 82.