← Alle essays

Wat betekent vakmanschap nog

Als je zelf geen code meer schrijft maar alleen beschrijft, beoordeelt en goedkeurt - ben je dan nog een vakman?

Drie Claude Code-sessies draaien terwijl ik dit schrijf. Eén ontwikkelt een module voor ons interne systeem. Eén bouwt een nieuwe open source library. Eén verwerkt feedback op een bugreport.

Ik wissel tussen terminals, lees en keur goed. Soms grijp ik in. Meestal niet.

Een jaar geleden zou ik dit allemaal zelf hebben geschreven. Nu beschrijf ik wat ik wil, beoordeel wat terugkomt, en keur het goed of stuur bij. De code is technisch van mij. Ik ben er verantwoordelijk voor. Maar ik heb hem niet getypt.

De vraag die blijft hangen: als ik geen code meer schrijf, wat doe ik dan eigenlijk?

De identiteitsvraag

GitHub interviewde in 2024 22 ontwikkelaars die AI intensief gebruiken. Eén vraag kwam steeds terug: "If I'm not writing the code, what am I doing?"[1]

Dertig jaar lang was "ontwikkelaar" mijn identiteit. Geen projectmanager, geen architect, geen consultant. Ontwikkelaar. Iemand die code schrijft.

Code schrijven was een vak. Je moest de syntax kennen. De patronen herkennen. Weten wanneer een for-loop beter is dan een while, wanneer je een klasse splitst, wanneer recursie elegant is en wanneer het onnodig complex is. Dat was vakmanschap.

Nu beschrijf ik wat ik wil bouwen. Beoordeel de gegenereerde code. Keur ik code goed of stuur bij. De onderzoekers van GitHub noemen het de verschuiving van "code producer" naar "creative director of code." Het klinkt geweldig.

Wat sommigen missen

Niet iedereen ervaart deze verschuiving hetzelfde. Sommige ontwikkelaars missen het eigenaarschap over elke regel. De trots op een elegante oplossing die niemand anders ooit zal zien. De refactor die de code halveerde en sneller maakte. Jouw vingerafdrukken in het systeem.

Ze missen hoe het voelde om zelf te typen, regel voor regel, in een soort flow.

Anderen, waaronder ikzelf, waren altijd meer resultaatgericht. Niet het schrijven van code gaf voldoening, maar wat je ermee bouwde. Voor ons voelt AI als een bevrijding. Eindelijk kunnen we focussen op het wat, zonder al te veel tijd kwijt te zijn met het hoe.

De meningen hierover zijn verdeeld. En dat is logisch. Het raakt aan iets fundamenteels: waar haal je je voldoening uit?

De oude definitie

In 2009 publiceerde een groep ontwikkelaars het Manifesto for Software Craftsmanship.[2] Het was een reactie op hoe Agile in de praktijk was verworden tot processen en sprints, met te weinig aandacht voor de code zelf. De beweging zei: software maken is een ambacht. Clean code. Test-driven development. Refactoring als discipline. We zijn geen fabrieksarbeiders. We zijn vakmensen.

Ik geloof daar nog steeds in. Clean code, kwaliteit, discipline. Maar het manifesto ging uit van een aanname die niemand toen ter discussie stelde: dat de vakman zelf de code schreef.

Wat als dat niet meer zo is?

Wat ben je?

Een architect legt geen bakstenen. Een regisseur speelt zelf geen rol. Een dirigent bespeelt geen enkel instrument. Toch noemen we hen vakmensen. Hun vakmanschap zit in de visie die ze hebben, en de keuzes die ze maken. En uiteindelijk het eindresultaat.

Er is een uitdrukking in de industrie: "Engineers are not paid to write code. Code is a means to an end." Ontwikkelaars worden niet betaald om te typen. Ze worden betaald om problemen op te lossen. Code is het middel, niet het doel.

Die problemen los ik nog steeds op. Elke dag. Bij elke review, elke goedkeuring, elke bijsturing. De principes blijven hetzelfde. Alleen de weg ernaartoe is veranderd.

De keerzijde

In februari 2025 introduceerde Andrej Karpathy, medeoprichter van OpenAI, een nieuwe term: vibe coding.[3] Code schrijven door het volledig over te laten aan AI. Niet meer lezen wat er gegenereerd wordt. "Accept All" klikken zonder de diff te bekijken. Als er een foutmelding komt, die kopiëren naar de AI zonder commentaar.

Karpathy bedoelde het half ironisch, maar de term bleef hangen. En voor een hobbyproject in het weekend, of voor experimenten is er niets mis mee. Maar voor professionele software die in productie gebruikt wordt kan het gevaarlijk zijn. Technical debt die zich opstapelt tot iemand er naar moet kijken.

In een wereld waar produceren makkelijk is geworden, zou de lat voor kwaliteit hoger moeten liggen. Niet lager.

De nieuwe verantwoordelijkheid

De echte verschuiving is eigenaarschap over code die je niet zelf schreef.

Dat is moeilijker dan het klinkt. Het is makkelijk om iets goed te keuren dat werkt. Het is moeilijk om te zien wat er potentieel mis kan gaan. Om de subtiele ontwerpfouten te herkennen. Om nee te zeggen tegen code die technisch correct is maar strategisch verkeerd.

Reviews voelen anders nu. Meer als redigeren dan proeflezen. Meer als regisseren dan controleren. Ik lees niet om typefouten te vinden. Ik lees om te begrijpen of dit de juiste richting is.

Een voorlopig antwoord

Voel ik me nog steeds een vakman?

Ja. Ik neem beslissingen die ertoe doen. Ik herken kwaliteit en het gebrek eraan. Ik bouw dingen die werken, die blijven werken, en die echte problemen oplossen.

Vakmanschap is niet verdwenen. Het zit nu in andere dingen: in de vragen die je stelt, de keuzes die je maakt, en de kwaliteit die je eist. De vorm is anders. De essentie blijft.


  1. GitHub Blog: The new identity of a developer, 2024. ↩︎

  2. Manifesto for Software Craftsmanship, 2009. ↩︎

  3. Andrej Karpathy op X over vibe coding, februari 2025. ↩︎

Marco Geuze

Marco Geuze

30+ jaar software bouwen. Oprichter van GDK Software.

Meer over mij →