Tien jaar lang heb ik met Legalloyd geprobeerd om technologie en legal te verenigen. We hebben een platform gebouwd, honderdduizenden contracten gegenereerd, samengewerkt met geweldige developers. Maar er was één ding dat ik zelf nooit kon: programmeren. Simpelweg te ingewikkeld.
De frustratie van niet-weten
In het begin heb ik me nog verdiept in de eenvoudige syntax die we gebruikten voor het programmeren van contracten. Dat ging nog wel. Maar de echte programmeurs waren daar altijd tien keer zo goed in als ik, dus stopte ik met proberen. Ik richtte me op wat ik wél kon: product owner zijn. Ik heb me jarenlang beziggehouden met programmeurs aansturen, productontwikkeling, user stories schrijven, prioriteiten bepalen. Ik heb boeken gelezen over Clean Code en over Scrum, en samen met geweldige collega’s altijd geprobeerd om goede processen in te richten.
Maar het échte controleren, het écht weten of code goed was — dat kon ik niet. Ik pushte altijd op documentatie, zorgde dat er goede beschrijvingen waren bij code zodat developers die snel konden lezen. Maar ook die documentatie kon ik eigenlijk niet goed beoordelen, want ik begreep niet écht waar het over ging. Als ondernemer is dat een kwetsbare positie. Je bent afhankelijk van anderen voor iets dat de kern van je product is.
De vonk
Vorig jaar gebeurde er iets. Maurits Fornier, een vriend en founder van Patroon, zei tegen me: “Je moet gewoon beginnen met programmeren. Met AI kan het nu.” Ik was sceptisch. Na tien jaar had ik mezelf al lang afgeschreven als “niet-technisch genoeg.”
Rond dezelfde tijd besloten we om het platform af te splitsen van het advocatenkantoor. Legalflow.ai werd een zelfstandige onderneming, en ik had een nieuwe website nodig voor Legalloyd. Maurits zei: “Ik ga hem voor je maken, maar dan grijpen we dat wel aan om jou ook te leren hoe je dat doet. Zodat je je website zelf kunt beheren.” Zo gezegd, zo gedaan.
De instructies die alles veranderden
Wat volgde was verrassend simpel. Maurits stuurde me een lijstje met tools om te installeren: Homebrew, npm, Node, TypeScript, Supabase, Python, Claude Code, Codex. Daarna een map aanmaken in VS Code, de terminal openen, Claude starten — en dan zit je in de coding agent. Dat was het. Met behulp van AI kon ik van daaruit ongelooflijk ver komen.
De volgende stappen waren React installeren, Vite opzetten, Tailwind CSS configureren, Shadcn components toevoegen. En voor je het weet heb je een werkende applicatie.
Een voetbalteam als leerschool
Ik bedacht me dat het voor een eerste project beter was om niet meteen iets juridisch te gaan doen. Te veel druk, te veel verwachtingen, te dicht op mijn dagelijkse werk. Dus ben ik begonnen met het programmeren van een teammanager voor het voetbalteam van mijn zoontje.
Dat bleek een gouden keuze. Elke week moet ik een opstelling maken voor een team van 11-jarigen, en dat werd mijn use case. Het is ongelooflijk leuk om vanuit een concreet idee én een wekelijkse behoefte te werken. Je speelt met functionaliteit, met look and feel, met de interactie tussen frontend en backend, met het opzetten van een database. Allemaal taken die je bij elk serieus project weer tegenkomt, en waar je dus je hele ei in kwijt kunt — zonder dat je meteen probeert een professionele toepassing te maken.
Het haalt de druk eraf. Je mag fouten maken. Je mag experimenteren. En ondertussen leer je precies de vaardigheden die je later nodig hebt. En, last but not least, je bent thuis een held omdat je “websites maakt”.
De echte les: begrip gaat voor snelheid
Op de SaaS Summit eind vorig jaar waren er presentaties over vibe coding en hoe je dat als professionele developer onderdeel kunt maken van je proces. Wat me opviel — en dit kon ik eindelijk volgen omdat ik nu zélf ook enigszins kan programmeren — was dat de harde skills als programmeur juist steeds noodzakelijker worden. De verhalen over AI-slop en spaghetti-code zijn legio.
En dat bracht me bij een inzicht dat eigenlijk alles verbindt wat ik de afgelopen tien jaar heb geleerd: je kunt alleen een goed product maken, of een goede dienst ontwerpen, als je de onderliggende materie echt begrijpt.
Dit geldt net zo goed voor AI in juridische processen. Als je niet een goed geschoold jurist bent, of heel goed ingevoerd in het beoogde eindresultaat, dan is het onzeker of je een goed resultaat boekt met behulp van AI. Je kunt niet beoordelen of het klopt. Je kunt niet zien waar de nuances zitten. Je mist de fouten die er onvermijdelijk in sluipen.
Precies hetzelfde geldt voor het programmeren met AI. Juist omdat ik zie wat er kan met AI, wil ik ook echt kunnen beoordelen of de code scherp, clean en goed functioneert. Je wilt jezelf dwingen om naar een dieper niveau van begrip te komen, zodat je daarna met de hulp van AI sneller tot resultaten kunt komen.
Het is een paradox: om AI goed te gebruiken, moet je eerst zelf snappen wat je aan het doen bent. De versnelling komt pas als je de basis beheerst.
De praktijk: van chaos naar controle
Maurits gaf me een reeks principes die ik nog steeds dagelijks gebruik. Het belangrijkste is Git behandelen als piketpaaltjes: na elke substap een commit maken, niet omdat het moet, maar omdat je er altijd naar terug kunt keren als iets kapot gaat. Claude helpt je met het maken van commit messages op basis van je werk.
Voor grotere features start je een nieuwe branch — dingen die alles kunnen slopen, wil je isoleren. Als het werkt, merge je in je development branch. Claude helpt met conflicten oplossen. Je CLAUDE.md file moet goed op orde zijn maar niet te lang; met korte instructies vul je hem gaandeweg aan. Dit wordt je geheugen voor het project.
Wat ook enorm helpt zijn subagents voor specifieke taken. Ik heb er een voor UI polish die met Puppeteer een browser opent, mijn werk bekijkt, screenshots maakt, en die terugvoert aan Claude — zodat Claude ook kan “zien” en niet alleen de code heeft als basis. Een andere subagent is gespecialiseerd in bug fixes en bewaakt de consistentie in mijn codebase.
Het resultaat
Voor het eerst in 15 jaar ondernemerschap heb ik geen externe partij die mijn website maakt of beheert. Dat klinkt misschien klein, maar voor mij is het revolutionair.
Ik kan nu zelf wijzigingen doorvoeren wanneer ik wil. Ik begrijp wat er in mijn codebase staat. Ik kan de kwaliteit van code beoordelen. Ik kan nieuwe features bouwen zonder afhankelijk te zijn van derden. Mijn website deploy ik via GitHub en Vercel met één push. En misschien nog belangrijker: ik kan nu eindelijk de documentatie lezen én begrijpen waar het over gaat.
Wat ik andere founders zou zeggen
Als je al jaren denkt dat programmeren “te moeilijk” is voor jou, dan snap ik dat. Ik dacht het ook. Maar de combinatie van AI-assistentie en goede begeleiding van iemand die je de juiste fundamenten leert, maakt het verschil.
Je hoeft geen expert te worden. Je hoeft alleen genoeg te weten om te begrijpen wat er in je codebase staat, om te controleren of de kwaliteit goed is, om zelf kleine wijzigingen door te voeren, en om niet meer volledig afhankelijk te zijn van derden. Dat is al genoeg om een compleet andere positie te hebben als founder.
De tijdsinvestering? Een paar maanden van af en toe een avond of weekend erin steken. En nu, een half jaar later, is het een vanzelfsprekend onderdeel van mijn werk geworden.
Begin met iets leuks. Een hobby-project. Een tool voor je sportclub. Iets waar je elke week mee speelt. De rest volgt vanzelf.
Sjors Dobbelaar is oprichter van Legalloyd, een advocatenkantoor voor de innovatie-economie. Hij schrijft over ondernemerschap, legal tech, en — sinds kort — ook over programmeren.